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?Thats pretty much what I see as well... The mail client is Thunderbird 16.0.1 on Windows 7 - so I wouldn't expect issues here... but you never know.If you take that "gibberish blob" below and send it through 'base64 -d' or 'openssl base64 -d', then you'll get something quite readable out. So from what I see, it should be all good.Yeah, I couldn't see anything at first glance either...I'm suspecting a mail client which doesn't parse the Content-Transfer-Encoding field very well - or that it rejects to display mails with application/octet-stream.Maybe - but I'd expect thunderbird would do the right thing? :\
For what its worth, I also looked at these emails on my iPad. They come up with an attachment and no actual content in the body of the email.
CC'ing Pat & sl-devel for comment - as I'm pretty sure the yum auto-update plugin isn't default in TUV...
Link address for full thread: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1210&L=scientific-linux-users&T=0&P=15732 -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299
smime.p7s
Description: S/MIME Cryptographic Signature
