Bug 2072 - document that Outlook Express forwarded messages will FP some rules
Summary: document that Outlook Express forwarded messages will FP some rules
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 2.55
Hardware: All Solaris
: P5 normal
Target Milestone: 3.0.0
Assignee: SpamAssassin Developer Mailing List
URL: http://www.ipinc.net
Whiteboard:
Keywords:
Depends on:
Blocks: 2344 3208
  Show dependency tree
 
Reported: 2003-06-16 17:02 UTC by Internet Partners Inc
Modified: 2004-03-23 13:01 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Internet Partners Inc 2003-06-16 17:02:39 UTC
Microsoft Outlook Express 6 has a Tools->Message Rule->Mail section that
allows you to enter a rule to automatically process incoming mail.

If a rule is entered that says "where the From line contains XXXXX forward
it to"  then when Microsoft Outlook forwards the mail message and RETAINS
the original message ID, instead of generating it's own.  Of course the
From line is set to the user that is forwarding the mail message.  Because
the domain name part of the message ID is different from the From line, the
test is activated.

I'm sure that what Outlook is doing violates some convention or other, but
because it is such a common MUA, I think it would be wise to reduce the
point value of this test by a half point.  At least, document the misbehavior
in the FAQ if nothing else.
Comment 1 Daniel Quinlan 2003-06-22 22:15:37 UTC
We need an example message that has been forwarded in this way.

Ideally, you could attach both versions of the message: the original message
and the forwarded version.  (Please use the "Create a New Attachment" link
to attach the message, don't cut-and-paste.)
Comment 2 Theo Van Dinter 2003-08-07 06:44:32 UTC
Just to note, the "some convention or other" is RFC 2822.  The question comes up (and this could 
be answered, I think, via a message sample): Is Outlook forwarding or resending the mail?  If 
forwarding, it's in complete violation of RFC2822.  If it's resending, it's valid to leave the message, 
but then it's invalid to change the From header, and they should add various Resent-* headers.

So either way, they're in violation of the RFC it sounds like.  But again, it'd be great to have some 
examples.  Even better to have pristine copies of "before" and "after".

The relevent sections of RFC 2822:

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.
[...]
   The message identifier (msg-id) itself MUST be a globally unique
   identifier for a message.  The generator of the message identifier
   MUST guarantee that the msg-id is unique.
[...]
   Note: Reintroducing a message into the transport system and using
   resent fields is a different operation from "forwarding".
   "Forwarding" has two meanings: One sense of forwarding is that a mail
   reading program can be told by a user to forward a copy of a message
   to another person, making the forwarded message the body of the new
   message.  A forwarded message in this sense does not appear to have
   come from the original sender, but is an entirely new message from
   the forwarder of the message.  On the other hand, forwarding is also
   used to mean when a mail transport program gets a message and
   forwards it on to a different destination for final delivery.  Resent
   header fields are not intended for use with either type of
   forwarding.
[...]
   Resent fields SHOULD be added to any message that is reintroduced by
   a user into the transport system.  A separate set of resent fields
   SHOULD be added each time this is done.  All of the resent fields
   corresponding to a particular resending of the message SHOULD be
   together.  Each new set of resent fields is prepended to the message;
   that is, the most recent set of resent fields appear earlier in the
   message.  No other fields in the message are changed when resent
   fields are added.
[...]
   The "Resent-Message-ID:" field provides a unique identifier for the
   resent message.

and from RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
Comment 3 Theo Van Dinter 2003-08-07 06:47:57 UTC
Subject: Re: [SAdev]  FORGED_MUA_OUTLOOK,MSG_ID_ADDED_BY_MTA_3 test is too harsh

On Thu, Aug 07, 2003 at 06:49:18AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> forwarding, it's in complete violation of RFC2822.  If it's resending, it's valid to leave the message, 

that should read "valid to leave the message-id unchanged", fyi

Comment 4 Internet Partners Inc 2003-08-07 12:08:47 UTC
Here are some samples for your perusal.

The first is the complete text of the message, it was sent from 
host "puka.ipinc.net" with a forged sender's address of "don@seasurf.net"
using sendmail at the command line.  The recipient is "support@ipinc.net

The second is the complete text of the message after it has passed through
Outlook running on host "brentsdesk.ipinc.net", outlook retrieved the message
from the mailserver via POP3, then a ruleset on Outlook that keys 
off "don@seasurf.net" told it to forward to user's mailbox "spilcher" whereupon 
Outlook SMTP-transmitted the message back to the mailserver, using the original 
message ID.

Note that in this case Outlook has changed the From: header but not changed the 
message ID.


-------------first message-------------------cut here----------------
From don@seasurf.net Thu Aug  7 11:09:51 2003
Return-Path: <don@seasurf.net>
Received: from puka.ipinc.net (puka.ipinc.net [205.139.120.61])
        by ipinc.ipinc.net (8.11.7/8.11.7) with ESMTP id h77I9pK15015
        for <support@ipinc.net>; Thu, 7 Aug 2003 11:09:51 -0700 (PDT)
Received: (from root@localhost)
        by puka.ipinc.net (8.11.1/8.11.1) id h77I9Pa09659
        for support@ipinc.net; Thu, 7 Aug 2003 11:09:25 -0700 (PDT)
        (envelope-from don@seasurf.net)
Date: Thu, 7 Aug 2003 11:09:25 -0700 (PDT)
From: don@seasurf.net
Message-Id: <200308071809.h77I9Pa09659@puka.ipinc.net>
To: undisclosed-recipients:;
X-Spam-Status: No, hits=2.0 required=4.1
        tests=NO_REAL_NAME,UNDISC_RECIPS
        version=2.55
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Content-Length: 64
Status: O
X-Status: 
X-Keywords:                  
X-UID: 236387

test

------------end of first message --------cut here----------------

-------forwarded message-----------cut here---------------------

From support@ipinc.net Thu Aug  7 11:11:48 2003
Return-Path: <support@ipinc.net>
Received: from brentsdesk (brentsdesk.ipinc.net [205.139.102.132])
        by ipinc.ipinc.net (8.11.7/8.11.7) with SMTP id h77IBeK15323
        for <SPilcher@IPINC.NET>; Thu, 7 Aug 2003 11:11:40 -0700 (PDT)
From: "Support at Internet Partners, Inc." <support@ipinc.net>
To: <SPilcher@ipinc.net>
Received: from puka.ipinc.net (puka.ipinc.net [205.139.120.61]) by 
ipinc.ipinc.net (8.11.7/8.11.7) with ESMTP id h77I9pK15015 for 
<support@ipinc.net>; Thu, 7 Aug 2003 11:09:51 -0700 (PDT)
Received: (from root@localhost) by puka.ipinc.net (8.11.1/8.11.1) id 
h77I9Pa09659 for support@ipinc.net; Thu, 7 Aug 2003 11:09:25 -0700 (PDT) 
(envelope-from don@seasurf.net)
Date: Thu, 7 Aug 2003 11:11:39 -0700
MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <200308071809.h77I9Pa09659@puka.ipinc.net>
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-Spam-Status: No, hits=-96.5 required=4.1
        tests=FORGED_MUA_OUTLOOK,USER_IN_WHITELIST
        version=2.55
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Status:  O
Content-Length: 65


test
-------------------end of second message --------cut here------------
Comment 5 Daniel Quinlan 2003-10-01 20:25:02 UTC
I don't see how we can possibly fix this, sorry.  The mail program is just
plain broken and the example you've provided shows no way to even work around
the problem.

I'm going to change this to a documentation bug and set the milestone
for 2.70.  At most, it should be in the FAQ, but it's not even a frequently
asked question.
Comment 6 Justin Mason 2004-03-23 22:01:24 UTC
added to FAQ