[Bug 2569] MSGID_FROM_MTA_SHORT triggers too easily

[bu...@bugzilla.spamassassin.org]

http://bugzilla.spamassassin.org/show_bug.cgi?id=2569





------- Additional Comments From felicity@kluge.net  2004-01-09 14:27 -------
A few things.

1) If you want to post a full header, please _ATTACH_ it to the ticket, not paste it into a comment 
field.
2) Don't bother posting headers w/out Received headers, they can't possibly hit this issue.  (I think 
it was just a bad paste, but still ...)
3) This rule's logic requires hypercubes, I'm fairly certain.

SMTP local injection:
Received: from localhost (localhost [127.0.0.1])
        by eclectic.kluge.net (Postfix) with ESMTP id 2BCF743E5C3
        for <tv...@kluge.net>; Fri,  9 Jan 2004 17:15:59 -0500 (EST)
Message-Id: <20...@eclectic.kluge.net>
From: tvd@example.com

and

CLI local injection:
Received: by eclectic.kluge.net (Postfix, from userid 501)
        id 800CD411B3B; Fri,  9 Jan 2004 16:35:38 -0500 (EST)
Message-Id: <20...@eclectic.kluge.net>
From: tvd@example.com

Both trigger the rule.  Basically what happens is the function finds the Received header that did the 
Message-Id if possible (the id in the Received is in the Message-Id).  If there are a small number of 
Received headers (<=2 if postfix sent the mail originally, <=1 for everyone else -- I think this is a 
bug or an old behavior (examples in this ticket show only 1 Received for local messages), but it's 
an explicit set of code), and the from domain doesn't match at the end of the message-id, it's 
flagged as MSGID_FROM_MTA_SHORT.

  4.432   6.7680   0.0560    0.992   0.94    3.67  MSGID_FROM_MTA_SHORT

So it hits 6.8% of spam, 0.06% of ham, for an accuracy rate of 99.2%.

WRT the postfix bit...  Apparently older versions did this:
Received: by jmason.org (Postfix, from userid 500)
        id 0ADD316F10; Wed, 23 Jul 2003 18:32:32 +0100 (IST)
Received: from jmason.org (localhost [127.0.0.1])
        by jmason.org (Postfix) with ESMTP
        id 03522F8E9; Wed, 23 Jul 2003 10:32:32 -0700 (PDT)
Message-Id: <20...@jmason.org>

versus the new versions which don't add the extra Received header.  I would say the code to 
determine the 1 vs 2 header bit ought to specifically look for the 'from userid' followed by a 
127.0.0.1 entry, instead of the current "first added" Received headers are from Postfix, which is 
definitely a bug.

So... If I modify the code to do:

  # Postfix adds the Message-ID on the second local hop.  Note: this is not
  # an exemption, this is a special case to classify these hits correctly.
  if ($#received > 0 &&
      $received[$#received] =~ /\[127\.0\.0\.1\].+\(Postfix.*?\)/i &&
      $received[$#received - 1] =~ /\(Postfix, from userid \d+\)/i)
  { 
    $local = 2;
  }

(which I'm not 100% convinced is right either, but ...), some of the FPs ought to be removed (when 
postfix sends to another postfix...)  At least the original reported header, and comment #4.

The rest, I can see the argument that the sender should be adding a Received header when they 
send the mail directly to you since clients ought not to be doing MTA deliveries.  So I don't 
necessarily think there's anything to do about those FPs.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.