1) ACCEPTABLE: Server Domain matches RFC 5322 From domain, and RFC 5321 Mail From is missing. HELO is an appropriate proxy for the missing Mail From, especially since a missing Mail From implies a system message, such as a server might need to generate.
2) NOT ACCEPTABLE: Server Domain matches RFC 5322 From domain, but RFC 5321 Mail From is a different domain. All this tells us is that the Mail From domain is a client on that system. Being a client of a hosting service does not give the right to speak for the hosting service. Doug Foster On Tue, Dec 1, 2020 at 5:17 PM John R Levine <[email protected]> wrote: > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > Ticket #1 is about SPF alignment. We need to replace references to 4408 > with 7408, ando clarify what if anything we do with SPF HELO checks if > the MAIL FROM is null. One possibility is to say only MAIL FROM SPF > counts, if you want to align your bounces, sign them. The other is to > explicitly say that HELO alignment is OK on bounces. > > R's, > John > > ================================================================ > > From: Anne Bennett <anne@…> > Date: Fri, 16 Jan 2015 19:10:56 -0500 > Subject: [dmarc-ietf] SPF RFC 4408 vs 7208 > > On Jan 6, Murray S. Kucherawy confirmed fixing the reference for > the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11"). > However, -12 still has, in section "3.1. Identifier Alignment": > For example, [DKIM] authenticates the domain that affixed a > signature to the message, while [SPF] authenticates either > the domain that appears in the RFC5321.MailFrom? portion of > [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom? > is null (in the case of Delivery Status Notifications). > Actually, RFC 7208 states that: > Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence > if both are checked. > > ... and implies that if the first check passes, the second > is unnecessary: > > If a conclusive determination about the message can be made > based on a check of "HELO", then the use of DNS resources to > process the typically more complex "MAIL FROM" can be avoided. > So the RFC5321.EHLO/HELO domain is checked not only if the > RFC5321.MailFrom? is null - in fact in cases where sites have > followed the RFC 7208 recommendation, it will be checked first, > at least by a "pure SPF" implementation. > This means, first of all, that the -12 text above needs fixing. > But also, I'm struggling with what it means for alignment. > I can think of some real-life cases where only one of > HELO or MAIL FROM aligns with RFC5322.From, even though > both would "pass" in a pure SPF check. IMHO, Section > "3.1.2. SPF-authenticated Identifiers" needs to be clarified > to better take HELO into account. > I'd like to see an approach similar to that for DKIM, where it > is explicitly stated that: > a single email can contain multiple DKIM signatures, and it > is considered to be a DMARC "pass" if any DKIM signature is > aligned and verifies. > Similarly, I think that for SPF, it should be considered a pass > if either the MAIL FROM or the HELO is aligned and results in a > pass at the SPF level. > But whether it is decided to take into account both HELO and MAIL > FROM, or whether it is decided to ignore HELO (modulo its use to > construct an artificial MAIL FROM if the latter is null), the text > should IMHO make this clear one way or another, both in "3.1.2. > SPF-authenticated Identifiers": > In relaxed mode, the [SPF]-authenticated domain and > RFC5322.From domain must have the same Organizational Domain. > In strict mode, only an exact DNS domain match is considered > to produce identifier alignment. > > ... and in "4.1. Authentication Mechanisms": > > o [SPF], which authenticates the domain found in an > [SMTP] MAIL command when it is the authorized domain. > In both cases, the text should specifically mention HELO, > and whether to include or exclude a HELO SPF result, in view > of HELO's prominence in RFC 7208. > If it is decided to allow both HELO and MAIL FROM results to be > passed back to DMARC, then in section "6.6.2. Determine Handling > Policy", item 4 should be updated to reflect that as > well._______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
