Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Hector Santos <[e-mail]>]

> On Mar 14, 2024, at 4:02 PM, Todd Herr <todd.herr=[e-mail]> wrote:
> 
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos <hsantos=[e-mail] <mailto:[e-mail]>> wrote:
>>> On Mar 14, 2024, at 10:09 AM, Todd Herr <todd.herr=[e-mail] <mailto:[e-mail]>> 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