Re: [dmarc-ietf] Organizational Domain

[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, and professional conduct.  I think that the working group 
archive needs to include a counter, lest the casual reader think that 
you note was a constructive exercise in authority.



On 1/31/2022 10:15 AM, Barry Leiba wrote:

2. Your 'for the sake of' is uncalled for and dismissive.  Please stop
doing that.  Attempts to be dismissive are a popular debating
technique in the IETF, but they are counter-productive, as well as
unprofessional.

Two things here:
First, please do not admonish participants for their behaviour: that's
for the chairs to do, and you should feel free to call things out to
us privately.  It's too easy for discussions to degenerate when we
move them away from the technical arguments.


First, there is no rule requiring that someone, who is being mistreated 
publicly, is prohibited from responding publicly.


Nor should there be.

The IETF has a long track record of handling mistreatment slowly and 
poorly, or not at all.  The current case is merely one more example.


Over time, the more grotesque examples of mistreatment have reduced, 
though they have far from disappeared.  What has remained is permission 
to ignore the substance of what is said, to dismiss it out of hand, or 
to misrepresent it cavalierly.


This leaves IETF discussion groups as distinctly friendly to markedly 
unprofessional conduct.  The best that can be said about changes over 
time is that conduct has generally moved from gross, direct, personal 
attacks, to passive aggressive attacks.


In practical terms this leaves the target of the misbehavior on their own.



Second, the chairs don't find Scott's comment to be at all dismissive,
as the "for the sake of" sentence needs to be taken in the context of
the subsequent sentence that explains that Scott doesn't think you've
given a suitable rationale for the proposed change.


Taking his subsequent sentence is pretty much irrelevant.  It does not 
establish context, since the real context is established by the note he 
was responding to, which you do not cite.


It is one thing to disagree with the the reasons I offered in that 
original note, but quite another to pretend none were provided.


Casting his characterization of my proposal as 'uncalled for and 
dismissive' was precise, accurate and, frankly, restrained. It simply is 
not professional to treat a participant disrespectfully like he did.  A 
view that it is not disrespectful, again, underscores the systemic 
problem here.  It creates a hostile work environment that discourages 
others from participating.


It's also striking that my opinion of 'uncalled for and dismissive' is 
of more concern to you than his misrepresentation of fact.




Rather, you are demanding justifications such as hard data to support
opinions... the sort of hard data that you, yourself are not providing
to support your own opinions.  We see *that* as being dismissive and
unhelpful in progressing the discussion.


Since you offer no specific examples, I'm left to guess what you are 
referring to.  Tsk.


Perhaps you meant my asking Levine to explain his tautology that a PSD 
can't be an Organizational Domain?


Perhaps you meant my taking exception to the circular logic Kitterman used?

Perhaps it is my asking for detail, where broad assertions are made?

But, again, I really don't know what 'hard data' I might have provided, 
but didn't, nor what hard data I was 'demanding'.  I suppose it would be 
indelicate to 'demand' that you provide hard data of my 
unreasonableness.  So, I won't.




1. For this topic, they are irrelevant. There is nothing in the
charter that says terminology must be preserved.  Interoperability is
not endangered by changes in terminology.

My opinion is that interoperability might well be endangered by
changes in terminology, if it results in older and newer
implementations differing in how they handle things based on those
differences in terminology.  To the point at hand, though, that
opinion seems to be what Scott and John are also raising, and which
you are dismissing.


Sure.  And while you clearly intended that paragraph to be relevant, it 
isn't.  Remember your interest in context?  You ignored that here.  Too.


First my language was not nearly as generic as you imply.

Second, the premise is that the term "Organizational Domain" is 
inextricably tied to a fine-grained technical definition, and that it 
has such deeply ingrained, established use, as to be dangerous to 
modify.  Except that premise is an assumption, not a demonstrated fact. 
It's not that the basic concern is unreasonable.  It's that the flat 
assertion of serious danger is unfounded.


And they nicely ignored my attempts to distinguish 

Re: [dmarc-ietf] Organizational Domain

[Alessandro Vesely]

On Tue 01/Feb/2022 00:01:33 +0100 Dotzero wrote:

On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely  wrote:


(This message is not going to be accepted by the IETF today, so I CC John too)


Why wouldn't your email be accepted?



I messed around with the DNS and reverse IP wasn't resolving —thanks for asking.



On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:

3. The role of the function that uses the PSD and the role of the
function that does a tree walk are identical.  Since you apparently feel
otherwise, please explain.


A PSD is potentially useful for DMARC policy determination if no policy exists
for the exact domain or the organizational domain.  It is not useful for
evaluating relaxed alignment.  Only the organizational domain can be used for
that.  So I do not think you are correct.


The RFC  9091 does not contain the word 'relaxed', so I'm curious about the
basis for your assertion of the limitation.


Let me ask if the following scenario is possible at all:

.BANK admins decide to setup a DKIM signing service for .bank domains.
They register dkim.bank, and accept and relay messages originating from
their customers, signing them with d=dkim.bank.  (Compare to
onmicrosoft.com?) >>
They may consider that a tangible way to protect .bank domains.

Will that work to validate, say, mail From: acco...@havenbank.bank?


Let's be realistic, any organization providing a DKIM signing service (but
why would banks divert their mail flows to go through such a service?) can
easily sign in an aligned manner for any unique domain. I did this for
multiple domains (about 6,000) with different mail systems at various times
(Ironport, Message Systems, etc). If such a service or system couldn't sign
for unique domains on the fly, it shouldn't be used.



Perhaps it could be a marketing hint, to demarcate (or do you say demark?) all 
mail from .bank.  I don't think it is a good idea, as it would conflate all 
those banks with one another.  I asked the question to see more clearly where 
the WG stands about ORG vs. PSD differences.  As a conclusion, it seems that 
nobody here thinks PSDs can be used for alignment.


To avoid BEC attacks, it is necessary to distinguish PSDs from ORGs.  If there 
are organizations that lease/rent or otherwise provide subdomains as part of 
their commercial offerings, they should be categorized as PSDs.  This is the 
duty that the PSL has been involved in.  Relaying on psd=, a tree walk can work 
without the PSL if we assume that all PSDs duly set that flag, which is not 
going to happen.




The reality is that people are trying to jump through all kinds of hoops in
support of a bad idea.



For onmicrosoft.com, it looks as if they believe that the value of a DKIM 
signature can be recognized even without referring to DMARC.




Best
Ale
--






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

Re: [dmarc-ietf] Organizational Domain

[Dotzero]

On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely  wrote:

> (This message is not going to be accepted by the IETF today, so I CC John
> too)
>

Why wouldn't your email be accepted?

>
> On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
> >>> 3. The role of the function that uses the PSD and the role of the
> >>> function that does a tree walk are identical.  Since you apparently
> feel
> >>> otherwise, please explain.
> >>
> >> A PSD is potentially useful for DMARC policy determination if no policy
> exists
> >> for the exact domain or the organizational domain.  It is not useful for
> >> evaluating relaxed alignment.  Only the organizational domain can be
> used for
> >> that.  So I do not think you are correct.
> >
> > The RFC  9091 does not contain the word 'relaxed', so I'm curious about
> the
> > basis for your assertion of the limitation.
>
>
> Let me ask if the following scenario is possible at all:
>
> .BANK admins decide to setup a DKIM signing service for .bank domains.
> They
> register dkim.bank, and accept and relay messages originating from their
> customers, signing them with d=dkim.bank.  (Compare to onmicrosoft.com?)
>
> They may consider that a tangible way to protect .bank domains.
>
> Will that work to validate, say, mail From: acco...@havenbank.bank?
>
> Let's be realistic, any organization providing a DKIM signing service (but
> why would banks divert their mail flows to go through such a service?) can
> easily sign in an aligned manner for any unique domain. I did this for
> multiple domains (about 6,000) with different mail systems at various times
> (Ironport, Message Systems, etc). If such a service or system couldn't sign
> for unique domains on the fly, it shouldn't be used.


The reality is that people are trying to jump through all kinds of hoops in
support of a bad idea.

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

Re: [dmarc-ietf] Organizational Domain

[Douglas Foster]

No that will not work.

A TLD is always a PSD, and PSDs cannot be used for alignment.
 Domain1.bank and Dkim.bank are considered part of different administrative
domains.

I am also recommending that we move away from sister-domain alignment.   If
adopted, then Domain1.OrgDomain and Dkim.OrgDomain would also fail to be
aligned.

>From a security standpoint, a signing service does not make much sense to
me.   The signing service has to do source authentication to ensure that
signing would be appropriate.   If the source domain can successfully
authenticate itself to the signing service, it should also be able to
authenticate itself to the intended recipient directly, without the help of
the signing service.  DKIM is not particularly difficult to make
operational at the point of origin, using available tools.

Doug Foster




On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely  wrote:

> (This message is not going to be accepted by the IETF today, so I CC John
> too)
>
> On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
> >>> 3. The role of the function that uses the PSD and the role of the
> >>> function that does a tree walk are identical.  Since you apparently
> feel
> >>> otherwise, please explain.
> >>
> >> A PSD is potentially useful for DMARC policy determination if no policy
> exists
> >> for the exact domain or the organizational domain.  It is not useful for
> >> evaluating relaxed alignment.  Only the organizational domain can be
> used for
> >> that.  So I do not think you are correct.
> >
> > The RFC  9091 does not contain the word 'relaxed', so I'm curious about
> the
> > basis for your assertion of the limitation.
>
>
> Let me ask if the following scenario is possible at all:
>
> .BANK admins decide to setup a DKIM signing service for .bank domains.
> They
> register dkim.bank, and accept and relay messages originating from their
> customers, signing them with d=dkim.bank.  (Compare to onmicrosoft.com?)
>
> They may consider that a tangible way to protect .bank domains.
>
> Will that work to validate, say, mail From: acco...@havenbank.bank?
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational Domain

[Alessandro Vesely]

(This message is not going to be accepted by the IETF today, so I CC John too)

On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:

3. The role of the function that uses the PSD and the role of the
function that does a tree walk are identical.  Since you apparently feel
otherwise, please explain.


A PSD is potentially useful for DMARC policy determination if no policy exists
for the exact domain or the organizational domain.  It is not useful for
evaluating relaxed alignment.  Only the organizational domain can be used for
that.  So I do not think you are correct.


The RFC  9091 does not contain the word 'relaxed', so I'm curious about the 
basis for your assertion of the limitation.



Let me ask if the following scenario is possible at all:

.BANK admins decide to setup a DKIM signing service for .bank domains.  They 
register dkim.bank, and accept and relay messages originating from their 
customers, signing them with d=dkim.bank.  (Compare to onmicrosoft.com?)


They may consider that a tangible way to protect .bank domains.

Will that work to validate, say, mail From: acco...@havenbank.bank?


Best
Ale
--







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

Re: [dmarc-ietf] Organizational Domain

[Barry Leiba]

Dave,

> 2. Your 'for the sake of' is uncalled for and dismissive.  Please stop
> doing that.  Attempts to be dismissive are a popular debating
> technique in the IETF, but they are counter-productive, as well as
> unprofessional.

Two things here:
First, please do not admonish participants for their behaviour: that's
for the chairs to do, and you should feel free to call things out to
us privately.  It's too easy for discussions to degenerate when we
move them away from the technical arguments.

Second, the chairs don't find Scott's comment to be at all dismissive,
as the "for the sake of" sentence needs to be taken in the context of
the subsequent sentence that explains that Scott doesn't think you've
given a suitable rationale for the proposed change.

Rather, you are demanding justifications such as hard data to support
opinions... the sort of hard data that you, yourself are not providing
to support your own opinions.  We see *that* as being dismissive and
unhelpful in progressing the discussion.

> 1. For this topic, they are irrelevant. There is nothing in the
> charter that says terminology must be preserved.  Interoperability is
> not endangered by changes in terminology.

My opinion is that interoperability might well be endangered by
changes in terminology, if it results in older and newer
implementations differing in how they handle things based on those
differences in terminology.  To the point at hand, though, that
opinion seems to be what Scott and John are also raising, and which
you are dismissing.


Everyone,

The chairs need the working group to move this discussion toward
resolution, which will require that we directly address each others'
points rather than relying on rhetoric aimed at keeping others in
defensive positions.  We all know how to move discussions forward
productively: listening to arguments and doing our best to understand
and respond to them, asking and responding to questions that seek
clarity, and accepting reasonable disagreements.  So let's all please
focus on that.

Barry and Seth

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

Re: [dmarc-ietf] Organizational Domain

[Douglas Foster]

My two cents:

Our document will be both a technical description of how to participate in
DMARC and a persuasive description of why participation is desirable.  The
organization domain represents an ADMD.  Therefore, alignment is not
allowed between two organizational domains because they represent two
different spans of administrative control.   Similarly, alignment is
currently allowed between sister domains because they are both under a
single ADMD and we assume that the organization's administration is best
qualified to determine whether sister domains should be allowed to send
messages on behalf of each other.

By contrast, although an SP policy is currently allowed only on an
organizational domain, there is no conceptual necessity for this
limtation to be permanent.  Consequently, IU favor the first original text
because it connects the abstract concept of administrative control to the
technical detail of a specific policy record.   A description based on the
mechanics of SP implementation seems too limiting.

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

Re: [dmarc-ietf] Organizational Domain

[Scott Kitterman]

On Sunday, January 30, 2022 2:57:56 PM EST Dave Crocker wrote:
> On 1/30/2022 10:39 AM, Scott Kitterman wrote:
> > On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
> >> On 1/29/2022 7:53 PM, Scott Kitterman wrote:
>  1. Using 7489 or 9091 as fixed, controlling documents is problematic,
>  as
>  I've noted.  So, 'consistency' with them is frankly irrelevant.
> >>> The WG charter doesn't say that they are irrelevant.  I don't think we
> >>> should be redefining terms for the sake of redefining terms.  You've
> >>> given no rationale for there being a problem with the current
> >>> definition,
> >>> so I don't think it's up to me to make the case for why things shouldn't
> >>> change.
> >> 
> >> 1. For this topic, they are irrelevant. There is nothing in the charter
> >> that says terminology must be preserved.  Interoperability is not
> >> endangered by changes in terminology.
> > 
> > I disagree.
> 
> OK.  Then point to the text in the charter that supports your view.

You said consistency is irrelevant.  I disagreed.  That's not anchored to the 
charter at all.

> >   Having the same term mean two different things in different DMARC
> > RFCs is a recipe for confusion.
> 
> 1. This ignores the concept of "Experimental" and, therefore, learning
> from experience.
> 
> 2. Your certitude about consequences means that you have clear and
> compelling evidence from the field that the negative outcome will
> happen.  Please cite it.
> 
> Otherwise, what you are saying is merely that you are concerned there
> might be confusion.  To this I'll counter that having two different
> terms that cover exactly the same semantic is inherently... semantically
> confusing.

Yes.  I am concerned that having two different definitions for the term 
organizational domain in RFC 7489 and DMARCbis that are technically distinct 
in their scope will cause confusion.  What two terms are there that cover the 
same semantic?

> >Confusion leads to programming and
> > configuration errors, which definitely impact interoperability.  I think
> > the current definition of Organizational Domain is fine.  If you think
> > there is a problem with it, I would encourage you to come up with a
> > different term to use in DMARCbis (and whatever other documents it's
> > relevant to) and make your case.
> 
> OD is not a programming construct.  And the way to ensure consistent,
> accurate programming -- or, at least, to make it more likely -- is with
> clear, precise, accurate specification of algorithms, rather than by
> treating unifying labels as problematic.

Except when you unify two different things (organizational domain and public 
suffix domain it what I think you are getting at) and pretend they are the same 
when they are not.

> >> 2. Your 'for the sake of' is uncalled for and dismissive.  Please stop
> >> doing that.  Attempts to be dismissive are a popular debating technique
> >> in the IETF, but they are counter-productive, as well as
> >> unprofessional.  (And no, this comment is not just meant for you. You're
> >> just lucky, tonight.)
> > 
> > I agree they are unfortunately common, but you've made no case for the
> > change beyond that fact that you proposed it.
> 
> Then I suggest you read my proposal and followup texts a lot more
> carefully and even engage with their details, such the details I
> reiterated that you included below...
> 
> >  You may, in fact, have a good reason
> > for it, but I have no idea what it is.  That's my opinion based on what I
> > know.  If I missed something about why you think this is worth spending
> > time on, please point me at the reference or explain it.
> 
> Clearly.

I've read it all.  I find no justification for your proposal and I think it's 
quite likely to do substantial harm.  I doubt I'm going to change my mind 
absent some new information, so I'll step back and see if your position gains 
support.

> >> 3. As for giving no rationale, 'tree walk' posting set the stage.
> >> 
> >>  a) Today's posting specifically noted:
> >>  "the move towards supporting (at least) two very different methods
> >> of finding it."  \
> >> 
> >>  b) Again:  for DMARC, the semantics of the different mechanisms is
> >> the same.  Hence a single term.
> >> 
> >> There is quite a bit of benefit in having a single term to cover
> >> different means of achieving the same goal.
> >> 
> >> So now I'll again ask:  what are the semantic differences that are
> >> relevant to DMARC, and what is the benefit of having DMARC use different
> >> terms, given that DMARC does not care about which mechanism is used?
> > 
> > Since relaxed mode alignment in RFC 7489 Section 3.1 is referenced to the
> > organizational domain, changing the definition of organizational domain to
> > include PSDs would have a huge impact on DMARC.
> 
> You are depending on a restriction for relaxed that is not documented
> and, frankly, doesn't make obvious sense.  So reliance on that isn't
> helpful to 

Re: [dmarc-ietf] Organizational Domain

[Dave Crocker]

On 1/30/2022 10:39 AM, Scott Kitterman wrote:

On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:

On 1/29/2022 7:53 PM, Scott Kitterman wrote:

1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
I've noted.  So, 'consistency' with them is frankly irrelevant.

The WG charter doesn't say that they are irrelevant.  I don't think we
should be redefining terms for the sake of redefining terms.  You've
given no rationale for there being a problem with the current definition,
so I don't think it's up to me to make the case for why things shouldn't
change.

1. For this topic, they are irrelevant. There is nothing in the charter
that says terminology must be preserved.  Interoperability is not
endangered by changes in terminology.

I disagree.


OK.  Then point to the text in the charter that supports your view.



  Having the same term mean two different things in different DMARC
RFCs is a recipe for confusion.


1. This ignores the concept of "Experimental" and, therefore, learning 
from experience.


2. Your certitude about consequences means that you have clear and 
compelling evidence from the field that the negative outcome will 
happen.  Please cite it.


Otherwise, what you are saying is merely that you are concerned there 
might be confusion.  To this I'll counter that having two different 
terms that cover exactly the same semantic is inherently... semantically 
confusing.




   Confusion leads to programming and
configuration errors, which definitely impact interoperability.  I think the
current definition of Organizational Domain is fine.  If you think there is a
problem with it, I would encourage you to come up with a different term to use
in DMARCbis (and whatever other documents it's relevant to) and make your
case.


OD is not a programming construct.  And the way to ensure consistent, 
accurate programming -- or, at least, to make it more likely -- is with 
clear, precise, accurate specification of algorithms, rather than by 
treating unifying labels as problematic.




2. Your 'for the sake of' is uncalled for and dismissive.  Please stop
doing that.  Attempts to be dismissive are a popular debating technique
in the IETF, but they are counter-productive, as well as
unprofessional.  (And no, this comment is not just meant for you. You're
just lucky, tonight.)

I agree they are unfortunately common, but you've made no case for the change
beyond that fact that you proposed it.


Then I suggest you read my proposal and followup texts a lot more 
carefully and even engage with their details, such the details I 
reiterated that you included below...




  You may, in fact, have a good reason
for it, but I have no idea what it is.  That's my opinion based on what I
know.  If I missed something about why you think this is worth spending time
on, please point me at the reference or explain it.


Clearly.



3. As for giving no rationale, 'tree walk' posting set the stage.

 a) Today's posting specifically noted:

 "the move towards supporting (at least) two very different methods
of finding it."  \

 b) Again:  for DMARC, the semantics of the different mechanisms is
the same.  Hence a single term.

There is quite a bit of benefit in having a single term to cover
different means of achieving the same goal.

So now I'll again ask:  what are the semantic differences that are
relevant to DMARC, and what is the benefit of having DMARC use different
terms, given that DMARC does not care about which mechanism is used?

Since relaxed mode alignment in RFC 7489 Section 3.1 is referenced to the
organizational domain, changing the definition of organizational domain to
include PSDs would have a huge impact on DMARC.


You are depending on a restriction for relaxed that is not documented 
and, frankly, doesn't make obvious sense.  So reliance on that isn't 
helpful to this topic.




  DMARC may not care about the
mechanism (I agree with that), but it certainly cares about the result.  With
your proposed change maryland.gov could send mail with a DMARC pass from
virignia.gov.  While that's not particularly catastrophic, as soon as a non-
governmental PSD publishes a record, it would be.


Please explain 1) how that can happen under .gov, and 2) why it is 
credible to claim that it could happen.  Because neither is obvious to me.




2. To the extent that the text I've proposed does not accurately reflect
the semantics of what DMARC needs, please explain what, specifically,
are the issues.

I'm not aware of any related to a need for this new text.  I think that's
up to you.

Sorry no.  It's not my job to guess at your objections.  I'm pretty sure
it's your job to explain them.

I've made my objections pretty clear, I think.


1. You have not engaged with the specific points I've made, explaining 
the basis and benefit of what I've proposed.


2. You've relied on points that aren't documented and, IMO, don't make 
sense.


So, no, you have not made meaningful 

Re: [dmarc-ietf] Organizational Domain

[Scott Kitterman]

On Sunday, January 30, 2022 11:14:18 AM EST John R Levine wrote:
> On Sun, 30 Jan 2022, Alessandro Vesely wrote:
> > Let me ask if the following scenario is possible at all:
> > 
> > .BANK admins decide to setup a DKIM signing service for .bank domains. 
> > They register dkim.bank, and accept and relay messages originating from
> > their customers, signing them with d=dkim.bank.  (Compare to
> > onmicrosoft.com?)
> Sounds like a bad idea, but OK for now ...  I note that onmicrosoft.com is
> an MTA farm, and they have ways to apply valid customer DKIM signatures if
> they want to.
> 
> > They may consider that a tangible way to protect .bank domains.
> 
> No, they won't.  See below.
> 
> > Will that work to validate, say, mail From: acco...@havenbank.bank?
> 
> No, of course not.  dkim.bank is no different from any other domain
> registered under .bank.
> 
> Scott knows better than me, but my understanding of PSD is that it's a way
> to check wheter registrants have published the DMARC policies they are
> supposed to, and to provide a backstop until they do, not another way to
> try and circumvent broken configurations.
> 
> PSDs only make sense in TLDs (or TL-ish Ds) that have a strong enough
> relationship with their registrants to require DMARC policies.  That's one
> of the many reasons you'll never see a PSD in .com or .org or .hockey.

I believe that's largely correct.  It also gives a mechanism to apply DMARC 
policies to non-existent domains, which has some value for dealing with 
unregistered entities subject to spoofing.

Scott K


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

Re: [dmarc-ietf] Organizational Domain

[Scott Kitterman]

On Sunday, January 30, 2022 7:34:35 AM EST Alessandro Vesely wrote:
> (This message is not going to be accepted by the IETF today, so I CC John
> too)
> On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
> >>> 3. The role of the function that uses the PSD and the role of the
> >>> function that does a tree walk are identical.  Since you apparently feel
> >>> otherwise, please explain.
> >> 
> >> A PSD is potentially useful for DMARC policy determination if no policy
> >> exists for the exact domain or the organizational domain.  It is not
> >> useful for evaluating relaxed alignment.  Only the organizational domain
> >> can be used for that.  So I do not think you are correct.
> > 
> > The RFC  9091 does not contain the word 'relaxed', so I'm curious about
> > the
> > basis for your assertion of the limitation.
> 
> Let me ask if the following scenario is possible at all:
> 
> .BANK admins decide to setup a DKIM signing service for .bank domains.  They
> register dkim.bank, and accept and relay messages originating from their
> customers, signing them with d=dkim.bank.  (Compare to onmicrosoft.com?)
> 
> They may consider that a tangible way to protect .bank domains.
> 
> Will that work to validate, say, mail From: acco...@havenbank.bank?

It's not possible.

Scott K


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

Re: [dmarc-ietf] Organizational Domain

[Scott Kitterman]

On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
> On 1/29/2022 7:53 PM, Scott Kitterman wrote:
> >> 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
> >> I've noted.  So, 'consistency' with them is frankly irrelevant.
> > 
> > The WG charter doesn't say that they are irrelevant.  I don't think we
> > should be redefining terms for the sake of redefining terms.  You've
> > given no rationale for there being a problem with the current definition,
> > so I don't think it's up to me to make the case for why things shouldn't
> > change.
> 
> 1. For this topic, they are irrelevant. There is nothing in the charter
> that says terminology must be preserved.  Interoperability is not
> endangered by changes in terminology.

I disagree.  Having the same term mean two different things in different DMARC 
RFCs is a recipe for confusion.  Confusion leads to programming and 
configuration errors, which definitely impact interoperability.  I think the 
current definition of Organizational Domain is fine.  If you think there is a 
problem with it, I would encourage you to come up with a different term to use 
in DMARCbis (and whatever other documents it's relevant to) and make your 
case.

> 2. Your 'for the sake of' is uncalled for and dismissive.  Please stop
> doing that.  Attempts to be dismissive are a popular debating technique
> in the IETF, but they are counter-productive, as well as
> unprofessional.  (And no, this comment is not just meant for you. You're
> just lucky, tonight.)

I agree they are unfortunately common, but you've made no case for the change 
beyond that fact that you proposed it.  You may, in fact, have a good reason 
for it, but I have no idea what it is.  That's my opinion based on what I 
know.  If I missed something about why you think this is worth spending time 
on, please point me at the reference or explain it.

> 3. As for giving no rationale, 'tree walk' posting set the stage.
> 
> a) Today's posting specifically noted:
> 
> "the move towards supporting (at least) two very different methods
> of finding it."  \
> 
> b) Again:  for DMARC, the semantics of the different mechanisms is
> the same.  Hence a single term.
> 
> There is quite a bit of benefit in having a single term to cover
> different means of achieving the same goal.
> 
> So now I'll again ask:  what are the semantic differences that are
> relevant to DMARC, and what is the benefit of having DMARC use different
> terms, given that DMARC does not care about which mechanism is used?

Since relaxed mode alignment in RFC 7489 Section 3.1 is referenced to the 
organizational domain, changing the definition of organizational domain to 
include PSDs would have a huge impact on DMARC.  DMARC may not care about the 
mechanism (I agree with that), but it certainly cares about the result.  With 
your proposed change maryland.gov could send mail with a DMARC pass from 
virignia.gov.  While that's not particularly catastrophic, as soon as a non-
governmental PSD publishes a record, it would be.

> >> 2. To the extent that the text I've proposed does not accurately reflect
> >> the semantics of what DMARC needs, please explain what, specifically,
> >> are the issues.
> > 
> > I'm not aware of any related to a need for this new text.  I think that's 
> > up to you.
> 
> Sorry no.  It's not my job to guess at your objections.  I'm pretty sure
> it's your job to explain them.

I've made my objections pretty clear, I think.  I don't see any problems with 
the RFC 7489 definition.  If you want to change something, surely it's not my 
job to read your mind.  To the extend I understand your reasoning (see above),  
I think it's factually incorrect.

> >> 3. The role of the function that uses the PSD and the role of the
> >> function that does a tree walk are identical.  Since you apparently feel
> >> otherwise, please explain.
> > 
> > A PSD is potentially useful for DMARC policy determination if no policy
> > exists for the exact domain or the organizational domain.  It is not
> > useful for evaluating relaxed alignment.  Only the organizational domain
> > can be used for that.  So I do not think you are correct.
> 
> The RFC  9091 does not contain the word 'relaxed', so I'm curious about
> the basis for your assertion of the limitation.

Because relaxed mode alignment is defined in RFC 7489, as defined in RFC 7489 
explicitly excludes PSDs (although not using that term, since you hadn't come 
up with it yet), and RFC 9091 makes no changes to it.  This is just one of the 
many things about RFC 7489 that RFC 9091 neither changes nor mentions.

Scott K



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

Re: [dmarc-ietf] Organizational Domain - But why?

[Douglas Foster]

RFC 7489 has two different scopes applied to policies:
current-domain-only and
current-domain-plus-subdomains

For undocumented reasons, RFC 7489 created a restriction that
current-domain-plus-subdomains may only be used on "organizational domains"
(since revised to include PSD domains).   I see no theoretical or technical
reason why this constraint is necessary or desirable.

We have established that the "organization domain" is technically difficult
to identify with accuracy.  The addition of PSD policies has made this
definition even more difficult.   Given this problem, continuing to build
an unnecessary constraint on an ambiguous target is a mistake.

We would do better to make policies generic -- any policy can be applied to
subdomains by providing an SP clause, and any policy can be restricted to
current-domain-only by providing a different token, such as LIMIITED=Y.
 If we do this, we give domain owners greater flexibility, and flexibility
is more likely to help migrate some domains from SP=NONE to SP=REJECT,
which I would consider a good thing.

As a side effect, the need to define an organizational domain goes away.

Doug Foster

On Sat, Jan 29, 2022 at 1:11 PM Dave Crocker  wrote:

> Folks,
>
> The current draft has this text concerning Organizational Domain:
>
> 3.2.7.
> Organizational
> Domain
> 
>  The
> Organizational Domain is typically a domain that was registered with a
> domain name registrar. More formally, it is any Public Suffix Domain plus
> one label. The Organizational Domain for the domain in the RFC5322.From
> domain is determined by applying the algorithm found in Section 4.6
> 
> .
>
>
> I believe the text is not adequately helpful, in terms of DMARC's history,
> and especially not helpful in the move towards supporting (at least) two
> very different methods of finding it.  I understand the desire to declare
> The One True mechanism, but I will claim it is too late for that.  Also, I
> think the term continues to be useful...
>
> Here is some alternative phrasing:
>
> For DMARC, an Organizational Domain can contain a DMARC record, to be used
> as the default DMARC record for subordinate domains that do not have a
> DMARC record of their own, and for subordinate domains that do not exist.
>
> This is text about the what, rather than the how.  It defines
> DMARC-relevant semantics, without saying anything about the mechanics of
> finding it.
>
>
> In that light, I'll renew my strong suggestion, from back in the days of
> PSD development, that this core DMARC document NOT contain details or
> sections devoted to PSD, in the style now shown in the current sections
> 3.2.8 - 3.2.10
>
> Rather, I suggest adding an additional sentence to the alternative
> phrasing, above:
>
> The method of finding an Organizational Domain is outside the scope of
> this specification.  Examples of such methods include the Public Suffice
> Domain (PSD) [RFC9091] and Public Suffix List [http://publicsuffix.org].
>
> I think this gives an adequate nod to established and new practice,
> without emphasizing either or the excluding the possibility of other
> methods.
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> Information & Planning Coordinator
> American Red crossdave.crock...@redcross.org
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational Domain

[Dave Crocker]

On 1/30/2022 4:34 AM, Alessandro Vesely wrote:
ANK admins decide to setup a DKIM signing service for .bank domains.  
They register dkim.bank, and accept and relay messages originating 
from their customers, signing them with d=dkim.bank.  (Compare to 
onmicrosoft.com?)


They may consider that a tangible way to protect .bank domains.

Will that work to validate, say, mail From: acco...@havenbank.bank? 



Consider .bank.com, setting up dkim.bank.com, signing with dkim.bank.com.

Will that work to validate, say, mail from acco...@havenbank.bank?

Please explain why these two different cases should be treated differently.

In other words, the issue is with problematic operational policies, 
rather than with needing to place special technical restrictions on TLDs.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Organizational Domain

[Dave Crocker]

On 1/29/2022 7:53 PM, Scott Kitterman wrote:

1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
I've noted.  So, 'consistency' with them is frankly irrelevant.

The WG charter doesn't say that they are irrelevant.  I don't think we should
be redefining terms for the sake of redefining terms.  You've given no rationale
for there being a problem with the current definition, so I don't think it's up
to me to make the case for why things shouldn't change.


1. For this topic, they are irrelevant. There is nothing in the charter 
that says terminology must be preserved.  Interoperability is not 
endangered by changes in terminology.


2. Your 'for the sake of' is uncalled for and dismissive.  Please stop 
doing that.  Attempts to be dismissive are a popular debating technique 
in the IETF, but they are counter-productive, as well as 
unprofessional.  (And no, this comment is not just meant for you. You're 
just lucky, tonight.)


3. As for giving no rationale, 'tree walk' posting set the stage.

   a) Today's posting specifically noted:

   "the move towards supporting (at least) two very different methods 
of finding it."  \


   b) Again:  for DMARC, the semantics of the different mechanisms is 
the same.  Hence a single term.


There is quite a bit of benefit in having a single term to cover 
different means of achieving the same goal.


So now I'll again ask:  what are the semantic differences that are 
relevant to DMARC, and what is the benefit of having DMARC use different 
terms, given that DMARC does not care about which mechanism is used?




2. To the extent that the text I've proposed does not accurately reflect
the semantics of what DMARC needs, please explain what, specifically,
are the issues.

I'm not aware of any related to a need for this new text.  I think that's  up
to you.


Sorry no.  It's not my job to guess at your objections.  I'm pretty sure 
it's your job to explain them.




3. The role of the function that uses the PSD and the role of the
function that does a tree walk are identical.  Since you apparently feel
otherwise, please explain.

A PSD is potentially useful for DMARC policy determination if no policy exists
for the exact domain or the organizational domain.  It is not useful for
evaluating relaxed alignment.  Only the organizational domain can be used for
that.  So I do not think you are correct.


The RFC  9091 does not contain the word 'relaxed', so I'm curious about 
the basis for your assertion of the limitation.



d/


--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational Domain

[Scott Kitterman]

On Saturday, January 29, 2022 10:26:37 PM EST Dave Crocker wrote:
> On 1/29/2022 1:58 PM, Scott Kitterman wrote:
> > So going
> > back to Dave's proposed text that started the thread:
> > 
> > On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote:
> >> Here is some alternative phrasing:
> >>  For DMARC, an Organizational Domain can contain a DMARC record, to
> >>  be used as the default DMARC record for subordinate domains that do
> >>  not have a DMARC record of their own, and for subordinate domains
> >>  that do not exist.
> > 
> > I don't think that is consistent with either RFC 7489 or RFC 9091.  I
> > don't
> > think what is in the current draft is great either.  RFC 7489
> > distinguished
> > between the definition of organizational domain and how you find the
> > organizational domain.  I think that distinction is useful.
> 
> 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
> I've noted.  So, 'consistency' with them is frankly irrelevant.

The WG charter doesn't say that they are irrelevant.  I don't think we should 
be redefining terms for the sake of redefining terms.  You've given no 
rationale 
for there being a problem with the current definition, so I don't think it's up 
to me to make the case for why things shouldn't change.

> 2. To the extent that the text I've proposed does not accurately reflect
> the semantics of what DMARC needs, please explain what, specifically,
> are the issues.

I'm not aware of any related to a need for this new text.  I think that's  up 
to you.

> 3. The role of the function that uses the PSD and the role of the
> function that does a tree walk are identical.  Since you apparently feel
> otherwise, please explain.

A PSD is potentially useful for DMARC policy determination if no policy exists 
for the exact domain or the organizational domain.  It is not useful for 
evaluating relaxed alignment.  Only the organizational domain can be used for 
that.  So I do not think you are correct.

Scott K


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

Re: [dmarc-ietf] Organizational Domain

[Dave Crocker]

On 1/29/2022 1:58 PM, Scott Kitterman wrote:

So going
back to Dave's proposed text that started the thread:

On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote:

Here is some alternative phrasing:
 For DMARC, an Organizational Domain can contain a DMARC record, to
 be used as the default DMARC record for subordinate domains that do
 not have a DMARC record of their own, and for subordinate domains
 that do not exist.

I don't think that is consistent with either RFC 7489 or RFC 9091.  I don't
think what is in the current draft is great either.  RFC 7489 distinguished
between the definition of organizational domain and how you find the
organizational domain.  I think that distinction is useful.



1. Using 7489 or 9091 as fixed, controlling documents is problematic, as 
I've noted.  So, 'consistency' with them is frankly irrelevant.


2. To the extent that the text I've proposed does not accurately reflect 
the semantics of what DMARC needs, please explain what, specifically, 
are the issues.


3. The role of the function that uses the PSD and the role of the 
function that does a tree walk are identical.  Since you apparently feel 
otherwise, please explain.


d/

--
Dave Crocker

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

Re: [dmarc-ietf] Organizational Domain

[Dave Crocker]

On 1/29/2022 12:48 PM, John R Levine wrote:
Since a PSD can't be an organizational domain, I don't think that's 
going to work.
Please provide the foundation to this assertion, because I believe 
the text I've offered makes your premise wrong.


Then it's lucky we caught this mistake now, isn't it?

See RFC 9091, section 1. 



John,

You might be surprised to find out that your saying something is a 
mistake does not make it one.  Especially when, you know, it isn't one.


You might also be surprised to find out that making a generic reference 
to an entire document does not further detailed discussion about a 
specific point.


And you might even be surprised to find out that citing an Experimental 
RFC does not do much in establishing much, as is constantly being 
pointed out in Emailcore, no matter how much group effort, and even IETF 
approval, was developed to get the document published.


And best of all is that the RFC you cited refers back to RFC 7489 for 
the definition of Organizational Domain.  And, gosh, that's also 
Experimental, not to mention, well, it's the document we are revising here.



So, perhaps you will consider the challenge of engaging in substantive 
discussion and respond to my proposed language... substantially?



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational Domain

[Scott Kitterman]

On Saturday, January 29, 2022 3:48:46 PM EST John R Levine wrote:
> >> Since a PSD can't be an organizational domain, I don't think that's going
> >> to work.
> > 
> > Please provide the foundation to this assertion, because I believe the
> > text
> > I've offered makes your premise wrong.
> 
> Then it's lucky we caught this mistake now, isn't it?
> 
> See RFC 9091, section 1.

Or even RFC 7489.

On the topic of if the process for discovering the organizational domain goes 
into DMARCbis or into a separate draft, I care far more that the chairs tell 
us what we're doing and we quit arguing about it than what the actual answer 
is.  I have a slight preference for a separate document (which I would be 
happy to edit if that's the direction go), but I can see arguments either way.  

Independent of where it's documented, I think the text of both RFC 7489 and 
RFC 9091 makes it clear that the "PSD" domains are not organizational domains.  
Let's start with RFC 7489:

In section 3, there is a textual definition:

>Organizational Domain:  The domain that was registered with a domain
>   name registrar.  In the absence of more accurate methods,
>   heuristics are used to determine this, since it is not always the
>   case that the registered domain name is simply a top-level DNS
>   domain plus one component (e.g., "example.com", where "com" is a
>   top-level domain).  The Organizational Domain is determined by
>   applying the algorithm found in Section 3.2.

In section 3.2, there is a definition of how to determine if something is an 
organizational domain:

> 3.2.  Organizational Domain
> 
>The Organizational Domain is determined using the following
>algorithm:
>
>1.  Acquire a "public suffix" list, i.e., a list of DNS domain names
>reserved for registrations.  Some country Top-Level Domains
>(TLDs) make specific registration requirements, e.g., the United
>Kingdom places company registrations under ".co.uk"; other TLDs
>such as ".com" appear in the IANA registry of top-level DNS
>domains.  A public suffix list is the union of all of these.
>Appendix A.6.1 contains some discussion about obtaining a public
>suffix list.
>
>2.  Break the subject DNS domain name into a set of "n" ordered
>labels.  Number these labels from right to left; e.g., for
>"example.com", "com" would be label 1 and "example" would be
>label 2.
>
>3.  Search the public suffix list for the name that matches the
>largest number of labels found in the subject DNS domain.  Let
>that number be "x".
>
>4.  Construct a new DNS domain name using the name that matched from
>the public suffix list and prefixing to it the "x+1"th label from
>the subject domain.  This new name is the Organizational Domain.
>
>Thus, since "com" is an IANA-registered TLD, a subject domain of
>"a.b.c.d.example.com" would have an Organizational Domain of
>"example.com".
>
>The process of determining a suffix is currently a heuristic one.  No
>list is guaranteed to be accurate or current.

Based on those rules, a PSD is not an organizational domain.  In fact, this is 
in section 3.1.1:

>However, a DKIM signature bearing a value of "d=com" would never
>allow an "in alignment" result, as "com" should appear on all public
>suffix lists (see Appendix A.6.1) and therefore cannot be an
>Organizational Domain.

Based on both the definitions and the specific statement, I think it's clear 
that what we later defines as PSDs are not organizational domains according to 
RFC 7489.

Did RFC 9091 experimentally change this?

As John suggested, the introduction to RFC 9091 explicitly addresses this 
question:

>In the basic DMARC model, Public Suffix Domains (PSDs) are not
>Organizational Domains and are thus not subject to DMARC processing.
>In DMARC, domains fall into one of three categories: Organizational
>Domains, subdomains of Organizational Domains, or PSDs.  A PSD can
>only publish DMARC policy for itself and not for any subdomains under
>it.  In some cases, this limitation allows for the abuse of non-
>existent organizational-level domains and hampers identification of
>domain abuse in email.

Here is the RFC 9091 definition of organizational domain:

> 2.3.  Organizational Domain
> 
>The term "Organizational Domain" is defined in Section 3.2 of
>[RFC7489].

I don't find anything in RFC 9091 that suggests anything different.  So going 
back to Dave's proposed text that started the thread:

On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote:
> Here is some alternative phrasing:
> For DMARC, an Organizational Domain can contain a DMARC record, to
> be used as the default DMARC record for subordinate domains that do
> not have a DMARC record of their own, and for subordinate domains
> that do 

Re: [dmarc-ietf] Organizational Domain

[John R Levine]

Since a PSD can't be an organizational domain, I don't think that's going 
to work.
Please provide the foundation to this assertion, because I believe the text 
I've offered makes your premise wrong.


Then it's lucky we caught this mistake now, isn't it?

See RFC 9091, section 1.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Organizational Domain

[Dave Crocker]

On 1/29/2022 10:52 AM, John Levine wrote:

Since a PSD can't be an organizational domain, I don't think that's going to 
work.



Please provide the foundation to this assertion, because I believe the 
text I've offered makes your premise wrong.


That is, I think you are taking as a given, something that is not a given.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Organizational Domain

[John Levine]

It appears that Dave Crocker   said:
>Here is some alternative phrasing:
>
>For DMARC, an Organizational Domain can contain a DMARC record, to
>be used as the default DMARC record for subordinate domains that do
>not have a DMARC record of their own, and for subordinate domains
>that do not exist.

That sounds right to me.

>In that light, I'll renew my strong suggestion, from back in the days of 
>PSD development, that this core DMARC document NOT contain details or 
>sections devoted to PSD, in the style now shown in the current sections 
>3.2.8 - 3.2.10

Since a PSD can't be an organizational domain, I don't think that's going to 
work.

R's,
John

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

[dmarc-ietf] Organizational Domain

[Dave Crocker]

Folks,

The current draft has this text concerning Organizational Domain:



3.2.7.

Organizational
Domain




The Organizational Domain is typically a domain that was registered 
with a domain name registrar. More formally, it is any Public Suffix 
Domain plus one label. The Organizational Domain for the domain in the 
RFC5322.From domain is determined by applying the algorithm found in 
Section 4.6 
.



I believe the text is not adequately helpful, in terms of DMARC's 
history, and especially not helpful in the move towards supporting (at 
least) two very different methods of finding it.  I understand the 
desire to declare The One True mechanism, but I will claim it is too 
late for that.  Also, I think the term continues to be useful...


Here is some alternative phrasing:

   For DMARC, an Organizational Domain can contain a DMARC record, to
   be used as the default DMARC record for subordinate domains that do
   not have a DMARC record of their own, and for subordinate domains
   that do not exist.

This is text about the what, rather than the how.  It defines 
DMARC-relevant semantics, without saying anything about the mechanics of 
finding it.



In that light, I'll renew my strong suggestion, from back in the days of 
PSD development, that this core DMARC document NOT contain details or 
sections devoted to PSD, in the style now shown in the current sections 
3.2.8 - 3.2.10


Rather, I suggest adding an additional sentence to the alternative 
phrasing, above:


   The method of finding an Organizational Domain is outside the scope
   of this specification.  Examples of such methods include the Public
   Suffice Domain (PSD) [RFC9091] and Public Suffix List
   [http://publicsuffix.org].

I think this gives an adequate nod to established and new practice, 
without emphasizing either or the excluding the possibility of other 
methods.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc