On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote: > On Thu, Jan 21, 2021 at 4:24 AM Alessandro Vesely <[email protected]> wrote > > > I agree that the spec needs some text somewhere to counter the passage in > > Section 2.3 of RFC 7208. This, methinks, is the intended semantics of the > > second paragraph of section 3.1.2 of dmarcbis: > > > > OLD: > > Note that the RFC5321.HELO identity is not typically used in the > > context of DMARC (except when required to "fake" an otherwise null > > reverse-path), even though a "pure SPF" implementation according to > > [RFC7208] would check that identifier. > > > > I'd rather replace that paragraph and leave item 4 of Section 6.6.2 as > > is. For > > a possibly less confusing wording: > > > > NEW: > > Even tough a "pure SPF" implementation, according to [RFC7208], would > > avoid to check the RFC5321.MailFrom identity if the RFC5321.HELO was > > conclusively determined to pass, DMARC authentication requires the > > authenticated identity to be aligned. > > May I propose that the section labeled "SPF-Authenticated Identifiers" be > rewritten as follows: > > CURRENT: > > DMARC permits Identifier Alignment, based on the result of an SPF > authentication, to be strict or relaxed. > > In relaxed mode, the [SPF > <https://tools.ietf.org/html/rfc7489#ref-SPF>]-authenticated domain > and RFC5322 <https://tools.ietf.org/html/rfc5322>.From > domain must have the same Organizational Domain. In strict mode, > only an exact DNS domain match is considered to produce Identifier > Alignment. > > Note that the RFC5321 <https://tools.ietf.org/html/rfc5321>.HELO > identity is not typically used in the > context of DMARC (except when required to "fake" an otherwise null > reverse-path), even though a "pure SPF" implementation according to > [SPF <https://tools.ietf.org/html/rfc7489#ref-SPF>] would check > that identifier. > > For example, if a message passes an SPF check with an > RFC5321 <https://tools.ietf.org/html/rfc5321>.MailFrom domain of > "cbg.bounces.example.com", and the address > portion of the RFC5322 <https://tools.ietf.org/html/rfc5322>.From > field contains "[email protected]", > the Authenticated RFC5321 > <https://tools.ietf.org/html/rfc5321>.MailFrom domain identifier and > the > RFC5322 <https://tools.ietf.org/html/rfc5322>.From domain are > considered to be "in alignment" in relaxed > > mode, but not in strict mode. > > > > NEW: > > DMARC permits Identifier Alignment, based on the result of an SPF > > authentication, to be strict or relaxed. > > > In relaxed mode, the [@!RFC3986]-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. > > > For example, if a message passes an SPF check with an > > RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address > > portion of the RFC5322.From field contains "[email protected]", > > the Authenticated RFC5321.MailFrom domain identifier and the > > RFC5322.From domain are considered to be "in alignment" in relaxed > > mode, but not in strict mode. In order for the two identifiers to > > be considered "in alignment" in strict mode, the domain parts would > > have to be identical. > > > The reader should note that SPF alignment checks in DMARC rely solely > > on the RFC5321.MailFrom domain. This differs from section 2.3 of > [@!RFC7208], > > which recommends that SPF checks be done on not only the "MAIL FROM" > > but also on a separate check of the "HELO" identity.
I think this is fine, but there is a subtlety to be aware of. If you look at RFC 7208 Section 2.4, when Mail From is null, postmaster@HELO is the mail from for SPF purposes. DMARC really can't change that. As a result, there are cases where Mail From results actually are derived from HELO and it's unavoidable. I believe the proposed text is clear enough about not using separate HELO identity results and that's appropriate. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
