Subject: [dmarc-ietf] Organizational Domain

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jan 2022 10:11:29 -0800

Folks,

The current draft has this text concerning Organizational Domain:

>
>         3.2.7.
>         <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#section-3.2.7>Organizational
>         Domain
>         <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#name-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 
> <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#determining-the-organizational-domain>.

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
[email-masked]
408.329.0791

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

---

From: "John Levine" <[email-masked]>
Date: 29 Jan 2022 13:52:51 -0500

>    not have a DMARC record of their own, and for subordinate domains

That sounds right to me.

>sections devoted to PSD, in the style now shown in the current sections 

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

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jan 2022 10:57:05 -0800

> 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
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 29 Jan 2022 15:48:46 -0500

> 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, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 29 Jan 2022 16:58:10 -0500

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

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:

>     not have a DMARC record of their own, and for subordinate domains

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.

I think the DMARCbis draft would be improved by going back to the RFC 7489 
definition and there being a separate discussion on how on determines an 
organizational domain either in a separate draft or in DMARCbis [chairs: 
please tell us what you want].

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jan 2022 15:23:48 -0800

On 1/29/2022 12:48 PM, John R Levine wrote:
>> Please provide the foundation to this assertion, because I believe 
>> the text I've offered makes your premise wrong.
>

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
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jan 2022 19:26:37 -0800

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

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

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 29 Jan 2022 22:53:48 -0500

> 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.

> the semantics of what DMARC needs, please explain what, specifically,

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

> 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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jan 2022 20:25:30 -0800

> 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?

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

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

> 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
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jan 2022 06:11:02 -0800

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: [email-masked]? 

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

Will that work to validate, say, mail from [email-masked]?

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
[email-masked]
408.329.0791

---

From: Douglas Foster <[email-masked]>
Date: Sun, 30 Jan 2022 09:12:23 -0500

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 <[email-masked]> wrote:

> <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#name-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...
>
> 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.
>
> 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].
>
> Dave [email-masked]
> 408.329.0791
>
> American Red [email-masked]
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

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

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: [email-masked]?

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.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 30 Jan 2022 13:39:46 -0500

On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
> > 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.
> 

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.

> unprofessional.  (And no, this comment is not just meant for you. You're

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.

> 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.

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

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.

> > 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.
> 

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

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 30 Jan 2022 13:43:20 -0500

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:
> > the
> > basis for your assertion of the limitation.
> 

It's not possible.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 30 Jan 2022 13:45:38 -0500

On Sunday, January 30, 2022 11:14:18 AM EST John R Levine wrote:
> > .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?)

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jan 2022 11:57:56 -0800

On 1/30/2022 10:39 AM, Scott Kitterman wrote:
> 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

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.

> 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

Clearly.

> 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

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.

> 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 objections.

>    I don't see any problems with
> the RFC 7489 definition.

This will be perhaps the fourth time I've explained:  Having different 
labels for the same semantics is not helpful for distinguishing the what 
from the how.  What you are promoting is different labels for the how, 
with no unifying term for the what.

>   If you want to change something, surely it's not my
> job to read your mind.

It is your job, however, to read what I've written, to consider it, and 
to respond to its details.

> many things about RFC 7489 that RFC 9091 neither changes nor mentions.
I'm sorry you do not see that your logic is circular.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 30 Jan 2022 15:28:50 -0500

> 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.

> terms that cover exactly the same semantic is inherently... semantically

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?

> > 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.
> 

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.

> > I agree they are unfortunately common, but you've made no case for the
> > change beyond that fact that you proposed it.
> 
> > 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.

> and, frankly, doesn't make obvious sense.  So reliance on that isn't

I disagree.  I think it's plain as day in RFC 7489.

> > 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.
> 

It's a straight forward reading of RFC 7489 Section 3.1 in my opinion.  I 
don't know how to make it clearer than the RFC already does.  I'm sorry.

> So, no, you have not made meaningful objections.

No, nothing other than explaining that I think it will make it possible for 
unrelated domains to publish email that passes DMARC based on relaxed 
alignment.  I think that's an absolutely fatal flaw in your suggestion.  I get 
that you disagree with that, but fortunately in the IETF it's not up to only 
you and I to decide.

> >    I don't see any problems with the RFC 7489 definition.
> 

Yes and I disagree.  They aren't the same.  Org is used for policy and 
alignment.  PSD is used for policy in the absence of Org policy.  Those are 
NOT the same thing.

> to respond to its details.

I have.  I disagree with you.  Disagreeing with you is not the same thing as 
not having read and considered.

> > 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.

I agree that I don't see this.  I'm out on this thread until there's some 
clear input from the rest of the working group.  One of us is wrong and we're 
each very confident who that is.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Sun, 30 Jan 2022 15:53:09 -0500

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 31 Jan 2022 13:15:50 -0500

Dave,

> 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

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 30 Jan 2022 13:34:35 +0100

(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:
> The RFC  9091 does not contain the word 'relaxed', so I'm curious about the 

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 31 Jan 2022 17:12:51 -0500

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 <[email-masked]> wrote:

> exists
> They

---

From: Dotzero <[email-masked]>
Date: Mon, 31 Jan 2022 18:01:33 -0500

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

Why wouldn't your email be accepted?

> 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