Bug 7702

Summary: Not detecting all variants of the Hotmail received headers
Product: Spamassassin Reporter: steven.lynch
Component: PluginsAssignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: normal CC: apache, rwmaillists, steven.lynch
Priority: P2    
Version: 3.4.2   
Target Milestone: Undefined   
Hardware: All   
OS: All   
Whiteboard:
Attachments: headers of the example email

Description steven.lynch 2019-03-28 04:05:41 UTC 
Created attachment 5646 [details]
headers of the example email

In lib/Mail/SpamAssassin/Plugin/HeaderEval.pm, in the _check_for_forged_hotmail_received_headers subroutine

There are a number of regex's that are used to detect a valid Received header for messages that originate from Hotmail. The one dealing with 'outbound.protection.outlook.com' needs a small change to allow for the HELO string which may appear in the header.

For example (taken from the original email):

Received: from mail-oln040092003100.outbound.protection.outlook.com (HELO
 NAM02-BL2-obe.outbound.protection.outlook.com) (40.92.3.100) by
 nb1.victas.uca.org.au with ESMTPS (AES256-SHA256 encrypted); 22 Mar 2019
 04:29:59 -0000

The regex does not allow for the presence of the HELO string. The modified regex should only allow for an optional HELO string and therefore there will be no backward compatibility problems with the modified plugin.

I have attached the full list of headers, but the above is probably sufficient in this case. For customer privacy reasons I have excluded the main body of the original email.
Comment 1 steven.lynch 2019-03-28 05:53:03 UTC 
Come to think of it, since the HELO is inserted by the MTA, this allowance might need to be added for some of the other recognition regex's as well.
Comment 2 Henrik Krohns 2019-03-28 06:05:06 UTC 
Is there really no X-OriginatorOrg in your message? The code seems to require that from outlook.com.

Looking at ruleqa it seem these rules are pointless anyway and pain to maintain hardcoded stuff. I would almost vote to remove everything, or consider simpler rule based stuff.
Comment 3 steven.lynch 2019-03-28 06:35:05 UTC 
Hmm, you're right, there is no X-OriginatorOrg header in the message. So either Hotmail have changed the way they are doing things, or perhaps this message was faked after all. Although it definitely originated from a Microsoft owned IP address (40.92.7.67) that reverse resolves to:

   mail-oln040092007067.outbound.protection.outlook.com

So it would seem to have come from the right area.

Either way, I guess this area of the code needs revisiting.
Comment 4 RW 2019-03-29 13:43:28 UTC 

The quoted received header was added by nb1.victas.uca.org.au, so the HELO is irrelevant as the regexes are testing for Microsoft's own formatting.

However, I don't think this code is worth maintaining. It provides two rules:

FORGED_HOTMAIL_RCVD2 which is a test for @hotmail.com addresses that are not relayed through Microsoft servers. Oddly this rule has an S/O that's substantially worse than __FROM_HOTMAIL_COM which just checks for a Hotmail address. It's modest scores have not been updated for almost 10 years when freemail spoofing was much more common. The scores predate even Hotmail's use of DKIM, let alone DMARC.

The other rule is FORGED_HOTMAIL_RCVD  which checks for a forged Hotmail HELO. Hotmail doesn't really exist anymore, the legacy addresses are relayed over the outlook servers. Are there really still legitimate servers that use hotmail in the HELO? I haven't seen it for years. If not then simply checking the untrusted relays for /helo=(?:\S+\.)?hotmail\.com\s/i should be an all-round improvement on the existing perl rule. 

Note that the existing rule checks for \S*hotmail\.com, and so could FP on other domains.