http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5185
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |
------- Additional Comments From [EMAIL PROTECTED] 2006-12-07 03:15 -------
I see the problem. When SpamAssassin is integrated with an MTA with a
milter-type layer, and allowed to reject messages as part of the SMTP
transaction before the message is filed to the delivery spool, this can arise.
here's the timeline:
1. spammer connects to SMTP, issues HELO,MAIL,RCPT,DATA. crucially,
they do _not_ forge any additional Received headers of their own.
The message just looks like this:
From: spammer <...>
To: whoever <...>
Message-Id: <...>
Subject: make money fast
blah blah
2. MTA passes message to spam-checking milter. milter (note: not MTA)
synthesises a Received header with the SMTP-session metadata, as we suggest:
Received: from helo (rdns [remoteip]) by MTA for scanning
From: spammer <...>
To: whoever <...>
Message-Id: <...>
Subject: make money fast
blah blah
3. SpamAssassin scans message, and autolearns, using that synthetic Received
header as part of the hashed data for the bayes_seen ID.
4. SpamAssassin passes results back to milter. milter decides to deliver
message. Milter returns "DELIVER" (or whatever) to MTA, which takes over.
5. MTA generates a "real" delivery header:
Received: from helo (rdns [remoteip]) by MTA with ESMTP id kAFKfrDH031427;
Wed, 15 Nov 2006 12:41:53 -0800 (PST)
From: spammer <...>
To: whoever <...>
Message-Id: <...>
Subject: make money fast
blah blah
note the addition of the real ID string representing the delivery.
One possible fix would be to "reserve" an ID string at step (2)
and ensure the synthetic string matches the string generated by the
"real" MTA code in step (5). However that may require major
changes to how MTAs work... most SpamAssassin integration layers
can't mandate that much change to the MTA. Also, there'd need
to be additional code added to revert that change if the message
is rejected at step (4), instead of delivered.
in my opinion, there's a bug here we need to fix, alright. We can't
expect MTAs to make those changes...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
