Subject: [dmarc-ietf] tree walk is experimental

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 09:22:48 -0800

G'day.

The method of finding the organizational domain should be specified 
outside of the base DMARC specification.  I suggested this back during 
the PSD discussion.

There are a number of reasons:

1. There is already an installed base using the PSL.  While I understand 
the desire to move away from it, the change might or might not happen 
and if it does, it will take a potentially long time.  During all of 
that time, field operations will be non-compliant with the DMARC 
specification.

    Note that success for tree walk requires a) receivers to attempt it,
    and b) operational experience to be satisfying. Good ideas often
    turn out not to succeed...  Again, at the very least, it will take
    an unknown amount of time for there to be enough uptake of this
    replacement mechanism.  And the incentives for that uptake are
    frankly not all that clear; do we have solid documentation of
    widespread dissatisfaction with the use of PSL in DMARC?  (I'm not
    asking about the logic, but about the basis for claiming widesprea
    market dissatisfaction.)

2. In spite of the current fashion that encourages use of tree walk, it 
does not have prior field experience and in fact runs contrary to 
long-standing, established practices.  While it might prove good to do 
and even better than PSL, it is, by its nature, an experimental 
mechanism.  Including it inside the base DMARC specification encourages 
treating that base specification as an experiment.

3. The base DMARC specification needs to define the construct of an 
organizational domain and it needs to specify how one is used in DMARC 
operation.  It does /not/ need to specify how to obtain one.  Given that 
we will have (at least) two different methods, it is cleaner and safer 
to partition the 'how' out of the core, leaving only the 'what'.

4. To the extent that there is a view that having tree walk inside the 
base spec somehow encourages or forces adoption, experience tends to 
show that, instead, it makes the transition confusing.  Also, see points 
1 & 2, above.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Seth Blank <[email-masked]>
Date: Wed, 26 Jan 2022 09:30:01 -0800

Yes, this is a core ticket that needs to be addressed:
https://trac.ietf.org/trac/dmarc/ticket/46

I believe right now the group is just dialing in the definition/text, but
there has been broad agreement (I don't remember hearing any disagreement,
but I wouldn't go so far as to call it consensus yet) that everything
related to organizational domain discovery should be moved into a separate
document.

Seth

On Wed, Jan 26, 2022 at 9:23 AM Dave Crocker <[email-masked]> wrote:

> outside of the base DMARC specification.  I suggested this back during the
> PSD discussion.
>
> the desire to move away from it, the change might or might not happen and
> if it does, it will take a potentially long time.  During all of that time,
> field operations will be non-compliant with the DMARC specification.
>
> Note that success for tree walk requires a) receivers to attempt it, and
> b) operational experience to be satisfying.  Good ideas often turn out not
> to succeed...  Again, at the very least, it will take an unknown amount of
> time for there to be enough uptake of this replacement mechanism.  And the
> incentives for that uptake are frankly not all that clear; do we have solid
> documentation of widespread dissatisfaction with the use of PSL in DMARC?
> (I'm not asking about the logic, but about the basis for claiming widesprea
> market dissatisfaction.)
>
> long-standing, established practices.  While it might prove good to do and
> even better than PSL, it is, by its nature, an experimental mechanism.
> Including it inside the base DMARC specification encourages treating that
> base specification as an experiment.
>
> operation.  It does /not/ need to specify how to obtain one.  Given that we
> will have (at least) two different methods, it is cleaner and safer to
> partition the 'how' out of the core, leaving only the 'what'.
>
> base spec somehow encourages or forces adoption, experience tends to show
> that, instead, it makes the transition confusing.  Also, see points 1 & 2,
> above.
>
>
> d/
>
> --
> Dave [email-masked]
> 408.329.0791
>
> American Red [email-masked]
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank * | Chief Product Officer
*e:* [email-masked]
*p:* 415.273.8818

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.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 09:36:49 -0800

> https://trac.ietf.org/trac/dmarc/ticket/46

21 months ago?  as if I'd remember something from 21 minutes ago.  sheesh.

>
> I believe right now the group is just dialing in the definition/text, 
> but there has been broad agreement (I don't remember hearing any 
> disagreement, but I wouldn't go so far as to call it consensus yet) 
> that everything related to organizational domain discovery should be 
> moved into a separate document.

great.  hadn't gotten that vibe from the list discussion but as long as 
the separation is an open point, that's fine.

thanks!

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 26 Jan 2022 13:04:02 -0500

It appears that Dave Crocker  <[email-masked]> said:
>-=-=-=-=-=-

That assumes that the org domain is useful on its own, rather than
just as a tool to help find policy records or to check for relaxed
alignment.

We tried and failed to find a general method to find an organizaional domain
in DBOUND, and I don't think we want to go there again.

>and if it does, it will take a potentially long time. ...

I think we have all agreed that whatever we come up with has to produce
similar results to the current scheme.  I say similar rather than identical,
since the PSL is a moving target.

>long-standing, established practices. ...

RFC 8659 suggests otherwise.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jan 2022 13:04:28 -0500

> related to organizational domain discovery should be moved into a separate

In RFC 7489, the organizational domain does two things relative to policy:

1.  It provides a top point for checking relaxed alignment.

2.  If provides policy for cases where the From domain does not have a DMARC 
record.

In recent discussions around organizational domain, we have mostly been 
discussing the first point, but if this is carved off into a separate draft, 
then the second point needs to go with it as they are intimately connected in 
RFC 7489.

If the chairs want a separate document, I'd be glad to take a shot at drafting 
it.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 10:18:18 -0800

> just as a tool to help find policy records or to check for relaxed

It does?  I don't understand how it assumes that.

> in DBOUND, and I don't think we want to go there again.

So it's a good thing I didn't suggest anything of the sort.

This just leaves the question of why you are introducing it here?

> since the PSL is a moving target.

My concern has nothing to do with equivalent semantics but rather is 
about the pragmatics of transition with parallel field operation, 
duration for gaining traction, and the risk of inadequate uptake.  Sorry 
I wasn't adequately clear about that.

> RFC 8659 suggests otherwise.

Because, yeah, the mere fact that an RFC was issued 2 years ago 
completely reverses established concerns and practice of 35 years...

And I'm sure there is plenty of data about operational uptake and 
comfort with the mechanism, though I didn't see it when searching for 
references to the RFC.

Please provide a point to the field experience that cover the concern I 
raised.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 26 Jan 2022 13:38:33 -0500

> It does?  I don't understand how it assumes that.

If the org domain isn't useful, why would we care how it's defined?

>> We tried and failed to find a general method to find an organizaional 
>> domain in DBOUND, and I don't think we want to go there again.
>

Could you explain in simple language that even I could understand how a 
generic definition of a way to find an org domain is not what DBOUND tried 
to do?

As I'm sure you remember, the late Gervase Markham proposed standardizing 
the PSL in DBOUND, and Casey Decchio and I had ways to put similar info in 
the DNS.  In each case, the idea was that you gave it a domain, it gave 
you back the PSD above that domain.  You know, like we do for org domains.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 10:47:37 -0800

> If the org domain isn't useful, why would we care how it's defined?

Well, now you've completely lost me.  I have no idea what you are 
talking about, nevermind how it it supposed to relate to the rather 
simple point of distinction I suggested, separating what from how.

>>> We tried and failed to find a general method to find an 
>>> organizaional domain in DBOUND, and I don't think we want to go 
>>> there again.
>>
> Could you explain in simple language that even I could understand how 
> a generic definition of a way to find an org domain is not what DBOUND 
> tried to do?

Ahh,  You are claiming I said something about a 'general method'.  I 
didn't.

Since you think otherwise, could you explain in simple language that 
even I could understand how you reached that interpretation of my note?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jan 2022 13:49:59 -0500

> even I could understand how you reached that interpretation of my note?

Or, not to put too fine a point on it, if you two want to discuss DBOUND, I 
think [email-masked] is still active.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 26 Jan 2022 13:54:41 -0500

> Ahh,  You are claiming I said something about a 'general method'.  I didn't.
>
> Since you think otherwise, could you explain in simple language that even I 
> could understand how you reached that interpretation of my note?

Now we're both confused.  When you said "The method of finding the 
organizational domain should be specified outside of the base DMARC 
specification" did that mean it's still unique to DMARC, but we put it in 
a different document?

If so, what's the point of making it separate?  If not, what am I missing?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 11:01:24 -0800

On 1/26/2022 10:54 AM, John R Levine wrote:
> specification" did that mean it's still unique to DMARC, but we put it 
> in a different document?

1. I said it should be specified outside of the base DMARC document.  
That's different from saying what the internals of the separate document 
should contain.  I didn't comment on that.

2. But since you are asking, I think it is pretty easy to specify the 
details of the mechanism in a way that does not require DMARC specific 
text.  Not because it is will or might have more general use -- that 
that's often a collateral benefit -- but because specs should not 
overspecify detail they don't need to.

> If so, what's the point of making it separate?  If not, what am I 

It removes fate-sharing of the core mechanism from the messier component 
mechanism that will have (at least) two very different operational 
designs with the new one being... new and lacking solid field experience 
that gives assurance for uptake.  (Thought I said all that in the 
original note.  Should I have used caps?)

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 11:02:55 -0800

On 1/26/2022 10:49 AM, Scott Kitterman wrote:
> [email-masked]  is still active.

there's nothing in what I posted that has anything to do with dbound or 
possible derivatives.  The introduction of the reference came from a 
creative misreading of my posting.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 26 Jan 2022 14:11:40 -0500

> 2. But since you are asking, I think it is pretty easy to specify the details 
> of the mechanism in a way that does not require DMARC specific text.  Not 
> because it is will or might have more general use -- that that's often a 
> collateral benefit -- but because specs should not overspecify detail they 
> don't need to.

Hm, we're addressing the same problem that DBOND did, but it's not DBOUND. 
Well, OK.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jan 2022 11:23:49 -0800

On 1/26/2022 11:11 AM, John R Levine wrote:
> Hm, we're addressing the same problem that DBOND did, but it's not 
> DBOUND. Well, OK. 

You seem to be, but I'm not.

I'm addressing a documentation issue.  I'm sorry you are having so much 
trouble understanding that.

I've no idea how you came up with a larger and more abstract scope.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 28 Jan 2022 16:45:36 +0100

On Wed 26/Jan/2022 20:01:24 +0100 Dave Crocker wrote:
>>> Since you think otherwise, could you explain in simple language 
>>> that even I could understand how you reached that interpretation of 
>>> my note?
>>
>> specification" did that mean it's still unique to DMARC, but we put 
>> it in a different document?
> 
> That's different from saying what the internals of the separate 
> document should contain.  I didn't comment on that.

I think I see where John's confusion is coming from.  After DBOUND 
experience, it was obvious to him that a tree walk cannot determine 
where the zone cut lies.  Hence replacing the PSL with a tree walk 
obviously implied to him to abandon the concept of organizational domain.

In that case, we wouldn't need to define any concept.  We pick up an 
algorithm and take its outcome, whatever it is.

> overspecify detail they don't need to.

The DMARC-specific detail is the use of role= or psd=/org= tags in 
DMARC records.  These tags can aid tree walking and determination of 
the organizational domain.

Still, since we are writing three documents, adding a forth one to 
specify the mechanism may make sense, especially if it's going to be 
experimental.

> It removes fate-sharing of the core mechanism from the messier 
> component mechanism that will have (at least) two very different 
> operational designs with the new one being... new and lacking solid 
> field experience that gives assurance for uptake.  (Thought I said all 
> that in the original note.  Should I have used caps?)

It's loud and clear, to me at least.  In particular, considerations 
about the uptake of the new mechanism need to take into account both 
the receiver's software implementations and the publishing of walking 
aid tags.  Perhaps there will be hybrid methods for a while.

Best
Ale
--