[Spambayes] Re: Outlook plugin plus Exchange

Tim Peters tim.one@comcast.net
Wed Nov 13 01:29:51 2002


[Moore, Paul]
> Was the problem with duff headers, or invalid MIME sections in the
> body?

The latter.

> 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
representation:

>>> print m.as_string()
X-MS-Mail-Gibberish: Microsoft Mail Internet Headers Version 2.0
Received: from inet-mail7.oracle.com ([209.246.10.171]) 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
        [148.87.9.11])g3DA8GV30065
        for PIERSH@FRISKIT.COM; Sat, 13 Apr 2002 03:08:16 -0700
Date: Sat, 13 Apr 2002 03:08:16 -0700
Message-Id: <200204131008.g3DA8GV30065@inet-mail7.oracle.com>
Subject: Oracle University iSeminars
From: Oracle Corporation<replies@oracleeblast.com>
To: PIERSH@FRISKIT.COM
Reply-To: replies@oracleeblast.com
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="next_part_of_message"
Return-Path: replies@oracleeblast.com
X-OriginalArrivalTime: 13 Apr 2002 10:19:01.0938 (UTC)
        FILETIME=[A1D8F920:01C1E2D4]

--next_part_of_message


--next_part_of_message--

>>>

The mystery there is why those MIME boundaries show up after "the real"
headers.  They're not reflected in the header count:

>>> len(m)
14
>>>

and they're not payload, preamble, or epilogue either:

>>> `m.get_payload()`
'None'
>>> m.preamble
>>> m.epilogue
>>>

The type may or may not be expected:

>>> m.get_type()
'multipart/alternative'
>>>

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:

>>> m.is_multipart()
0
>>>

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 mailing list