Everyone,
I have just upgraded a Centos 5 server to a Centos 7 server and am having difficulty with a change of behavior of mailx with the use of a command line of :
mail -s 'This is the subject' user@domain.com < text_file.txt
On Centos 5 when mailx was used by a program started by a cron job we were able to send a text file as an email message and the headers did not contain 'Content-Transfer-Encoding: base64'
On Centos 7 the headers contain 'Content-Transfer-Encoding: base64' and when the client gets the e-mail they are unable to open it up.
The interesting thing is that on Centos 7 when the command line is used by typing the above command 'Content-Transfer-Encoding: 7bit' is placed in the header and the client can see the e-mail without a problem.
I have looked for a way to control the 'Content-Transfer-Encoding:' header to '7bit' when we use a cron job, but I have not been able to figure out how.
Your suggestions would be appreciated.
Thank you,
On Fri, 4 Sep 2020 at 16:00, Gregory P. Ennis PoMec@pomec.net wrote:
Everyone,
I have just upgraded a Centos 5 server to a Centos 7 server and am having difficulty with a change of behavior of mailx with the use of a command line of :
mail -s 'This is the subject' user@domain.com < text_file.txt
On Centos 5 when mailx was used by a program started by a cron job we were able to send a text file as an email message and the headers did not contain 'Content-Transfer-Encoding: base64'
The version of mailx in Red Hat Enterprise Linux 5 is based off the old BSD mailx program (in Debian it looks like it is still available as bsd-mailx). That version was 'bit' rotting and having problems with newer mail servers. For an afternoon read http://heirloom.sourceforge.net/mailx_history.html and https://www.redhat.com/archives/rhl-devel-list/2008-June/msg00628.html [It looks like this was further forked into s-nail which Debian, Ubuntu, Arch, etc seem to ship as the default for mailx now.]
Looking for why this change was done I found these:
https://www.redhat.com/archives/rhl-devel-list/2008-June/msg00632.html https://www.redhat.com/archives/rhl-devel-list/2008-June/msg00641.html
which says one of two ways to hack around this problem: 1. Put in /etc/mail.rc the items needed 2. Try the MAILRC=/dev/null hack
and finally a google "heirloom mailx Content-Transfer-Encoding base64" got me to
https://stackoverflow.com/questions/10343106/linux-mail-file-log-has-content...
which seems to offer changing it to
cat -v {{file}} | mail -s "your subject" "your@recipient.internet"
On Centos 7 the headers contain 'Content-Transfer-Encoding: base64' and when the client gets the e-mail they are unable to open it up.
The interesting thing is that on Centos 7 when the command line is used by typing the above command 'Content-Transfer-Encoding: 7bit' is placed in the header and the client can see the e-mail without a problem.
I have looked for a way to control the 'Content-Transfer-Encoding:' header to '7bit' when we use a cron job, but I have not been able to figure out how.
Your suggestions would be appreciated.
Thank you,
Greg Ennis
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Stephen and Kenneth,
Thank you very much for your help.
I tried 'MAILRC=/dev/nul' which I put in /etc/mail.rc as
'set MAILRC=/dev/null'
But I did not identify that this changed any behavior.
The link below was very helpful Stephen thank you for your kindness in digging this out for me. https://www.digitalocean.com/community/tutorials/how-to-send-e-mail-alerts-o...
In the end the above link gave me a grammar and syntax that worked, but it is requiring a change in every line of code that the 'mail' command had been used. the following syntax and grammer gave me what I needed.
echo | mail -s "Subject" -r from@address -q /loc/to/body.txt email@address
Thank you again for your help!!!
Greg
On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis PoMec@pomec.net wrote:
Stephen and Kenneth,
Thank you very much for your help.
I tried 'MAILRC=/dev/nul' 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.
But I did not identify that this changed any behavior.
The link below was very helpful Stephen thank you for your kindness in digging this out for me.
https://www.digitalocean.com/community/tutorials/how-to-send-e-mail-alerts-o...
In the end the above link gave me a grammar and syntax that worked, but it is requiring a change in every line of code that the 'mail' command had been used. the following syntax and grammer gave me what I needed.
echo | mail -s "Subject" -r from@address -q /loc/to/body.txt email@address
Thank you again for your help!!!
Greg
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis PoMec@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@address -q /loc/to/body.txt email@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...
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@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@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
--On Friday, September 04, 2020 3:58 PM -0500 "Gregory P. Ennis" PoMec@PoMec.Net wrote:
On Centos 7 the headers contain 'Content-Transfer-Encoding: base64' and when the client gets the e-mail they are unable to open it up.
That sounds like a broken client that needs to be updated. What kind of client?
-
Gregory P. Ennis -
Kenneth Porter -
Stephen John Smoogen