Hi,
Yes - the "From" header is just for the mail client (such as Outlook). The "real" sender is typically provided in the Sender or X-Sender header. Here is an example using different versions of CDO: a) Up to Win 2000 Server and prior Reply-To: <authorspreferredem...@somecorporatedomain.com> From: <authors...@somepdadomain.com> Sender: <postmas...@anamera.net> To: <customer.serv...@anamera.net> The MAIL FROM was: postmas...@anamera.net b) Win 2003 and up (Win 2000 Server supports either) Reply-To: <authorspreferredem...@somecorporatedomain.com> From: <authors...@somepdadomain.com> X-Sender: <postmas...@anamera.net> To: <customer.serv...@anamera.net> The MAIL FROM was: postmas...@anamera.net So - the most appropriate logic for FROMNOMATCH would have been: - if X-Sender header exists, compare THAT against MAIL FROM - if Sender header exists, compare THAT against MAIL FROM - else, compare From header against MAIL FROM Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Colbeck, Andrew Sent: Thursday, July 15, 2010 2:36 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] A small Junkmail enhancement suggestion David, are you there? The FROMNOMATCH test introduced in 2006 checks whether the MAILFROM matches the From: header. I suggest an enhancement to reduce false positives: that the FROMNOMATCH is suppressed if the Sender: header line is present. The Sender: header line is used to indicate that the sending mail system knows that the actual sender is different from the cosmetic From: line. The result in, say, Microsoft Outlook, is that the From: line will show "%MAILFROM% on behalf of %From: field contents%". The Sender: line receives a bare mention here: http://en.wikipedia.org/wiki/E-mail_header The FROMNOMATCH should also be suppressed if the MAILFROM is <>. I suspect that VERP addresses should also be excerpted, because as with the Sender: header, the envelope/MAILFROM is expected to not match the From: header. Here's the Wikipedia article on VERP: http://en.wikipedia.org/wiki/Variable_envelope_return_path There may be a problem with VERP if there is no clear winner or winners in the formatting; if there are VERP formats that are intended to be interpreted by software instead of humans, then those formats make good exceptions to FROMNOMATCH. As an example of what is too vague and relies on the human being is the huge variety of mailing list, return, and bounce formats in the MAILFROM. I see a lot of bounces that begin the MAILFROM with "bounces", "bounce", "bo-" or put bounce in the fully qualified domain name. The only one I know of that is consistent is the "prvs=.+=" prefix by BATV: http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation Reducing the incidence of FROMNOMATCH in the subjective bounce formattings may be too much of a custom configuration to maintain, and would make a decent "combo" test. I have been using FROMNOMATCH with a tiny weight since its inception, adding more weight in combination tests. I recently looked at my Declude logs, and found that FROMNOMATCH triggered 10:1 on ham:spam, that is, the spammers are now more likely to match the envelope and From: header (even though it's probably a fake address anyway). My statistic has to be taken with a grain of salt; I use Alligate in front of my Declude, so my results are skewed by omitting lots of the spam from zombie hosts. tldnr: Exclude from the FROMNOMATCH test when the MAILFROM is "<>", or when the valid Sender: line is also in the header, or MAILFROM is in BATV or recognizable VERP format. Andrew. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
