SA Bugzilla – Bug 2072
document that Outlook Express forwarded messages will FP some rules
Last modified: 2004-03-23 13:01:24 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.
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.)
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.
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
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------------
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.
added to FAQ