[dmarc-ietf] (7.1?) DKIM-only authentication

2022-02-11 Thread Douglas Foster
I know that we took out the reference to default policy at my request, and I think it was in section 7.1. But subsequent discussion helped me to understand objectives that were not clear to me in the previous text. I think we need to re-insert something specific about domain owners that want DK

[dmarc-ietf] 4.6 Reverse Tree Walk problems

2022-02-11 Thread Douglas Foster
Using the reverse tree walk for alignment can become disastrous if a PSD publishes a policy record without the PSD=Y flag. Worse yet, organizations would be powerless to defend against its harm. To prent this harm, the alignment tree walk needs to proceed in the upward direction only. Additional

Re: [dmarc-ietf] 7.1 SPF -ALL

2022-02-11 Thread Alessandro Vesely
On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote: This section implies that publishing SPF -ALL is a risky move, which is made worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded without MAILFROM rewrite and (b) the evaluator does not implement DMARC. My reading of

Re: [dmarc-ietf] 7.1 SPF -ALL

2022-02-11 Thread Dotzero
On Fri, Feb 11, 2022 at 7:19 AM Alessandro Vesely wrote: > On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote: > > This section implies that publishing SPF -ALL is a risky move, which is > made > > worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded > > without MAILFROM r

Re: [dmarc-ietf] (7.1?) DKIM-only authentication

2022-02-11 Thread Ken O'Driscoll
No. “?all” in an SPF record is a negative signal to many filters and a quick way to the spam folder. It also exposes the domain to abuse unconnected with DMARC. If a sender intentionally relies on DKIM-only alignment, then that’s their decision. Making any recommendations as to what their SPF r

Re: [dmarc-ietf] (7.1?) DKIM-only authentication

2022-02-11 Thread Dotzero
On Fri, Feb 11, 2022 at 3:14 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I know that we took out the reference to default policy at my request, and > I think it was in section 7.1. But subsequent discussion helped me to > understand objectives that were not clear to me in t

Re: [dmarc-ietf] 7.1 SPF -ALL

2022-02-11 Thread Benny Pedersen
On 2022-02-11 08:57, Douglas Foster wrote: This section implies that publishing SPF -ALL is a risky move, which is made worse by DMARC. SPF -ALL is a only risk when (a) the message is forwarded without MAILFROM rewrite and (b) the evaluator does not implement DMARC. +1 Rather than telling s

Re: [dmarc-ietf] 7.1 SPF -ALL

2022-02-11 Thread John Levine
It appears that Dotzero said: >> I agree with Ale. Further, it is not as if we are considering this in a >vacuum. Since originally being made public, DMARC has been widely >implemented and it has not been identified that this (early reject on SPF >-all) has been a significant or even an insignifi

Re: [dmarc-ietf] 7.1 SPF -ALL

2022-02-11 Thread Benny Pedersen
On 2022-02-11 17:25, John Levine wrote: A bare -all is clearly a special case, the converse of null MX, that means no mail at all. I agree the current wording is fine. nullMX is supported from all mta, but spf is lotto ___ dmarc mailing list dmarc@i

Re: [dmarc-ietf] 4.6 Reverse Tree Walk problems

2022-02-11 Thread Alessandro Vesely
On Fri 11/Feb/2022 09:29:07 +0100 Douglas Foster wrote: Using the reverse tree walk for alignment can become disastrous if a PSD publishes a policy record without the PSD=Y flag.  Worse yet, organizations would be powerless to defend against its harm.   To prent this harm, the alignment tree wa

[dmarc-ietf] Figuring out the tree walk

2022-02-11 Thread John Levine
It appears that Alessandro Vesely said: >I think it is already clear to the WG that the tree walk is screwed up. Yes, we know we have to rewrite sections 4.5 and 4.6. I think there are 2 1/2 situations we need to look at. The first is finding the policy record for a domain that does not have

Re: [dmarc-ietf] 7.1 SPF -ALL

2022-02-11 Thread Douglas Foster
I don't see that the current language is in any way limited to the soecial case of only -ALL. I read it as a general warning. On Fri, Feb 11, 2022, 11:26 AM John Levine wrote: > It appears that Dotzero said: > >> I agree with Ale. Further, it is not as if we are considering this in a > >vacu

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

2022-02-11 Thread Elizabeth Zwicky
> On Jan 25, 2022, at 10:35 AM, John R Levine wrote: > > Do we have any stats on how often real mail depends on sibling alignment? If > nobody actually uses it, the spec would be simpler if we could take it out. Stats are tricky, but here are some senders using sibling alignment like From dom

Re: [dmarc-ietf] Organizational Domain

2022-02-11 Thread Dave Crocker
Barry, Your note underscored the lack of interest in engaging in discussion of the original substance to my posting.  So I will of course drop further attempts at improving the working group's documentation effort. However your note also underscored a basic misunderstanding in rules, process