> On Mar 14, 2024, at 4:02 PM, Todd Herr > <todd.herr=40valimail....@dmarc.ietf.org> wrote: > > On Thu, Mar 14, 2024 at 3:25 PM Hector Santos > <hsantos=40isdg....@dmarc.ietf.org <mailto:40isdg....@dmarc.ietf.org>> wrote: >>> On Mar 14, 2024, at 10:09 AM, Todd Herr >>> <todd.herr=40valimail....@dmarc.ietf.org >>> <mailto:40valimail....@dmarc.ietf.org>> wrote: >>> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as >>> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail >>> that aligns with the Author Domain, and then publish an SPF policy in DNS >>> for that domain. The SPF record MUST be constructed at a minimum to ensure >>> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom >>> domain. >> >> A major consideration, Todd, is receivers will process SPF for SPF without >> DMARC (payload) considerations. IOW, if SPF is a hardfail, we have SMTP >> processors who will not continue to transmit a payload (DATA). >> >> DMARCBis is making a major design presumption receivers will only use SPF as >> a data point for a final DMARC evaluation where a potentially high overhead >> payload was transmitted only to be rejected anyway, > > I don't necessarily think your assertion is true here, or at least I'd submit > that DMARCbis and RFC 7489 aren't approaching this subject any differently. > > Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two > paragraphs, the second of which reads: > > Some receiver architectures might implement SPF in advance of any > DMARC operations. This means that a "-" prefix on a sender's SPF > mechanism, such as "-all", could cause that rejection to go into > effect early in handling, causing message rejection before any DMARC > processing takes place. Operators choosing to use "-all" should be > aware of this.
Yes, I agree. I am only reminding the community SPF can preempt DMARC with a restrictive hardfail policy. Does DMARCBis integrate the tag to delay SPF failures? > > DMARCbis contains the same two paragraphs with no change to the text, other > than the section is now numbered 8.1. > >> >>> In the ticket, I propose the following new text: >>> >>> ================================================== >>> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing >>> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with >>> the Author Domain. >>> ================================================== >> >> In order to maximize security, the Domain Owner is REQUIRED to choose a ….. >> >> Is REQUIRED the same as MUST? I think SHOULD or MUST is fine as long as we >> specify the reason it is required, > > I'm not understanding the comment you're making here, as I don't see the word > "REQUIRED" in anything I wrote. For any protocol, there are “Protocol Requirements,” A MUST or SHOULD is a “Requirement” for proper support, So I just wanted to just note that it can stated another way. Developers need a Requirements Section that allow us to code the logic, Its getting pretty confusing for implementors. — HLS
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
