Re: [dmarc-ietf] ARC questions

On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Michael, I think the purpose is stated well enough: Mailing lists want > to keep adding their content to messages, without being blocked by > recipients. This means that they have to provide recipien

Re: [dmarc-ietf] ARC questions

Michael, I think the purpose is stated well enough: Mailing lists want to keep adding their content to messages, without being blocked by recipients. This means that they have to provide recipients with enough information for them to accept the forwarded content. Google and Microsoft seem to

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

> In article you write: > >> One of the points of the tree walk is to get rid of the PSL processing. > > > > The PSL processing is a local lookup on an in-memory suffix tree. How is > > it a > > progress to replace it with a tree walk? A PSL search is lightning faster > > than > > even a sing

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

In article you write: >-=-=-=-=-=- > >On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely wrote: > >> The PSL is the result of a community-maintained effort. ... >I'm curious as to whether this is the consensus opinion of the PSL. It's >my impression that it is not, given the arguments that sup

Re: [dmarc-ietf] ARC questions

On Tue, 24 Nov 2020, Michael Thomas wrote: Our experience also showed that more than one hop is quite common in enterprise deployments, and those are also the places where the most complexity arises. Others shared our experience as well. That's more than one modifying intermediary in *separate

Re: [dmarc-ietf] ARC questions

On 11/24/20 4:56 PM, Brandon Long wrote: On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas > wrote: Our experience also showed that more than one hop is quite common in enterprise deployments, and those are also the places where the most complexity arises. 

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely wrote: > The PSL is the result of a community-maintained effort. They do not > follow > intricate naming restrictions that ccTLDs might theorize, but actively > track > subdomains as they become visible/ noticed. It is remarkably good. > I'm c

Re: [dmarc-ietf] ARC questions

On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas wrote: > > On 11/24/20 3:24 PM, Brandon Long wrote: > > > On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas wrote: > >> >> >> Sorry, changing the auth-res to old-auth-res and dkim signing the >> message would be completely sufficient, and far easier to

Re: [dmarc-ietf] ARC questions

On 11/24/20 3:24 PM, Brandon Long wrote: On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas > wrote: Sorry, changing the auth-res to old-auth-res and dkim signing the message would be completely sufficient, and far easier to understand with a lot less bloat. Al

[dmarc-ietf] Messages passing more than one modifying intermediary?

Does anybody know what percentage of traffic that passes through more than one modifying intermediary in different administrative domains? I know that modifying intermediaries like mailing lists are relatively rare, so I'd think that messages that go through more than one would be extremely

Re: [dmarc-ietf] ARC questions

As Chair- This thread is quickly becoming unproductive and veering to personal attacks, which will not be tolerated. Please engage productively and on the merits, take the conversation elsewhere, or disengage. Seth On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas wrote: > You'd be wrong. The on

Re: [dmarc-ietf] ARC questions

You'd be wrong. The only ad hominem was yours from yesterday and it was I think where *you* dismissed the very question I raised: "Two or more levels of forward are quite common, particularly in large mail systems.  Look at mail coming out of Google and Microsoft's hosted mail and you'll see a

Re: [dmarc-ietf] ARC questions

On 11/23/20 6:04 PM, John Levine wrote: In article you write: What I'm struggling to understand is what having authenticated auth-res >from a previous hop helps. this is what i found: See some of the previous messages. My usual example is a mailing list message that fails DMARC at the final

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

Right. The optimal solution would be to load the list and the lookup algorithm as a shared object. Currently, my filter has its private copy of it. But then I don't reload the filter so often that parsing the file is noticeable. To wit, loading the virus database takes much much longer. In

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue 24/Nov/2020 18:03:51 +0100 John Levine wrote: In article you write: One of the points of the tree walk is to get rid of the PSL processing. The PSL processing is a local lookup on an in-memory suffix tree. How is it a progress to replace it with a tree walk? A PSL search is lightnin

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

Better a correct answer slowly than an incorrect answer quickly. For the existing PSL, it is not just the accuracy of the document itself, but also the accuracy of the parsing process. Is there a well-trusted parser floating around? DF From: dmarc [mailto:dmarc-boun...@ietf.org] On

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue 24/Nov/2020 17:50:20 +0100 Murray S. Kucherawy wrote: On Tue, Nov 24, 2020 at 4:20 AM Alessandro Vesely wrote: If I'm going to go to the effort to download and decode a PSL and find the OD, I'll just use the OD. >>> One of the points of the tree walk is to get rid of the PSL processing.

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/24/2020 9:21 AM, John Levine wrote: With the tree walk, I was thinking that if the tree walk finds a _dmarc record, that acts as the organizational domain, so finance.acme.example can only allow alignment with itself or its descendants. This is different from the way that OD works now, b

Re: [dmarc-ietf] org domain and dns-perimeter draft

I am intrigued by Dave's document. I have not yet read John's. John described this topic as a battle, so I wonder if we need a crash course in the results of those battles before revisiting the topic. One of the issues that did not seem sufficiently addressed was split-mode nodes, where some d

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

In article <9ab0d7b9-2e35-f64b-02ea-a111c10ac...@wisc.edu> you write: >So if acme.example publishes aspf=s adkim=s >It does not prevent finance.acme.example from publishing aspf=r adkim=r >Which would align widgets.acme.example with finance.acme.example even if the >intent was to only align >dele

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

In article you write: >On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote: >> I had one spam message that had 13 parts. It included both "_mta-sts" and >> "mta-sts" in there, as well as >"mail" nine times. The last two parts were the org domain. > >If the message happened to authenticate, ne

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

In article you write: >> One of the points of the tree walk is to get rid of the PSL processing. > >The PSL processing is a local lookup on an in-memory suffix tree. How is it a >progress to replace it with a tree walk? A PSL search is lightning faster >than >even a single DNS lookup, isn't i

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/24/20 9:52 AM, todd.herr=40valimail@dmarc.ietf.org wrote: > On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker > wrote: > > Just to be clear, I'm not challenging the need.  Rather I'm just looking > for text that explains the need.  And I'm not finding it... >

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote: I had one spam message that had 13 parts. It included both "_mta-sts" and "mta-sts" in there, as well as "mail" nine times. The last two parts were the org domain. If the message happened to authenticate, negative reputation is better a

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue, Nov 24, 2020 at 4:20 AM Alessandro Vesely wrote: > > If I'm going to go to the effort to download and decode a PSL and find > the OD, I'll just use the OD. > > > > One of the points of the tree walk is to get rid of the PSL processing. > > The PSL processing is a local lookup on an in-mem

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue, Nov 24, 2020 at 7:56 AM Dave Crocker wrote: > Perhaps I am misreading these, but I see them only as 'what' and 'how', > not 'why'. The 'why' is important. It is often noted in our > discussions, but seems to be missing from the spec. Seems like something the -bis document should tackl

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/24/2020 7:52 AM, Todd Herr wrote: For point 1, this is from Section 6.6.3, Policy Discovery: ... For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers: Perhaps I am misreading these, but I see them only as 'what' and 'how', not 'why'.  The 'why' is important.  It is of

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker wrote: > Just to be clear, I'm not challenging the need. Rather I'm just looking > for text that explains the need. And I'm not finding it... > > On 11/24/2020 7:28 AM, Todd Herr wrote: > > There are two reasons (at least) for needing the Organizati

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

Just to be clear, I'm not challenging the need.  Rather I'm just looking for text that explains the need.  And I'm not finding it... On 11/24/2020 7:28 AM, Todd Herr wrote: There are two reasons (at least) for needing the Organizational Domain, and they are discussed in RFC 7489: 1. DMARC al

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Tue, Nov 24, 2020 at 10:15 AM Dave Crocker wrote: > On 11/24/2020 7:00 AM, Joseph Brennan wrote: > > I will ask why the recipient system should look up anything but the > > dmarc record for the specific domain in the Header From. > > > Hmmm. Unless I've missed it, the DMARC spec does not expl

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/24/2020 7:00 AM, Joseph Brennan wrote: I will ask why the recipient system should look up anything but the dmarc record for the specific domain in the Header From. Hmmm.  Unless I've missed it, the DMARC spec does not explain the reason for needing the Organizational Domain. d/ -- D

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

I will ask why the recipient system should look up anything but the dmarc record for the specific domain in the Header From. In some cases looking up related domains is useful, and in some cases it can lead to disruption. We don't look up SPF records for related domains, because they are deliberat

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

I was sort of curious yesterday and checked as well. Most were four or less. I had a number that were five or six. A couple dozen were at eight. I had one spam message that had 13 parts. It included both "_mta-sts" and "mta-sts" in there, as well as "mail" nine times. The last two parts we

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On Mon 23/Nov/2020 22:38:46 +0100 John Levine wrote: In article <9f388e33-c15d-9fcc-e9d3-d7719288f...@gmail.com> you write: On 11/23/2020 1:04 PM, Jesse Thompson wrote: I meant to suggest that the requirement for a tree walk would be that the Organizational Domain would need to have that in its