[Spambayes] Re: Outlook plugin plus Exchange

[Tim Peters]

[Piers Haken]
> I'm not sure that's the case. Outlook _always_ shows the MIME headers
> below the SMTP headers in its 'internet headers' UI.

My Outlook never does.  Really!  Never.  I've trained on thousands of HTML
spam here, and surely would have noticed this problem if it had ever popped
up.

So, there's some difference between our Outlooks.  Which version are you
using?  I'm using Outlook 2000 SR-1, build 9.0.0.4201, Internet Mail Only
configuration, and get email solely thru remote POP3 accounts.  I'm
*guessing* you've got yours configured for Corporate/Workgroup, which is
said to change lots of stuff in undocumented ways.

> For example, heres the 'headers' from another message which does render
> correctly and that spambayes does parse correctly:

<example>
Microsoft Mail Internet Headers Version 2.0
Received: from sccrmhc02.attbi.com ([204.127.202.62]) by
zeus.sfhq.friskit.com with Microsoft SMTPSVC(5.0.2195.5329);
         Mon, 11 Nov 2002 11:22:27 -0800
Received: from Computer ([12.236.244.49]) by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20021111191007.KEOD5251.sccrmhc02.attbi.com@Computer>;
          Mon, 11 Nov 2002 19:10:07 +0000
From: "Rebecca Whitworth" <lesanctuaire@earthlink.net>
To: "Piers Haken" <piersh@friskit.com>
Cc: "Traci and Stephen Green" <tracigreen50@yahoo.com>
Subject: the green's car
Date: Mon, 11 Nov 2002 11:15:54 -0800
Message-ID: <LMBBIHONPNPJLKCOKALNIEDIDHAA.lesanctuaire@earthlink.net>
MIME-Version: 1.0
Content-Type: multipart/related;
        boundary="----=_NextPart_000_002F_01C28973.B386B770"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: lesanctuaire@earthlink.net
X-OriginalArrivalTime: 11 Nov 2002 19:22:27.0328 (UTC)
FILETIME=[ABBFA800:01C289B7]

------=_NextPart_000_002F_01C28973.B386B770
Content-Type: multipart/alternative;
        boundary="----=_NextPart_001_0030_01C28973.B386B770"

------=_NextPart_001_0030_01C28973.B386B770
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

------=_NextPart_001_0030_01C28973.B386B770
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


------=_NextPart_001_0030_01C28973.B386B770--
------=_NextPart_000_002F_01C28973.B386B770
Content-Type: image/jpeg;
        name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: <image001.jpg@01C28973.B30C7E60>


------=_NextPart_000_002F_01C28973.B386B770--
</example>

> As you can see it's just showing everything but the contents of
> the MIME parts.

Yes, I see.  I've never seen anything like that before, though.

> I don't think there's any suggestion that these are _just_ the SMTP
> headers, but the outlook plugin is treating them as such.

Sure, because that's what the people who wrote the client have *seen* in
their Outlooks.  It's not like what MS does here is documented <wink>.

> Maybe the outlook plugin should trim the non-SMTP parts from these
> 'headers' before passing them to the classifier??

Looks like we don't have any choice about that now.

> Yeah, it's a mess, but I don't think that the classifier should assume
> that the message has SMTP headers at all, since many other MTA's exist
> (exchange, notes, etc...)

We don't.  The value of the MAPI PR_TRANSPORT_MESSAGE_HEADERS property is
magnificently ill-defined, to the point of complete uselessness, so this is
purely poke-and-hope programming.  The only other case we've *seen* before
this is the one where PR_TRANSPORT_MESSAGE_HEADERS has no value, in which
case there's code to try to *synthesize* some bare-bones headers out of the
PR_SUBJECT, PR_DISPLAY_NAME, PR_DISPLAY_TO, and PR_DISPLAY_CC properties.
Now some other case has popped up -- so it goes.

> Outlook wasn't designed with MIME in mind ...

I had figured that one out already <wink>.