Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

I’d say it’s best practice to have a separate policy subdomains. We should encourage it.foo.example.com’s spoofed by one vendor most likely, so switching vendors isn’t too big a task. No need to roll example.com back to none. Just role foo back. It’s clearly a better way to go. Set things up so when you make changes, you open up a tiny security hole for as short a time as possible. So if dmarcbis exncourages subdomain dmarc policies then let’s encourage that with clear words and clear policies.On Oct 7, 2023, at 11:44 AM, Douglas Foster  wrote:No, this is not a false positive.  The PSL put all of the identifiers in a 2LD organization, which I reviewed and judged to be correct.The problem happens when Mail From u...@bounce.example.com authenticates u...@example.com and both domains have DMARC policies.  Removing the lower policy is the only remedy.   For SPF, this pattern of child-authenticates-parent is quite common.  Hsving multipke DMARC policies is less common. Again, what previous data was presented to justify the consensus that we would see no probems? DougOn Sat, Oct 7, 2023, 1:26 PM Richard Clayton  wrote:-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message 
hgv...@mail.gmail.com>, Douglas Foster 
com> writes

>    So initially, I am asking for a compsrison between my results and 
>    the data used to justify the asserted consensus.

if you published the data (just the right hand side of relevant
addresses is needed) we could check your working ...

>    Was 2% previuosly observed and judged acceptable?  Were the 
>    previous error rates judged acceptable because they were computed 
>    using a different denominator definition?

clearly if you get 10 messages from odd-domain and 10 messages from
Google then you will see a different percentage than someone who gets 3
(or some days 0) messages from odd-domain and 100 from Google ...
but provided odd-domain isn't just sending to you then any large mailbox
provider should have seen enough mail to provide a sensible measure of
the impact by counting domains not %age of overall mail.

>    With our present design, the necessary response to these errors is 
>    for the domain owner to remove intermediate DMARC policies.

that's strange ... isn't the intent of the new scheme to encourage
subdomain owners to add them !

I do wonder if this is the PSL raising its ugly head again. A remarkable
number of the people who have added entries have not understood how they
now need to publish rather more DNS records than previously ...

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZSGUTN2nQQHFxEViEQKHpQCeP4SAEJFQbCG74hSpmKPugIWLWs0An2e5
DMtrmcDBziCPFM9PVB0Vx6dI
=aCqk
-END PGP SIGNATURE-

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

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> 
> On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
>>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:
>>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
 Both approaches have problems.   Stop-at-last enables the walk to exit the 
 current organization and stop on a private registry, for both alignment 
 evaluation and for aggregate report transmission.   This is not a minor 
 problem, even if it is arguably infrequent.
>>> 
>>> The illustrative example in the draft says:
>>> 
>>> _dmarc.a.b.c.d.e.mail.example.com
>>> _dmarc.e.mail.example.com
>>> _dmarc.mail.example.com
>>> _dmarc.example.com
>>> _dmarc.com
>>> 
>>> That is, no stop at all.  In this respect, a psd=n at example.com would 
>>> save a lookup.  However, it is not something that we can recommend, after 
>>> we chose the obscure tag name. >
>> I'm not sure I understand what you're saying...
>> The illustrative example cited is intended to illustrate a full tree walk
>> that follows the steps for a full tree walk that are spelled out in the
>> numbered list just prior to the illustrative example.
> 
> 
> Yup, I'm not criticizing the text (I wouldn't know how to better it).
> 
> Just wondering how to implement it.  It is understood that programs must 
> behave /as if/ they followed the letter of the spec, but don't have to 
> actually do so.

Would it be possible to test these scenarios with a working prototype or some 
other way to provide proof. Due to other obligations I haven’t been able to 
lurk here much but upon coming back I think the tree walk issues touched on 
today are possibly the only things standing in the way of dmarcbis. Though I 
saw there’s a nascent save our PSL movement that I read about. I’m not sure how 
serious or influential this movement is and why they’d feel so strongly that 
they’d step in with somewhat dubious play reviews on the 10 yard line. 

I’m just an observer.

I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect problems 
will be addressed, there’s going to be stress, but ultimately another hack such 
as the hosts file for DNS will become largely irrelevant in the big picture, 
taking the Internet another step out of childhood toward adulthood. That’s a 
good thing even if some things go wrong along the way that need to be fixed or 
mitigated. The Internet is a place where the perfect is often more blatantly 
the enemy of the good.

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