On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis <PoMec at pomec.net> wrote: > > Stephen and Kenneth, > > Thank you very much for your help. > > I tried 'MAILRC=/dev/null' which I put in /etc/mail.rc as > > 'set MAILRC=/dev/null' > > No that is meant to be a shell environment variable so that it does not try to read /etc/mail.rc.. if you have it in /etc/mail.rc its not going to help any. ----------------------------------------------------------------------------------- Stephen, Unfortunately, the syntax below that I thought was working did not work from a cron job : "echo | mail -s 'Subject' -r from at address -q /loc/to/body.txt email at address" Also the addition of environment variables did not work with a cron job. I was not able to get any change in behavior by adding an environment variable as 'MAILRC=/dev.null'. I found an additional reference using the 'MAILRC=/dev/null mailx' and this did not work either. There was some references of adding additional environment variables which also did not work : 'LC_NAME=fr_FR.UTF-8' 'LC_ALL=fr_FR.UTF-8' The purpose of this as I understood the reference was a faulty interpretation of accents as control characters https://stackoverflow.com/questions/10343106/linux-mail-file-log-has-content-type-application-octet-stream-a-noname-attac I finally found two things that worked : #1. Your reference to the use cat with the -v switch did work with a cron job, and this is the only way I could get mailx to not base64 encode the file. "cat -v log/logfile.log | mail -s 'here is a log file' 'person at example.com'" #2. Use of mutt which had the exact same syntax and grammar as mail in 98% of my code "mutt -s 'Test the dump' Name at domain.com < /u/3/dump" The easiest fix for me ended up installing mutt and changing the symbolic link of mail->mailx to mail->mutt I hope this is helpful to others that have the same problem with mailx. Greg Ennis