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

[Scott Kitterman <[e-mail]>]

On Thursday, March 14, 2024 1:59:58 PM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote:
> > On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> >> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> >>> [...]
> >>> 
> >>> In the ticket, I propose the following replacement text:
> >>> 
> >>> ==================================================
> >>> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
> >>> take full advantage of DMARC, a Domain Owner MUST first ensure that
> >>> either
> >>> SPF or DKIM authentication are properly configured, and SHOULD ensure
> >>> that
> >>> both are.
> >>> 
> >>> 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.
> >>> ==================================================
> >> 
> >> Wouldn't you at least add "trusted",  "ensure an SPF pass verdict for all
> >> known, trusted sources of mail"?  To avoid mandating an insecure
> >> behavior.
> >> Consider:
> >> 
> >> _ Hey dude, they're spoofing your domain with a tide of phishing.
> >> 
> >> _ How come?
> >> 
> >> _ You have an include:phisherman.example in your SPF.  Remove it.
> >> 
> >> _ No, since they occasionally send a true message from us, the RFC says I
> >> MUST keep it.
> 
> [...]
> 
> > I think that's issue 135, not this one.
> 
> SPF it treated in multiple places.  We cannot warn against a bad practice in
> one place (135) and recommend it unconditionally in another (132).

That is exactly how one handles Security Considerations.  So 132 says do SPF.  
Security Considerations gives you stuff to think about how you do SPF.  There's 
not need to embed mitigations for the considerations throughout the draft 
(someone with more IETF experience than me, please correct me if I'm wrong 
about this).

Scott K