[Spambayes] Re: Outlook plugin plus Exchange
Wed Nov 13 01:29:51 2002
> Was the problem with duff headers, or invalid MIME sections in the
> If the latter, there is an option in the email package to not
> parse the body - instead of email.message_from_string(data), you can
> use email.Parser.Parser().parsestr(data, 1). IIRC, this treats the
> body as a single uninterpreted "payload", rather than as structured
> MIME parts.
I'm not sure it helps in this case, and I don't understand what it's doing.
Feeding the original msg (reconstructed from the diagnostic output) into
parsestr(data, True) yields a Message object m with a pretty bizarre string
>>> print m.as_string()
X-MS-Mail-Gibberish: Microsoft Mail Internet Headers Version 2.0
Received: from inet-mail7.oracle.com ([22.214.171.124]) by
zeus.sfhq.friskit.com with Microsoft SMTPSVC(5.0.2195.4453);
Sat, 13 Apr 2002 03:19:01 -0700
Received: from blaster-smtp.oracle.com (eblast01.oracleeblast.com
for PIERSH@FRISKIT.COM; Sat, 13 Apr 2002 03:08:16 -0700
Date: Sat, 13 Apr 2002 03:08:16 -0700
Subject: Oracle University iSeminars
From: Oracle Corporation<email@example.com>
X-OriginalArrivalTime: 13 Apr 2002 10:19:01.0938 (UTC)
The mystery there is why those MIME boundaries show up after "the real"
headers. They're not reflected in the header count:
and they're not payload, preamble, or epilogue either:
The type may or may not be expected:
The reason I think it *may* be unexpected is that I thought it was a Message
invariant that the type is multipart if and only if the payload is a list.
m doesn't think it's multipart despite its type:
but in *that* case the docs say the payload is a string (which None is not).
Barry, is this a sane Message object, or an insane one?
More information about the Spambayes