On Thu, Mar 14, 2024 at 4:52 PM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote:
> > 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> wrote: > >> On Mar 14, 2024, at 10:09 AM, Todd Herr <todd.herr= >> 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? > Perhaps some additional cautionary text for Mail Receivers, either added to the above paragraph or just after it, warning against rejecting solely due to SPF -all unless the SPF record is simply "v=spf1 -all"? Such text would be consistent, for example, with M3AAWG's Email Authentication Best Practices <https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf> document. > > > 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. > > > I'm sorry but I'm still not understanding the source of your confusion here. The text we're discussing is pulled from the Domain Owners section, and while it's not explicitly stated, "choosing a DKIM-signing domain" would essentially involve indicating to the sending platform what domain the Domain Owner wants to use in DKIM signing and then publishing a public key in DNS. It is presumed that the sending platform has already built into it the ability to DKIM sign messages based on the Domain Owner's choices. What logic must be coded to support this? -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
