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: <r...@xenhost.lan.crc.id.au>
Delivered-To: net...@crc.id.au
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 <net...@crc.id.au>; 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: r...@xenhost.lan.crc.id.au
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: r...@xenhost.lan.crc.id.au
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
