The way it works in Office 365 is this: 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) when doing the DMARC alignment check for SPF.
We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found this to be a problem. I don't know how it works in Hotmail (although I should) but it is moving over to the Office 365 infrastructure over the next several months anyhow so it will be the same. -- Terry -----Original Message----- From: dmarc [mailto:[email protected]] On Behalf Of Franck Martin Sent: Thursday, January 22, 2015 3:58 PM To: R E Sonneveld Cc: [email protected]; Michael Jack Assels Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it if you send a bounce, and usually some MTAs have trouble to sign the bounce they generate (not anymore true with postfix but a bit tricky to setup), then the only way to recover the message is to ensure there is an SPF aligned on the string presented by HELO. So basically, I would say DMARC takes only the result of the check_host for the MAIL FROM entity which contains the postmaster@helo if the RFC5321.mailfrom is empty. Murray, I think the elegant way in DMARC to refer to RFC7208 is this. "DMARC uses only the result of the check_host() applied on the MAIL FROM entity as defined by RFC7208. The MAIL FROM entity is the one used for alignment checking.". If I recall the operational test created by Tim, were checking these cases: http://dmarc-qa.com/ (2.1) We all ran these tests during inter-op for conformance. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
