For a while now I experienced a strange behavior on a monthly executed cron script, which is installed on three different servers. The cron script launches an SQL query and mails the output as body to my e-mail address.
The strange behavior? The e-mail received from one out of the three servers is empty, instead of a body a file is attached called "noname". All scripts are exactly the same. As mail binary, mailx is used on all machines.
Today I looked into this and mailx != mailx. There are different versions of mailx around and depending on which version you have installed, the treatment of a mail can be very different. So I compared the installed mailx binaries on the different servers.
# dpkg -l | grep mailx
ii bsd-mailx 8.1.2-0.20071201cvs-3 A simple mail user agent
ii mailx 1:20071201-3 Transitional package for mailx rename
Broken Server (sent the noname attachment):
# dpkg -l | grep mailx
ii heirloom-mailx 12.4-2 feature-rich BSD mail(1)
The difference is easy to see. heirloom-mailx seems to have problems with some output. As the working server is an older version of Debian, the mailx package is now included in the mailutils package.
# apt-get remove heirloom-mailx
# apt-get install mailutils
After the installation of mailutils, /usr/bin/mailx was back and the e-mail now contained the output in the body part.
Side Note: The issue only happened with a certain output (maybe length of row?). A simple echo worked fine:
echo -ne "bla\nbla\nbla\nbla\nbla\nbla\nbla\nbla\nbla\nbla\nbla\nbla\nbla\nbla" | mailx -s Test firstname.lastname@example.org
But the MySQL output was attached to the file. Same if I wrote the output first to a file and then wanted to send the content with cat.
Update November 5th 2012:
I just took a look with my colleague at the mail headers. The mail sent by heirloom-mailx wrongly defined the mail as octet-stream (a binary). That must be the reason, why my mail client attached the content instead of showing it in body:
User-Agent: Heirloom mailx 12.4 7/29/08
But why does heirloom-mailx define the content as octet-stream? Our guess is that the data, coming from a ISO-8859-1 database, is then handled by the UTF8 system encoding and forwarded to mailx. The system then doesn't know the ISO characters and therefore doesn't see the content as text/ascii, ergo defining the content as binary.
Francisco Maia from Portugal wrote on Aug 25th, 2015:
Thank you, you just saved my day.
Lost an hour with this same problem.
The strings command fixed my script.
Psype from France wrote on Nov 20th, 2013:
I was experiencing the same problem, but only when I had special chars to send.
adding a "strings" to my command, which will only prints... well, printable chars, worked like a charm.
echo "toto\033\010tata" | strings | mailx [...]
Alexandre Magno from Natal-RN, Brazil wrote on Mar 7th, 2013:
If content all is utf-8, it works. For example: cat two utf-8 files; no make union of iso-8859-1 and utf-8 files. I use Ubuntu 12.04.2 LTS.
Personal Internet VMware PHP Linux Shell Bluecoat Proxy Windows Hardware Virtualization Nagios MySQL DB Monitoring Mail Android Network Wyse Hacks Tomcat Postgres Apple Mac Backup BSD ZFS Solaris SmartOS Unix Multimedia Perl Database MongoDB CMS OTRS FreeBSD Wordpress LXC Nginx Proxmox DNS Graphics GlusterFS Security Chef HAProxy Icinga Ansible HTML MariaDB Containers Rancher Docker AWS ELK Kibana Logstash Filebeat Varnish PGSQL PostgreSQL ElasticSearch CouchDB Bash Macintosh Container Minio Grafana InfluxDB Databases NFS OSSEC SystemD Java Zoneminder Surveillance Elasticsearch SSL TLS Icingaweb2 Cloud Wireless Kubernetes Ubuntu