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

2024-03-15 Thread Alessandro Vesely 

On Thu 14/Mar/2024 20:23:01 +0100 John Levine wrote:

It appears that Scott Kitterman   said:

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).


If you're going to provide implementation advice for SPF, which I still think is
a bad idea, security considerations is indeed the least bad place to do it.



I agree.

The point here is not to give a questionable MUST.  Telling people they MUST 
grant a pass to /every/ source is questionable, isn't it?



Best
Ale
--






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread Todd Herr 
On Thu, Mar 14, 2024 at 4:52 PM Hector Santos  wrote:

>
> On Mar 14, 2024, at 4:02 PM, Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>> On Mar 14, 2024, at 10:09 AM, 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

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

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

2024-03-14 Thread Hector Santos 

> On Mar 14, 2024, at 4:02 PM, Todd Herr 
>  wrote:
> 
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>>> On Mar 14, 2024, at 10:09 AM, Todd Herr 
>>> >> > 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

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

2024-03-14 Thread Todd Herr 
On Thu, Mar 14, 2024 at 3:25 PM Hector Santos  wrote:

> On Mar 14, 2024, at 10:09 AM, 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.


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.

If one wants to configure DKIM for DMARC, one MUST choose a DKIM signing
domain that aligns with the Author Domain, mustn't one? Saying SHOULD
choose an aligned DKIM domain means that the Domain Owner can choose not to
choose an aligned DKIM domain, and that won't be configuring DKIM for DMARC.

-- 

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

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

2024-03-14 Thread Hector Santos 
> On Mar 14, 2024, at 10:09 AM, 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.

+1

> 
> 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,  

> 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,

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread John Levine 
It appears that Scott Kitterman   said:
>> 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).

If you're going to provide implementation advice for SPF, which I still think is
a bad idea, security considerations is indeed the least bad place to do it.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread Scott Kitterman 
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



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread Alessandro Vesely 

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).



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread Scott Kitterman 
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.
> 
> > [...]
> > 
> > Further notes on the threads that gave rise to this ticket:
> > - I do not believe that recommending the use of the ? modifier in an
> > SPF
> > record configured for DMARC is appropriate, since as I understand the
> > ?
> > modifier, the result produced is not "pass", but rather "neutral",
> > which is
> > the same as "none". Therefore, an SPF record using ? would not produce
> > an
> > aligned pass to be used with DMARC. I am willing to be convinced that
> > I'm
> > wrong here.
> 
> The drastic solution for those who unwittingly chose a non-filtering
> provider is to remove the SPF record altogether.  The compromise is to use
> the neutral qualifier.  If we mention that —which I think we should— we
> should also add that DKIM is necessary for such mail flows.

I think that's issue 135, not this one.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread Alessandro Vesely 

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.




[...]
Further notes on the threads that gave rise to this ticket:

- I do not believe that recommending the use of the ? modifier in an SPF
record configured for DMARC is appropriate, since as I understand the ?
modifier, the result produced is not "pass", but rather "neutral", which is
the same as "none". Therefore, an SPF record using ? would not produce an
aligned pass to be used with DMARC. I am willing to be convinced that I'm
wrong here.



The drastic solution for those who unwittingly chose a non-filtering provider 
is to remove the SPF record altogether.  The compromise is to use the neutral 
qualifier.  If we mention that —which I think we should— we should also add 
that DKIM is necessary for such mail flows.



Best
Ale
--








___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2024-03-14 Thread Todd Herr 
On Thu, Mar 14, 2024 at 10:22 AM Scott Kitterman 
wrote:

>
> I think MUST do SPF or DKIM, SHOULD do SPF, to do SPF MUST do xxx, SHOULD
> do
> DKIM, to do DKIM MUST do yyy is reasonable (that's how I parsed your
> proposed
> changes, is that right?).  I think it's an improvement and assuming I am
> reading it correctly, I support the change.
>

That is the gist of the text I've proposed, yes.

[rest snipped for further discussion when issue is opened and reported to
list]

-- 

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

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

2024-03-14 Thread Scott Kitterman 
On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote:
> Colleagues,
> 
> After reviewing the "Another point SPF advice" thread and Murray's separate
> post re: SHOULD vs. MUST, I have opened issue 132 on the topic:
> 
> The current text of section 5.5.1, Publish and SPF Policy for an Aligned
> Domain, reads:
> 
> ==
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376]], in order to
> take full advantage of DMARC, a Domain Owner SHOULD first ensure that SPF
> and DKIM authentication are properly configured. As a first step, the
> Domain Owner SHOULD choose a domain to use as the RFC5321.MailFrom domain
> (i.e., the Return-Path domain) for its mail, one that aligns with the
> Author Domain, and then publish an SPF policy in DNS for that domain. The
> SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict
> for all known sources of mail for the RFC5321.MailFrom domain`
> ==
> 
> 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.
> ==
> 
> In addition, the last paragraph in section 5.5.2, Configure Sending System
> for DKIM Signing Using an Aligned Domain, reads:
> 
> ==
> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain
> in the DKIM-Signature header) that aligns with the Author Domain.
> ==
> 
> 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.
> ==
> 
> Further notes on the threads that gave rise to this ticket:
> 
>- I do not believe that recommending the use of the ? modifier in an SPF
>record configured for DMARC is appropriate, since as I understand the ?
>modifier, the result produced is not "pass", but rather "neutral", which
> is the same as "none". Therefore, an SPF record using ? would not produce
> an aligned pass to be used with DMARC. I am willing to be convinced that
> I'm wrong here.
>- That said, I think there is room for discussion of too-permissive SPF
>records and the  cross-user forgery discussed in RFC 7208 Section 11.4,
> and I will open a separate issue for that to expand on section 8.1

I think MUST do SPF or DKIM, SHOULD do SPF, to do SPF MUST do xxx, SHOULD do 
DKIM, to do DKIM MUST do yyy is reasonable (that's how I parsed your proposed 
changes, is that right?).  I think it's an improvement and assuming I am 
reading it correctly, I support the change.

Relative to the further notes section:

I think we need to do something about this.  For SPF, there's a trade off 
available when including third parties in your SPF record that allows you to 
have them not fail SPF, but not be aligned for DMARC purposes (the ? 
qualifier).  It's a trade off and that trade off should be described.

Third parties are always a risk.  If you set up DKIM signing for a third party 
and they sign mail from your domain that you didn't send, you'll get the exact 
same issue.  It's fundamentally the same problem.  Just because we aren't 
seeing scads of this at the moment, doesn't mean we should ignore it.

I'll leave this just as a thought for now, since we should discuss it in the 
other issue, but I think this discussion probably belongs in security 
considerations.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc