On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis <PoMec@xxxxxxxxx> 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-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@xxxxxxxxxxx'"
#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@xxxxxxxxxx < /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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
