SCIENTIFIC-LINUX-USERS Archives

October 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Sat, 27 Oct 2012 01:58:34 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
On 26/10/12 21:03, Steven Haigh wrote:
> Hi all,
>
> Recently I've noticed a trend to get some logs from yum updates that happen
> automatically that don't display. Looking at the message source, I see:
>
> Return-Path: <[log in to unmask]>
> Delivered-To: [log in to unmask]
> Received: from xenhost.lan.crc.id.au (unknown
> [IPv6:2002:cb38:f71b:1:52e5:49ff:fe4d:4af6])
> by mail.crc.id.au (Postfix) with ESMTP id 9566D9E
> for <[log in to unmask]>; Sat, 27 Oct 2012 04:12:57 +1100 (EST)
> Received: by xenhost.lan.crc.id.au (Postfix)
> id CC9A412A; Sat, 27 Oct 2012 04:12:56 +1100 (EST)
> Delivered-To: [log in to unmask]
> Received: by xenhost.lan.crc.id.au (Postfix, from userid 0)
> id BE3B614D; Sat, 27 Oct 2012 04:12:56 +1100 (EST)
> Date: Sat, 27 Oct 2012 04:12:56 +1100
> To: [log in to unmask]
> Subject: YUM:xenhost.lan.crc.id.au:2012-10-27
> User-Agent: Heirloom mailx 12.4 7/29/08
> MIME-Version: 1.0
> 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 message that is in my cron folder shows as blank. While I'm not an expert
> in email formatting, is it possible the encoding is incorrect causing it not
> to display properly? This one isn't really my field of expertise...

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.

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.


kind regards,

David Sommerseth

ATOM RSS1 RSS2