Live Messenger Invitation with forged Received header?

[Andreas Pettersson <an...@telia.com>]

I need some help with understanding why some of the below rules 
triggered on these headers..


Received: from baym-sm1.msgr.hotmail.com ([207.46.1.190])
    by mail.mydomain.com with esmtp
    (envelope-from <xx...@hotmail.com>)
    id 1GJcP7-00063q-JH
    for yyyy.zzzz@mydomain.com; Sat, 02 Sep 2006 22:47:53 +0200
Received: from mail pickup service by baym-sm1.msgr.hotmail.com with 
Microsoft SMTPSVC;
     Sat, 2 Sep 2006 13:47:45 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; 
boundary="----_=_NextPart_001_2QAIHCIKEOG.9E6CG57B"
Date: Sat, 02 Sep 2006 13:41:39 Pacific Daylight Time
From: xxxx@hotmail.com
To: yyyy.zzzz@mydomain.com
X-MSMessengerInvitationMailTemplateVersion: 2.9.12.5.0.02
Message-ID: <BA...@baym-sm1.msgr.hotmail.com>

    2.2 INVALID_DATE           Invalid Date: header (not RFC 2822)
    0.8 DATE_IN_PAST_06_12     Date: is 6 to 12 hours before Received: date
    2.3 FORGED_HOTMAIL_RCVD    Forged hotmail.com 'Received:' header found
    0.3 MIME_BOUND_NEXTPART    Spam tool pattern in MIME boundary


Why does SA 3.1.3 think that the hotmail.com Received header is forged? 
As far as I can see it seems alright..
"Pacific Daylight Time" is perhaps not the right way to describe the 
timezone, or is it?
And "Spam tool pattern in MIME boundary", what's that by the way?


Regards,
Andreas

Re: Live Messenger Invitation with forged Received header?

[Loren Wilton <lw...@earthlink.net>]

>I need some help with understanding why some of the below rules triggered 
>on these headers..
>
>    2.2 INVALID_DATE           Invalid Date: header (not RFC 2822)
>    2.3 FORGED_HOTMAIL_RCVD    Forged hotmail.com 'Received:' header found
>    0.3 MIME_BOUND_NEXTPART    Spam tool pattern in MIME boundary
>
> Why does SA 3.1.3 think that the hotmail.com Received header is forged? As 
> far as I can see it seems alright..

I'm not an expert on received header formats, but I would guess that it 
isn't in precisely the right format to be a known hotmail received header.

> "Pacific Daylight Time" is perhaps not the right way to describe the 
> timezone, or is it?

No, it is completely bogus.

> And "Spam tool pattern in MIME boundary", what's that by the way?

Certain spam tools leave certain patterns in the message.  Sometimes those 
patterns are also used by legit mailers, but much less frequently than the 
spam tool uses them.  A spam tool pattern was detected in the message, and 
it contributed a small score.  This indicates that the pattern can also be 
used by real mailers.

Re: Live Messenger Invitation with forged Received header?

[jdow <jd...@earthlink.net>]

From: "Andreas Pettersson" <an...@telia.com>
>I need some help with understanding why some of the below rules 
> triggered on these headers..
> 
> 
> Received: from baym-sm1.msgr.hotmail.com ([207.46.1.190])
>    by mail.mydomain.com with esmtp
>    (envelope-from <xx...@hotmail.com>)
>    id 1GJcP7-00063q-JH
>    for yyyy.zzzz@mydomain.com; Sat, 02 Sep 2006 22:47:53 +0200
> Received: from mail pickup service by baym-sm1.msgr.hotmail.com with 
> Microsoft SMTPSVC;
>     Sat, 2 Sep 2006 13:47:45 -0700
> MIME-Version: 1.0
> Content-Type: multipart/alternative; 
> boundary="----_=_NextPart_001_2QAIHCIKEOG.9E6CG57B"
> Date: Sat, 02 Sep 2006 13:41:39 Pacific Daylight Time
> From: xxxx@hotmail.com
> To: yyyy.zzzz@mydomain.com
> X-MSMessengerInvitationMailTemplateVersion: 2.9.12.5.0.02
> Message-ID: <BA...@baym-sm1.msgr.hotmail.com>
> 
>    2.2 INVALID_DATE           Invalid Date: header (not RFC 2822)
>    0.8 DATE_IN_PAST_06_12     Date: is 6 to 12 hours before Received: date
>    2.3 FORGED_HOTMAIL_RCVD    Forged hotmail.com 'Received:' header found
>    0.3 MIME_BOUND_NEXTPART    Spam tool pattern in MIME boundary
> 
> 
> Why does SA 3.1.3 think that the hotmail.com Received header is forged? 
> As far as I can see it seems alright..
> "Pacific Daylight Time" is perhaps not the right way to describe the 
> timezone, or is it?

It is not. And the bad date format is usually a very good spamsign.
Someboty ought to beat them about the virtual head and shoulders to
get it fixed. Of course, if they don't care about the issue why should
we care about them?

> And "Spam tool pattern in MIME boundary", what's that by the way?

A MINE boundary declaration that is in a format that is typically
spam. Maybe the used a spam engine to send their invitations?

{^_^}