On 10/29/2012 08:08 PM, Steven Haigh wrote: > On 27/10/2012 1:36 PM, Steven Haigh wrote: >> On 27/10/2012 10:58 AM, David Sommerseth wrote: >>>> Content-Type: application/octet-stream >>> ^^^^^^^^^^^^^^^^^^^^^^^^ >>> This is somewhat odd, I'd expect this to be text/plain or something in >>> that direction. But that's set based on the data the mailer receives. >>> If it contains some control characters or other binary bytes, it might >>> flip over to octet-stream. >>> >>>> Content-Transfer-Encoding: base64 >>> ^^^^^^ >>> The mail is encoded as base64. At first glance, the mail headers looks >>> appropriate to me. Which makes me wonder what kind of mail client you >>> use?
The problem is caused by bad RPMs that write out text during install/update/etc and that text happens to contain non printable ASCII characters (like a carriage return character or some garbage like that). The mail program on linux sees these characters and automatically converts the mail to base64 before sending it. The patch I have to fix it is to put a " /usr/bin/tr -cd '\11\12\40-\176' " to filter the yum response before it is mailed. Works for me : --- /etc/cron.daily/yum-autoupdate.bak 2012-09-10 10:25:37.000000000 -0400 +++ /etc/cron.daily/yum-autoupdate 2012-09-25 14:55:11.535869852 -0400 @@ -322,7 +323,7 @@ echo " Mail Needs To Be Sent" echo " /bin/mail -s \"YUM:$HOSTNAME:$TODAY\" $MAILLIST " fi - cat $TEMPMAILFILE | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST + cat $TEMPMAILFILE | /usr/bin/tr -cd '\11\12\40-\176' | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST fi else if [ "$DEBUG" = "true" ] ; then @@ -330,7 +331,7 @@ echo " Mail Needs To Be Sent" echo " /bin/mail -s \"YUM:$HOSTNAME:$TODAY\" $MAILLIST " fi - cat $TEMPMAILFILE | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST + cat $TEMPMAILFILE | /usr/bin/tr -cd '\11\12\40-\176' | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST fi fi fi -- Andrew Schretter Systems Programmer, Duke University Dept. of Mathematics (919) 660-2866