Subject: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

From: Todd Herr <[email-masked]>
Date: Mon, 25 Oct 2021 15:30:19 -0400

Greetings.

There are, by my count, eleven tickets that are primarily focused on or at
least touch on the issue of policy discovery. A specialized query for them
is at this URL - https://trac.ietf.org/trac/dmarc/report/15

The question of policy discovery has a few options as its answer:

   - Leave things as they are (meaning look up the policy for the
   RFC5322.From domain and the organizational domain of that domain if
   different)
   - Add a third lookup for a public suffix domain
   - Walk the DNS tree from the RFC5322.From domain all the way to an
   agreed-upon level in the DNS hierarchy
   - Something other than what's listed here

The topic of policy discovery has been proposed for the agenda for the
upcoming DMARC session at IETF 112, and so this message should serve to
kick off a discussion of the topic now, so that we can have a most
productive discussion on the 9th.

Thank you.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

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: "Brotman, Alex" <[email-masked]>
Date: Mon, 25 Oct 2021 21:31:45 +0000

I know there has been a fair bit of talk about walk-the-tree.  Taking a 24h set of data, and trying to measure the number of times where this situation may be warranted.  We can try to make a guess the goal is to look for a DMARC policy between the 5322.From which has an unknown number of dotted sections, and the second-level/apex/organizational domain.  I extracted the 5322.From and counted the number of "." in the field.  So "1" dot, means example.com, "2" means third.example.com, and so on.  I included the policy as well, abs(ent)/none/quarantine/reject.

In roughly 86% of cases, the domain of record is in the format of "example.com".  In about 13%, we have "third.example.com".  The other <1% are other variations.  Not exactly sure if this data tells us walking-the-tree is going to be advantageous, but thought I would share with others.

Let me know if you have questions, or would like to see different data (that I'd be allowed to share)

Note: This is percentage of messages, not percentage of domains
(apologies if the formatting goes sideways)

Num_dots        Policy  PctOfTraffic
--------------          ---------  ---------------------------------------
1               none    60.9147275180
1               abs     11.4060937845
1               reject  10.9984823560
2               quarantine      7.3245642177
1               quarantine      3.1460328512
2               abs     2.5626295515
2               reject  2.1029313056
2               none    1.1140098795
3               abs     0.1924108697
3               reject  0.1362830691
3               none    0.0797639119
3               quarantine      0.0173744076
4               abs     0.0021115047
4               reject  0.0017292496
6               abs     0.0003094447
4               none    0.0002730394
4               quarantine      0.0001092158
5               quarantine      0.0001092158
5               abs     0.0000364053
5               none    0.0000091013
6               none    0.0000091013

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc <[email-masked]> On Behalf Of Todd Herr
Sent: Monday, October 25, 2021 3:30 PM
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

Greetings.

There are, by my count, eleven tickets that are primarily focused on or at least touch on the issue of policy discovery. A specialized query for them is at this URL - https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/report/15__;!!CQl3mcHX2A!VGJAEdJ0DpNqMeFma5x4t8ehOeZpPCdYqZs4Dq9_D2Zja366Lx0pcwqK4DFcSskDWHhaFXGCzA$

The question of policy discovery has a few options as its answer:
• Leave things as they are (meaning look up the policy for the RFC5322.From domain and the organizational domain of that domain if different)
• Add a third lookup for a public suffix domain
• Walk the DNS tree from the RFC5322.From domain all the way to an agreed-upon level in the DNS hierarchy
• Something other than what's listed here
The topic of policy discovery has been proposed for the agenda for the upcoming DMARC session at IETF 112, and so this message should serve to kick off a discussion of the topic now, so that we can have a most productive discussion on the 9th.

Thank you.

--
Todd Herr | Technical Director, Standards and Ecosystem
e: mailto:[email-masked]
m: 703.220.4153

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: Douglas Foster <[email-masked]>
Date: Mon, 25 Oct 2021 18:06:44 -0400

For me, the appeal of a tree walk would be to eliminate the PSL.   But an
artificially constructed domain name could have more than 100 segments, so
walking the entire tree seems like an opportunity for denial of service
attacks.

If we walk up from the bottom and quit too soon, a phony but long name
could be used to evade the actual domain policy.

We could limit complexity by starting at the PSL or organization and
walking down a limited number of segments, but this approach preserves the
need for a PSL.

These objections would not apply to a solution like the one suggested in
ticket #59, where a name is checked for membership in a single
sub-organizational unit.  Eliminating the PSL was not an objective of
ticket 59.

Doug

On Mon, Oct 25, 2021 at 3:33 PM Todd Herr <todd.herr=
[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Oct 2021 16:06:47 -0400

> productive discussion on the 9th.

I think you are getting ahead of yourself as I think we would need to 
understand a number of other things first.  Here's some immediate things that I 
think would need to be considered.  It wouldn't surprise me if I think of more 
later.

What does "an agreed-upon level in the DNS hierarchy" mean?  The 
organizational domain is the current "agreed-upon level".  Is this the same or 
something different?  We know you can't do this by counting dots in a domain 
name.  If it's the same level as the current organizational domain, then I'm 
not sure why we would want to add more lookups.  I'm not aware of a problem 
that would solve.  If it's all the way to the top of the hierarchy, then I'm 
confident the answer is no.  Regardless of exactly how the PSD experiment 
lands, the rules for a PSD level lookup need to be different than for an 
individual organization, so we still need to know where the break between the 
organizational level and the top level is (so still not sure why you would 
want to do more lookups).

Before we  have results from the PSD experiment it would be premature to 
decide either to included (add the third lookup) or exclude it (decide not to 
add the third lookup).

I recall a strong preference to do away with the PSL to define the org domain, 
but we've continually foundered on coming up with a suitable replacement that 
can achieve consensus.  I'd suggest coming to some agreement on an alternate 
method to define the org domain or that we don't care and we can identical 
policy discovery to the top of the hierarchy would be the first questions to 
answer.  Once we know the answers to those questions, then I think the actual 
policy discovery question will be relatively simple.

My prediction is that  we will pretty quickly conclude that the org domain 
construct is essential and then flounder for some time again about how to 
replace the PSL.  As a thought experiment, if the PSD is always consulted when 
an org doesn't have a DMARC record (because we're just walking up the tree), 
how does everyone feel about _dmarc.com publishing sp=reject with a reporting 
address so that the .com operator gets feedback reports for every single .com 
domain that hasn't deployed DMARC yet?  Unless the group consensus is that 
we're comfortable with that, then ditching the org domain isn't an option.

Scott K

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Oct 2021 17:03:15 -0400

> want to do more lookups).
There are two tickets of the eleven that advocate walking the tree. One,
ticket #60, suggests walking the entire DNS tree until a policy is
discovered. The other, ticket #121, champions a "one level tree walk".

My use of the phrase "an agreed-upon level in the DNS hierarchy" was meant
to acknowledge that both tickets exist, and that both propose the same
method (tree walking) with different end points.

--

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Oct 2021 17:06:31 -0400

> method (tree walking) with different end points.
And when I wrote "ticket #60" above, I meant "ticket #68".

https://trac.ietf.org/trac/dmarc/ticket/68

https://trac.ietf.org/trac/dmarc/ticket/121

--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Oct 2021 21:14:18 +0000

>method (tree walking) with different end points.

Thanks for the clarification.

For a 'normal' domain/sub-domain like eml.example.com where the domain has a DMARC policy, every single implementation approach gives the same answer, so it doesn't matter.  The challenge is getting all the other cases right.

Until we understand what we want, overall, selecting a specific design to achieve that goal is premature.  Both of those approaches will give a wrong answer (at least as I'd define it) for less usual cases.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Tue, 26 Oct 2021 18:43:43 -0400

I was surprised to see that #111 and #112, about the definition of NP,
survived to be included in this policy discussion.

I remain strongly opposed to an NP policy based on A/AAAA/MX.    A brief
recap:

- A non-existent domain test should be based on a DNS query that returns
NXDomain, not NODATA.

- A non-existent domain test should be mutually exclusive with any
existence test, but the A/AAAA/MX allows for a message to be simultaneously
authenticated by a domain DKIM signature and repudiated by absence of an
A/AAAA/MX record.

- A non-existent domain test should allow for unpublished From addresses to
become DNS-published without imputing behavior.   This can be accomplished
with a TXT record, but cannot be accomplished with an A, AAAA, or MX record.

- A non-existence test based on NXDomain can be accomplished with one extra
DNS query, while a test based on A/AAAA/MX requires multiple additional
queries.

- A non-existence test based on NXDomain can definitively state that the
name does not exist in DNS.   A test based on A/AAAA/MX says that the name
might be used for email if found, and might not be used for email if not
found.,   An ambiguous result is a useless result.

But past attempts to get these problems addressed have been fruitless.  I
do not understand why.

Doug Foster

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2021 22:09:13 -0400

It appears that Scott Kitterman  <[email-masked]> said:
>For a 'normal' domain/sub-domain like eml.example.com where the domain has a DMARC policy, every single implementation approach gives the
>same answer, so it doesn't matter.  The challenge is getting all the other cases right.
>
>Until we understand what we want, overall, selecting a specific design to achieve that goal is premature.  Both of those approaches will
>give a wrong answer (at least as I'd define it) for less usual cases.

Yup.  I think I was the first person to propose a tree-walk, so here is roughly what I was thinking:

The problem with organizational domain is that it is ill-defined.  It waves its hands and says to use something
like the PSL, and in practice everyone uses the PSL.  But the PSL is a moving target, with entries added and deleted
on a regular basis, so this month's organization domain may not be the same as last month's.  The advantage of the
tree walk is that the DMARC result now depends entirely on what is in the DNS, not on a volunteer maintained list
whose volunteers keep reminding us that it's only intended to manage http cookies.

Todd's stats confirm my intuition that the DNS is pretty flat, and the amount of mail that comes from addreses
with more than, say, four labels is miniscule.  So if you do a four level tree walk, you will find all of the
DMARC records for all of the real mail.

The question remains what to do about the fake mail with 12 label domains.  My perhaps radical suggestion is to
say that if the author domain does not exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and
you do whatever you do to mail with fake addresses.  Or perhaps you only say that if it's NXDOMAIN and has more than
four labels.  That way if you really want to use 12 label addresses, you have to add a _dmarc record every four
levels.  Nobody will do that, but nobody sends mail like that other than to be perverse, so it doesn't matter.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Oct 2021 06:52:55 -0400

On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote:
> >For a 'normal' domain/sub-domain like eml.example.com where the domain has
> >a DMARC policy, every single implementation approach gives the same
> >answer, so it doesn't matter.  The challenge is getting all the other
> >cases right.
> >
> >Until we understand what we want, overall, selecting a specific design to
> >achieve that goal is premature.  Both of those approaches will give a
> >wrong answer (at least as I'd define it) for less usual cases.
> The problem with organizational domain is that it is ill-defined.  It waves
> its hands and says to use something like the PSL, and in practice everyone
> uses the PSL.  But the PSL is a moving target, with entries added and
> deleted on a regular basis, so this month's organization domain may not be
> the same as last month's.  The advantage of the tree walk is that the DMARC
> result now depends entirely on what is in the DNS, not on a volunteer
> maintained list whose volunteers keep reminding us that it's only intended
> to manage http cookies.
> 
> Todd's stats confirm my intuition that the DNS is pretty flat, and the
> amount of mail that comes from addreses with more than, say, four labels is
> miniscule.  So if you do a four level tree walk, you will find all of the
> The question remains what to do about the fake mail with 12 label domains. 
> My perhaps radical suggestion is to say that if the author domain does not
> exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and
> you do whatever you do to mail with fake addresses.  Or perhaps you only
> say that if it's NXDOMAIN and has more than four labels.  That way if you
> really want to use 12 label addresses, you have to add a _dmarc record
> every four levels.  Nobody will do that, but nobody sends mail like that
> other than to be perverse, so it doesn't matter.

Thanks.  From the bottom up, I think that seems reasonable, but my concern 
(not surprisingly) is on the other end of the question.  Should a policy found 
at _dmarc.com be treated differently than _dmarc.example.com?  If so, then what 
about _dmarc.gov.uk versus _example.gov.uk and how do we distinguish between 
the first set and the second?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2021 15:28:53 -0400

>the first set and the second?

Since we are writing a technical spec, the only answer is that we don't.
The PSL, or anything like the PSL, is only someone's guess about relationships
between various DNS subtrees.

Let us not rehash the theological argument about who controls the DNS tree,
the technical faction saying that each zone controls all of its descendants,
and the political faction saying we have rules about that not visible in
the DNS.  One the one hand, zones like .BANK have real contracts that they
want to enforce, but on the other hand, we have overclever hosting providers
who imagine that the PSL is a get out of jail card for dealing with sleazy
customers, and the PSL maintainers are not happy:

https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion

I would say that if you have an issue with a DMARC record in the
tree above your domain, that's a business issue with whoever
controls that record, not a technical one.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Thu, 28 Oct 2021 06:31:15 -0400

John's idea is workable for policy lookup, but the PSL is also used for
alignment and to protect the PSL names.

Alignment starts by finding the longest shared DNS path between two
addresses.   The resulting string must be longer than any PSL entry, to
verify that the names are in the same organization.

Additionally, any email domain-part which exactly matches a PSL entry is
fake (unless the PSL is wrong) and should be blocked.

An alternative would require every organization to create a DNS token that
says "ToipOfOrganization" at organization boundaires, but getting worldwide
participation is unlikely.

The best result would be for IANA to maintain the PSL.  It seems obvious
that this should be part of their job.  But I assume that has been tried
without success.

On Tue, Oct 26, 2021 at 10:09 PM John Levine <[email-masked]> wrote:

> >For a 'normal' domain/sub-domain like eml.example.com where the domain
> has a DMARC policy, every single implementation approach gives the
> achieve that goal is premature.  Both of those approaches will
> The problem with organizational domain is that it is ill-defined.  It
> waves its hands and says to use something
> like the PSL, and in practice everyone uses the PSL.  But the PSL is a
> moving target, with entries added and deleted
> on a regular basis, so this month's organization domain may not be the
> same as last month's.  The advantage of the
> amount of mail that comes from addreses
> The question remains what to do about the fake mail with 12 label
> domains.  My perhaps radical suggestion is to
> say that if it's NXDOMAIN and has more than

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Oct 2021 10:33:18 -0400

> The best result would be for IANA to maintain the PSL.  It seems obvious that this should be part of their job.

Well, to be clear about what that would mean: IANA doesn't "manage"
any registries in the sense that they determine the contents.  They
administer the registries under direction from the IETF and/or
designated experts.  So, having IANA administer (or host) the PSL
would still mean that some designated expert or team of such would
have to tell them what changes to make when.

The benefits we'd get from IANA would be a long-term well-known place
to find it, and a process to control the updates.  But the mechanism
for making changes would be the same.

Barry

---

From: Joe Humphreys <[email-masked]>
Date: Thu, 28 Oct 2021 10:56:45 -0400

Why not allow the DMARC record to specify what domain root the identifier
must align with? Instead of adkim=r meaning "consult the PSL list", use
adkim=example.com to mean "use relaxed alignment, and the organizational
domain is example.com".

On Thu, Oct 28, 2021 at 10:33 AM Barry Leiba <barryleiba=
[email-masked]> wrote:

> that this should be part of their job.
>

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2021 13:11:14 -0400

>adkim=example.com to mean "use relaxed alignment, and the organizational

Because first you have to figure out where to look for the DMARC record.

If you have domains aa.bb.cc.de.us, or ee.ff.gg.hi.us, where do you
look for the org records if the domain itself doesn't have a DMARC
record? The PSL tells us that they're _dmarc..bb.cc.de.us and
_dmarc.gg.hi.us.

R's,
John

---

From: Joe Humphreys <[email-masked]>
Date: Thu, 28 Oct 2021 13:52:26 -0400

Sorry, I should have made it clear that my suggestion was in the context of
the tree-walk proposal. Douglas Foster had pointed out that tree-walking by
itself doesn't eliminate the need for the PSL, because the relaxed
alignment rules still require you to know the organizational domain. I
believe my suggestion solves that problem, without requiring any new DNS
records.

Regards,
Joe H

---

From: "John R Levine" <[email-masked]>
Date: 28 Oct 2021 14:17:55 -0400

> alignment rules still require you to know the organizational domain.

Doug misundersands my proposal.  The tree walk is instead of the PSL.  You 
look up four levels in the tree and if you don't find anything, you're 
done.

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

---

From: Joe Humphreys <[email-masked]>
Date: Thu, 28 Oct 2021 14:27:21 -0400

In your proposal, what happens if you find a record that specifies aspf=r;
the From header is aa.bb.cc.de.us, and the Envelope From is ee.ff.gg.hi.us?
How do you decide whether the common suffix .us is sufficient for relaxed
alignment?

Regards,
Joe H

---

From: "John R Levine" <[email-masked]>
Date: 28 Oct 2021 14:47:54 -0400

> How do you decide whether the common suffix .us is sufficient for relaxed

Walk up from aa.bb.cc.de.us and stop when you find a _dmarc record.  If 
it's _dmarc.us, then ee.ff.gg.hi.us is OK for a relaxed match.  If it's 
below that, it isn't.

Regards,

---

From: Joe Humphreys <[email-masked]>
Date: Thu, 28 Oct 2021 15:25:13 -0400

If I understand your suggestion, then I think you lose some flexibility
that way. Suppose you want to use relaxed alignment. Say you have some
subdomains that you want to use p=reject for, but at the organizational
level, you want p=none.

_dmarc.sub.org.tld TXT "v=DMARC1;p=reject;aspf=r"
_dmarc.org.tld TXT "v=DMARC1;p=none;aspf=r"

You get a message with RFC5322.From domain sub.org.tld, and
RFC5321.MailFrom domain other.tld.

So the first record you find, at _dmarc.sub.org.tld doesn't give you enough
information to judge alignment. Do you keep walking? I suppose you could
jump to the longest common domain (tld in this case) and start walking
again there.

Regards,
Joe

---

From: "John R Levine" <[email-masked]>
Date: 28 Oct 2021 15:37:47 -0400

> jump to the longest common domain (tld in this case) and start walking

It's not that you lose flexibility, it's that it's different.  A tree walk 
lets you put different policies at labels between the org domain and the 
leaf, while the current PSL approach doesn't. The question is whether it's 
different in a way that's better or worse or indifferent.  Given the 
numbers that show how flat the DNS tree is, my guess is that it's 
indifferent.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Oct 2021 17:12:51 -0400

On Wednesday, October 27, 2021 3:28:53 PM EDT John Levine wrote:
> >> domains.
> >(not surprisingly) is on the other end of the question.  Should a policy
> >found at _dmarc.com be treated differently than _dmarc.example.com?  If
> >so, then what about _dmarc.gov.uk versus _example.gov.uk and how do we
> >distinguish between the first set and the second?
> 
> The PSL, or anything like the PSL, is only someone's guess about
> relationships between various DNS subtrees.
> 
> want to enforce, but on the other hand, we have overclever hosting
> providers who imagine that the PSL is a get out of jail card for dealing
> with sleazy customers, and the PSL maintainers are not happy:
> 

I didn't like this when I first read it.  Contrary to my usual practice, I 
didn't react immediately and sat on it to think about it instead.

It's growing on me.

If I understand correctly, there really isn't a technical difference between 
_dmarc.example.com and _dmarc.gov.uk and so from the point of view of an RFC 
that defines DMARC and DMARC interoperability we can't and shouldn't 
distinguish between them.

There are, however privacy and security concern differences between processing 
a record for _dmarc.example.com and _dmarc.com.  We can, and should explain 
those differences in the security and privacy considerations sections of the 
eventual DMARC RFC, but if com should publish a DMARC policy is really between 
the operator of com and ICANN and if ICANN were to allow it, it would be up to 
com domain registrants to decide how to deal with it (to be clear, I think it  
would be horrible if that happened, but that's not a technical, 
interoperability horror, it's about privacy and security).

Technically, the change is:

Lookup policy and if not found, lookup up the next level (up to 4) instead of 
lookup policy and if not found, consult PSL and lookup the org domain.

For the common case like eml.example.com where there is no DMARC record the 
trade is one extra DNS lookup in exchange for getting the PSL out of the 
equation.  

Assuming I have that right, I think that is a reasonable path forward that 
would solve a number of problems.  The key is to get the security and privacy 
considerations documented so that ICANN and ccTLD operators are informed and 
can set their own rules appropriate.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2021 20:58:12 -0400

>It's growing on me.

Ooh, cool.

>interoperability horror, it's about privacy and security).

Right - it's not a problem with a technical solution.

I know several of the people who run the PSL and while they try very
hard to do a good job, they are just volunteers and have no unique insight
into DNS policy truth.  There are a few places where they have specifically
decided to punt, like not including the 15,000 2LDs in .name under which they
sell 3LDs.

>trade is one extra DNS lookup in exchange for getting the PSL out of the 

Sounds right.

>can set their own rules appropriate.

I would be pretty surprised if ICANN had any interest in this other than using
their existing RSTEP process if some TLDs want to publish _dmarc.<tld>.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 29 Oct 2021 01:15:10 +0000

>their existing RSTEP process if some TLDs want to publish _dmarc.<tld>.

Yes, and ccTLD operators for whatever processes they use.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Fri, 29 Oct 2021 07:06:18 -0400

PSL entries are imputed with four important characteristics:
- name not valid for MAILFROM
- name not valid for FROM
- name not valid for DKIM
- name not valid as an alignment point for mismatched names.

For non-PSL names, the reverse is assumed by default - any name is valid
for any of these purposes.

It is important to note that the PSL covers all possible names -- if a name
prefix is not in the PSL, we assume it is a fake name.    Experience also
indicates that it is trusted as accurate.  We have not spent any time
talking about a need for PSL override rules.

Finding the first available DMARC policy, as John suggests, does not come
close to replacing the PSL.

- First, DMARC policies do not cover all possible names, which is a
rather critical problem.

- Secondly, even when they are present, the first-match DMARC policy does
not define all valid alignment points.   Consider unit2.example.com and
unit1.example.com.   Each unit may have its own DMARC policy, but the
parent domain may still be a valid alignment point.

I can test alignment without a DMARC policy, but I cannot test alignment
without a PSL or a comparable replacement.   We could define DNS flags to
cover the four PSL characteristics listed above, and those flags have
potential use cases outside of the PSL   But we have already concluded that
we cannot reliably expect every PSL to configure DNS entries to meet our
needs, so the DNS-based PSL would lack the necessary trust that we have in
the current PSL.

Doug

On Wed, Oct 27, 2021 at 3:29 PM John Levine <[email-masked]> wrote:

> found
> providers

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 29 Oct 2021 10:03:06 -0400

> needs, so the DNS-based PSL would lack the necessary trust that we have in

Have you looked at the PSL?  I mean the actual content?

In the public names section of the PSL, here are the entries with three or 
more dots:

schools.nsw.edu.au
pvt.k12.ma.us
chtr.k12.ma.us
paroch.k12.ma.us

I think it was a mistake for RFC 7489 not to specify that the private domains 
section of the PSL shouldn't be used.  Using the private ones doesn't change 
the equation much, but I don't think these merit any special consideration.  
It does get you one more dot.  Here's the four dot private names:

*.compute.amazonaws.com.cn
cn-north-1.eb.amazonaws.com.cn
cn-northwest-1.eb.amazonaws.com.cn
*.elb.amazonaws.com.cn
s3.cn-north-1.amazonaws.com.cn
s3.dualstack.ap-northeast-1.amazonaws.com
s3.dualstack.ap-northeast-2.amazonaws.com
s3.dualstack.ap-south-1.amazonaws.com
s3.dualstack.ap-southeast-1.amazonaws.com
s3.dualstack.ap-southeast-2.amazonaws.com
s3.dualstack.ca-central-1.amazonaws.com
s3.dualstack.eu-central-1.amazonaws.com
s3.dualstack.eu-west-1.amazonaws.com
s3.dualstack.eu-west-2.amazonaws.com
s3.dualstack.eu-west-3.amazonaws.com
s3.dualstack.sa-east-1.amazonaws.com
s3.dualstack.us-east-1.amazonaws.com
s3.dualstack.us-east-2.amazonaws.com
app.os.stg.fedoraproject.org
users.scale.virtualcloud.com.br
it1.eur.aruba.jenv-aruba.cloud
cloud.jelastic.open.tim.it

If you include the private names, the organizational domain for 
example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-
northeast-1.amazonaws.com, not amazonaws.com (RFC 7489 3.2 Step 3 specifies the 
longest match).  That can't be what we would want.

As John has suggested, DNS is pretty flat and there are solutions for fakes 
that are deep in the tree that don't need the PSL.  If paroch.k12.ma.us were 
to publish a DMARC record that caused a problem for a parochial school in the 
US state of Massachusetts, then I think it's fair to say that the school 
should take that up with the operator of paroch.k12.ma.us.  It's enough of a 
corner case that it's not worth giving up the benefit of not being dependent on 
the PSL.

Keep in mind, even if you're assessment were correct and we agreed it's 
important, it would only describe the PSL as it exists today with an 
assumption it's accurate.  If you look in the comments of the PSL it's clear 
that it is incomplete, known to be incomplete by the PSL maintainers, and will 
remain that way.

Even if we liked the idea of email being dependent on an external list, it's 
not clear that the PSL is really a complete enough answer to that question.  
It got DMARC out the door to start, but let's not pretend it's more than it 
is.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Oct 2021 18:48:38 +0200

On Fri 29/Oct/2021 03:15:10 +0200 Scott Kitterman wrote:
>>> The key is to get the security and privacy considerations documented so
>>> that ICANN and ccTLD operators are informed and can set their own rules
>>> appropriate. >>

Verisign is not new to abusive behavior.  About 20 years ago they used to reply 
with one of their servers' IP addresses to any query like 
www.<unregistered-2LD>.com.  ISC came out with the "root-delegation-only" hack 
to counter that.

IMHO, we shouldn't throw away the PSL.  Most importantly, we should stick to 
the concept of Organizational Domain.  We can give an abstract definition of 
the latter in terms of affiliation of some kind.  Then the spec can leave it to 
developers to decide how to find it: tree-walk, PSL, dbound or whatever thing 
like it will eventually come about, or even a mix of those.  That way, code 
using the PSL wouldn't be obsoleted.  For new code, some configuration stuff to 
skip useless queries to _dmarc.com would be useful anyway.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2021 13:31:52 -0400

>www.<unregistered-2LD>.com.  ISC came out with the "root-delegation-only" hack 

Oh, please.  That was the sitefinder fiasco which led to lawsuits and convulsions
at ICANN, and considerable contract revision.  Nothing like that will happen
again for reasons I can explain privately for anyone who cares.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 29 Oct 2021 17:29:13 -0400

> other than to be perverse, so it doesn't matter.

Based on the longest true PSL entry being 4 labels, we could also just jump to 
the 5th and walk up from there.  It would give every domain that currently has 
the ability to express a domain policy the ability to do so and bound the 
total number of lookups you could get stuck with for the perverse case.  
Something like the attached.

This shows the change from the current 6.6.3.  It's largely a merge of text 
from the current 3.2 and 6.6.3 adjusted for the proposal.  All of 3.2 and any 
reference to organizational domain would also be removed.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Oct 2021 15:17:43 -0700

> again for reasons I can explain privately for anyone who cares.

Except that repetition of the same action is not what was being 
suggested.  Rather, a matter of corporate culture was.

I'm not commenting on the company, but do suggest that it helps more to 
respond to a point being made than to a point not being made.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: "John R Levine" <[email-masked]>
Date: 29 Oct 2021 20:02:35 -0400

>> Oh, please.  That was the sitefinder fiasco which led to lawsuits and 
>> convulsions at ICANN, and considerable contract revision.  Nothing like that will 
>> happen again for reasons I can explain privately for anyone who cares.
>
> Except that repetition of the same action is not what was being suggested. 
> Rather, a matter of corporate culture was.

That was one event eighteen years ago.  Since they haven't done anything 
else like that since then, perhaps they learned a lesson.

Every gTLD operator has a web of contracts with ICANN, and Verisign also 
with the US government, which severely constrain what they can do with 
their TLDs.

If someone believes that Verisign or any other TLD operator might do 
something bad, and that using the PSL would fix the badness, we really 
need details about what the bad thing might be and what the fix would be. 
I am probably as involved with ICANN and TLD operators than anyone else 
here and I just don't see it.  I'm not saying any of the operators are 
paragons of sweetness and light, but I am saying I do not see anything 
they could do that would affect the way DMARC works.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Oct 2021 17:11:56 -0700

On 10/29/2021 5:02 PM, John R Levine wrote:
>>> Oh, please.  That was the sitefinder fiasco which led to lawsuits 
>>> and convulsions at ICANN, and considerable contract revision.  
>>> Nothing like that will happen again for reasons I can explain 
>>> privately for anyone who cares.
> That was one event eighteen years ago.  Since they haven't done 
> anything else like that since then, perhaps they learned a lesson.

When Jon Postel had half the root servers change where they took the 
master data from, it was not as a demonstration of his power, 
independent of the US government, as is often claimed.

The same folk in question here ran that master DNS root and were 
threatening to go rogue and Jon wanted to make sure it would be possible 
to marginalize the damage if they did.

cf, my above reference to corporate culture.

A variant of trust-but-verify is trust-but-prevent.

> Every gTLD operator has a web of contracts with ICANN, and Verisign 
> also with the US government, which severely constrain what they can do 
> with their TLDs.

Yes, yes.  All of them are well-behaved, following all the rules, and 
the rules perfectly protect against misbehaviors, which they'd never 
think of finding a way around.

d/

-- 

Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2021 20:14:46 -0400

>total number of lookups you could get stuck with for the perverse case.  

That's not a bad idea, deals with the real cases without a lot of wheel spinning
for the silly ones.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 29 Oct 2021 21:06:53 -0400

On Fri, 29 Oct 2021, Dave Crocker wrote:
> Yes, yes.  All of them are well-behaved, following all the rules, and the 
> rules perfectly protect against misbehaviors, which they'd never think of 
> finding a way around.

Can you explain what this line of argument has to do with DMARC?  I'm 
drawing a blank.

If it's that any TLD operator might at any time do something horrible, 
even though they never have before, it seems to me that the only 
reasonable option is to abandon the DNS.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Oct 2021 18:14:41 -0700

On 10/29/2021 6:06 PM, John R Levine wrote:
> an you explain what this line of argument has to do with DMARC?  I'm 
> drawing a blank.
>

Sorry you lost the thread.  To review:

Alessandro expressed concern about a particular company's demonstrated 
predilection for what was classed as abuse.

You attempted to dismiss his concern with an irrelevant point about the 
particulars of the specific abuse he cited.

I pointed out that you'd missed the point that he cited as issue with 
corporate culture.

You again attempted to dismiss the point by claiming it was a single 
event, long ago.

I point out that there was a pattern of behavior and concern about them.

You are now claiming that all this is irrelevant to the current topic.

Except that Alessandro's original reference was in the service of 
explaining why a mechanism DMARC relies on, for establishing 
organization authority, should not necessarily rely on everyone's being 
a good actor.

A point that is entirely relevant and would have been easier to focus 
on, had you not chosen to distract from it.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2021 21:40:49 -0400

>organization authority, should not necessarily rely on everyone's being 

I take it you are agreeing that we should stop using the PSL.  It's just
a bunch of thinly funded volunteers and a github repo.  Who knows what
they might decide to do tomorrow?  

Unlike the other parties we've been discussing, they have no contracts
and no consequences if they decide to close up shop or do something
strange and unexpected that we might not like.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Fri, 29 Oct 2021 21:58:00 -0400

I enthusiastically endorse John's proposal for policy discovery.  But as
stated previously, I do not see that it provides a viable mechanism for
eliminating the PSL as an alignment tool.   To address that part of the
problem, I submit my proposal for migrating from the publicsuffix.org list
to DNS flags.

Doug Foster

PSL replacement using DNS Flags

This proposal specifies a resource record that can be used to distinguish
between PSL names and organization-controlled names.  The design also
permits fine-tuning of organization-controlled names to obstruct misuse of
those names.

When this mechanism is available, it provides sufficient information to the
evaluator so that the Public Suffix List from publicsuffix.org does not
need to be checked.   In the future, if participation becomes sufficiently
widespread, evaluators may choose to bypass the publicsuffix.org list
completely.
Resource Record Definition (type=TXT)

All interpretations apply to the Resource Record’s DNS name.   No cascading
of information is used.

Label:                    DMARCFLAGS

Version tag         v=1

Tokens:

·         SMTPFROM=FALSE
Name is never used for SMTP MailFrom addresses.  Stronger repudiation than
SPF FAIL.  Equivalent to “SPF -ALL”, primarily included here for simplified
PSL configuration.  Applicable if no SPF policy exists.  If an SPF policy
exists, the policy takes precedence.  When omitted, the default
interpretation is TRUE, the name may be used for SMTP MailFrom.

·         MSGFROM=(TRUE | FALSE )
When this token is not used, the default depends on SPF.  If SPF is “-ALL”
or SMTPFROM=FALSE, the MSGFROM defaults to FALSE.  If any other SPF record
exists, defaults to TRUE.  If no SPF record exists, default is UNKNOWN.

o   MSGFROM=FALSE
Name is never used for message FROM header address.  Stronger repudiation
than DMARC FAIL.

o   MSGFROM=TRUE
Name may be used for message FROM header address.   Primarily used to
ensure that From non-existence tests recognize that the name exists and is
valid for Email FROM addresses.

·         DKIM=FALSE
Stronger than DKIM verification failure.   If name cannot be verified
because a public key is not found in DNS, treat the signature as a fake.
When not present, TRUE is assumed.

·         ALIGN=FALSE
Name is not usable for alignment of non-matching domain names.   Primarily
used to indicate a PSL entry.  When not present, TRUE is presumed.
Specifying ALIGN=FALSE implies that all parent domains are also
characterized by ALIGN=FALSE.  To avoid inconsistent results, it should
only be published when parent domains have also published ALIGN=FALSE.
Use Cases PSL Name

A PSL name is not usable for mail or for alignment, so the record has these
values:

“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFFROM=FALSE DKIM=FALSE ALIGN=FALSE”
Organization-owned Mail Server

An organization-owned mail-sending server uses its own domain for both the
SMTP MailFrom and the message From header, and is also likely to use the
domain name to sign messages.   So all defaults are applicable and the
MSGFROM clause is optional as long as an SPF record is present.   To be
explicit, this record would be used.

“DMARCFLAGS v=1 MSGFROM=TRUE”
Organization subdomain used only for Mailing Service messages

Mailing services typical use one of their own subdomains for the SMTP
MailFrom address, to ensure SPF PASS.   The client organization chooses the
message From address from the domain tree that it controls.   If a From
address subdomain name is only used in this context, it may have no other
existence in DNS, without this clause, it might be considered
non-existent.   This record documents the use of the name for the message
FROM header while repudiating its use for SMTP MailFrom.

“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=TRUE”
Mailing service SMTP names used for client messages

Mailing services typically use their own subdomain names for the SMTP
MailFrom address, to ensure SPF PASS.  These subdomain names are typically
used only in this context, never for sending the service provider’s own
mail.  The subdomain may or may not be used for DKIM signatures, so these
records are possible.

“DMARCFLAGS v=1 MSGFROM=FALSE”
or
“DMARCFLAGS v=1 MSGFROM=FALSE DKIM=FALSE”
Holding Company with Isolation between Subsidiaries

This is an unlikely situation, but is supported by the design.  Assume that
Example.Com is a large conglomerate with subsidiaries involved in
activities as wide-ranging as oil exploration and home repair.
Example.Com does not want to allow subsidiaries to send on each other’s
behalf, so it does not want the corporate parent domain to be used for
alignment.   Corporate messages will be sent using exact-match alignment,
while subsidiary companies will use normal alignment up to the subsidiary’s
parent domain.  This record documents the holding company policy:

“DMARCFLAGS v=1 ALIGN=FALSE”
Domain or Subdomain which is never used for sending email

If a name is not used for either SMTP MailFrom or message FROM header, then
the name can be strongly protected against misuse with this record:

“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=FALSE DKIM=FALSE”

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Oct 2021 19:08:21 -0700

On 10/29/2021 6:40 PM, John Levine wrote:
> I take it you are agreeing that we should stop using the PSL.

Since I never said or implied anything of the sort, it's odd you would 
choose to again introduce such a distraction, given the exercise we've 
just gone through.  Please stop.

>    It's just

You mean, like the DNS root operators?

But, again, this is, at best, only tenuously relevant to the original point.

I will bet that, with some effort, you could find a way to make a 
relevant response to Alessandro's original point.  Please feel 
encouraged to try.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2021 22:56:40 -0400

I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any.

Please consider the environment before reading this message.
John Levine, [email-masked] 

> On Oct 29, 2021, at 22:08, Dave Crocker <[email-masked]> wrote:
> 
> Since I never said or implied anything of the sort, it's odd you would choose to again introduce such a distraction, given the exercise we've just gone through.  Please stop.
> 
> 
>>   It's just
> I will bet that, with some effort, you could find a way to make a relevant response to Alessandro's original point.  Please feel encouraged to try.
> 
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Oct 2021 20:10:13 -0700

> I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any.

1. I've reviewed what I believe are all of your relevant postings on 
this thread and managed to miss where you asked that.  Please point to 
the message.

2.  Though I admit it's a bit difficult to discern exactly what your 
concern is, I read the motivating text as encouraging the development of 
a thoughtful privacy and security considerations section.  Oddly, you 
appear to have objected to that point.  Can't guess as to why.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 30 Oct 2021 03:15:14 +0000

>“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=FALSE DKIM=FALSE”

None of that is needed for DMARC.  

Also, if you want to communicate a domain name is never used in Mail From, you can already publish v=spf1 -all.  The absence of a published selector does the same for DKIM.

Why don't you focus in on the problem you are trying to solve before you jump to a specific solution, because I can't tell what it is?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 30 Oct 2021 03:48:26 +0000

>appear to have objected to that point.  Can't guess as to why.

I didn't think he was objecting, I thought he was specifying the target audience.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2021 13:42:01 -0400

>skip useless queries to _dmarc.com would be useful anyway.

The problem with that approach is that different people evaluating the
same message will get different answers, unless you carefully figure
out every possible way one might look for an organizational domain and
be sure that you publish whatever every option needs. When we're
writing standards, options are bad since more options mean more bugs
and more ways not to interoperate. Pick one method and tell people to
use it.

I can't get too worried about the query to _dmarc.com.  For one thing, for the
stuff Scott is doing, while _dmarc.com is unlikely to exist, _dmarc.bank is
on the roadmap.  For another, in 99.99% of cases the _dmarc.com query will
be answered from a local cache so it's fast and cheap.

The PSL is over 200K and has over 9000 entries, so you can do a lot of
local DNS queries in the time it takes to read and parse the PSL. I
think the tree walk is likely to be at least as fast, maybe faster
than using the PSL.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 Oct 2021 20:20:19 +0200

On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote:
>> uses the PSL.

That usage has proven to work quite well.  And some respect for the installed 
base wouldn't hurt.

>> But the PSL is a moving target, with entries added and deleted on a
>> regular basis, so this month's organization domain may not be the same as
>> last month's.  The advantage of the tree walk is that the DMARC result now
>> depends entirely on what is in the DNS, not on a volunteer maintained list

The whole DNS is a moving target.

> Something like the attached.

That sounds much like the poor man's do-it-yourself PSL.

> reference to organizational domain would also be removed.

I disagree.  The concept of Organizational Domain has been a winning point of 
DMARC.  We should keep it.  Instead of the pragmatic definition given in 
Section 3.2 of RFC 7489, we can say something like the current Section 3.9, but 
turning the reference to Section 3.15 into an example rather than a normative 
algorithm.

The spec should recall that the DNS is a hierarchy so that an affiliation 
between the parent zone and the delegated domain can be assumed, unless the 
parent is a public registry or similar entity.  Situations like .BANK and 
.GOV.UK can be mentioned.  A definition of Organizational Domain given in such 
abstract terms is semantically solid and makes for a good conceptual guidance.

Suggestions about how to deal with corner cases like >5 labels or TLDs can be 
given.  According to the above discussion, a programmer cannot code a behavior 
outside of the rules, irrespective of her decision to use (part of) the PSL or 
any other configuration file to assist tree walking.

Configuration files avoid to hard code stuff like that ">5".  Users can adjust 
those files instead of waiting for new software releases.  And the PSL is just 
a kind of configuration file, albeit complex.  It assists in walking up the 
tree at more than one label at a time.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 30 Oct 2021 19:55:59 +0000

>That usage has proven to work quite well.  And some respect for the installed 

The alternative I suggested is 100% compatible with the installed base.  If a domain has published DMARC policy per RFC 7489, the proposed new approach will still find it.  I agree that something which would require existing DMARC records to be changed would be a non-starter.

I'm not sure how much more respectful we can manage to be.

 Scott K

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2021 20:47:51 -0000

According to Scott Kitterman  <[email-masked]>:
>The alternative I suggested is 100% compatible with the installed base.  If a domain has published DMARC policy per RFC 7489, the proposed new approach will
>still find it.  I agree that something which would require existing DMARC records to be changed would be a non-starter.
>

I'd say it's 99.4% compatible with the existing usage. If you have

_dmarc.x.foo.com
_dmarc.foo.com

and you have a message from [email-masked], the current scheme will
skip up to _dmarc.foo.com while a tree walk will find _dmarc.x.foo.com.

I doubt that will make any difference in practice.  If there really are any
situations like that, who knows what they think it does now.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 30 Oct 2021 20:56:00 +0000

>situations like that, who knows what they think it does now.

Yes.  Under this new approach it's possible to publish records that would be found that would be skipped by old implementations, but the other way around it's fine.  It should find 100% of  the currently published records.

I think it would be appropriate to have some kind of note warning not to assume intermediate domains are queried for policy due to legacy code 

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Oct 2021 11:48:15 +0100

> and more ways not to interoperate. Pick one method and tell people to

The example on the other thread, [email-masked], illustrates this variability 
well.  As you say, it shouldn't make much difference in practice.  Of course, 
if an organization publishes inconsistent DMARC records, they can get 
surprisingly different results.

On the other hand, even if we deprecate the PSL, there will be  number of old 
implementations around for years.

> be answered from a local cache so it's fast and cheap.

Comparing against a list of six PSDs is even faster and cheaper.

> local DNS queries in the time it takes to read and parse the PSL.

Yes.  I downloaded a copy from publicsuffix.org now, and found:

    19,268  4,817 trie_nodes of size 4 +
    18,884  9,442 num_strings of size 2 +
     9,442  9,442 flags of size 1 +
    52,701  total string table size =
   -------
   100,295

> I think the tree walk is likely to be at least as fast, maybe faster than
> using the PSL.

No.  After compiling the list —which is not done every day— a binary search is 
lightning fast.  At least, it is comparable to a DNS cache lookup.  And if you 
don't hit the cache, you must spend the extra time to send a query, receive a 
response and possibly check DNSSEC.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Oct 2021 12:29:41 +0100

On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote:
>>> The alternative I suggested is 100% compatible with the installed base.
>>> If a domain has published DMARC policy per RFC 7489, the proposed new
>>> approach will still find it.

Yes, but would PSL-based DMARC filters have to be re-written, re-tested, 
re-installed?

>>> I agree that something which would require existing DMARC records to be
>>> changed would be a non-starter.

That's pct=, but I'm digressing...

>> I doubt that will make any difference in practice.

Agreed.

>> If there really are any situations like that, who knows what they think it
>> does now.

Since they all belong to the same organization, their policies should be concerted.

> Yes.  Under this new approach it's possible to publish records that would be found that would be skipped by old implementations, but the other way around it's fine.  It should find 100% of  the cur…

Another criterion, beside tree-walk and PSL, could be to look at the d= tag of 
the DKIM signatures that are aligned with the From: domain.  Would that be 
semantically equivalent to the procedure described in the current Section 6.7.2?

> I think it would be appropriate to have some kind of note warning not to assume intermediate domains are queried for policy due to legacy code

Agreed.  Intermediate domains, the ones between the From: domain and its 
Organizational Domain, would be considered like some kind of proxy, or even a 
more specific alternative to the Organizational Domain or the possible PSD. 
Still, checking each and every intermediate domain may remain optional.

The concept of Organizational Domain is still useful for receivers, as it helps 
setting up reputation databases.  In this respect, the PSL is also useful 
outside the DMARC protocol; for example, to get the organizational domain of 
HELO arguments.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sun, 31 Oct 2021 07:30:29 -0400

We have two issues floating here:
1) For policy lookup, replace the PSL with a constrained tree walk.
2) For authentication testing, replace the PSL with something based on the
policy lookup.

Currently, the DMARC policy has nothing to do with the authentication
test.

If the second idea is still on the table, we need a definition and a
defense of the algorithm.   If the suggestion is withdrawn, please say so.

Doug Foster

On Sat, Oct 30, 2021 at 3:56 PM Scott Kitterman <[email-masked]>
wrote:

> waves
> approach will still find it.  I agree that something which would require
> existing DMARC records to be changed would be a non-starter.
>

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Oct 2021 12:57:32 +0100

On Sat 30/Oct/2021 05:15:14 +0200 Scott Kitterman wrote:
>> I enthusiastically endorse John's proposal for policy discovery.
>>
>> [...]

IMHO, that design has the same flaw of SPF, of requiring an organization to 
define RRs for almost every host.  DMARC overcame that hurdle using the PSL.

> None of that is needed for DMARC.

Still, it could be possible to specify policy discovery so that if one day 
something like Doug's idea, or like Dbound, were going to be available, even 
partially, then it could be applicable without requiring a new spec.  As long 
as there's semantic equivalence, that is.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2021 11:01:03 -0400

>Yes, but would PSL-based DMARC filters have to be re-written, re-tested, 

If we make any changes at all to DMARC, people will have to update their code.  That's not a very compelling argument.

>semantically equivalent to the procedure described in the current Section 6.7.2?

I don't understand what you're proposing.  Are you saying to look for DMARC records at
the d= domains in the signatures on a message?  What if it has no signatures but might
be SPF aligned?

>setting up reputation databases.

Sure.  You get the org domain via the tree walk.

> In this respect, the PSL is also useful 

I don't immediately see the utility of the org domain of the HELO unless you're
checking SPF on a bounce, but why wouldn't you do the same tree walk?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 31 Oct 2021 15:27:14 +0000

>Yes, but would PSL-based DMARC filters have to be re-written, re-tested, 

I don't think so.  Because, modulo the backwards compatibility note mentioned below (which I think is primarily a theoretical concern), existing implementations would find policies published under the new design, they wouldn't need to be changed to support this new policy discovery definition.

>That's pct=, but I'm digressing...

Completely separate issue, please don't.

>>> I doubt that will make any difference in practice.

Great.

>Since they all belong to the same organization, their policies should be concerted.

Yes.

>semantically equivalent to the procedure described in the current Section 6.7.2?

Sorry, 6.7 doesn't have numbered sub- paragraphs.  Did you mean 6.6.2?

Once you dig into 6.6.2 you end up at 3.1 identifier alignment.  For strict alignment, it works unchanged.  For relaxed, there's a potential for an issue.

Since since both 3.1.1 (DKIM) and 3.1.2 (SPF) define relaxed based on a common org domain, we would have to come up with a new definition.  

We can't, under the new design, use the policy domain as a substitute for org domain since that would potentially allow unrelated entities to generate aligned results if records are published above the current org domain level (as a totally hypothetical example, messages could be sent signed by state.gov From maryland.gov and they would align).

I think that if we changed the relaxed definition to the same as or a sub-domain of the From domain it would avoid potential issues like that without practical impact.  I don't think I have ever seen legitimate mail where Mail From or DKIM signing domain wasn't either the same or a sub-domain of From that were in the same org domain.

Someone with access to more data should check that.

>Still, checking each and every intermediate domain may remain optional.

As a practical matter, it would be optional since no one is likely to publish records for those domains, but we wouldn't specify it that way.  It would be a local optimization an implementer might choose.

>outside the DMARC protocol; for example, to get the organizational domain of 

Perhaps, but if it's not DMARC related, it's out of scope for our consideration.  In any case, none of those uses require commonality to support interoperability, they're all local functions.  I don't think we need any RFC definition to enable those uses.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 31 Oct 2021 15:29:58 +0000

Neither SPF nor DKIM use the PSL, so I still don't understand.  What do you mean by "authentication testing"?

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Sun, 31 Oct 2021 12:48:10 -0400

DMARC is an authentication test also.   The authentication of the first
identifier (SPF or DKIM) serves as a proxy to authenticate the second
identifer (FROM), which is conditioned on a satisfactory relationship
(equal or aligned) between the two domains.

You began to address the issue in your recent post, which included this:

I think that if we changed the relaxed definition to the same as or a
sub-domain of the From domain it would avoid potential issues like that
without practical impact.  I don't think I have ever seen legitimate mail
where Mail From or DKIM signing domain wasn't either the same or a
sub-domain of From that were in the same org domain.

You still need a way to protect the PSL names themselves, and this
paragraph does not do so.

Exact match to the authenticated domain is always sufficient to
authenticate the FROM domain.

>From a trust standpoint, the greatest trust occurs when the authenticated
identifier (SPF or DKIM) is the parent of the second identifier (FROM).
Based on my observed data, I agree that the norm is for FROM to be the
parent or the equal, rarely the child.   I should be able to provide some
data.   I will not have data about cousin relationships (unit1.example.com
aligned with unit2.example.com).

Doug

---

From: Douglas Foster <[email-masked]>
Date: Sun, 31 Oct 2021 12:51:57 -0400

John said

I don't immediately see the utility of the org domain of the HELO unless
you're
checking SPF on a bounce, but why wouldn't you do the same tree walk?

Apparently he has never evaluated the reputation of server organizations by
aggregating data based on server organization.   It is a pretty useful
exercise.  Scott is correct that this is not relevant to the RFCs we will
produce.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 31 Oct 2021 17:03:19 +0000

Perhaps it's a pointless semantic distinction.  I think of DMARC as a mechanism for expressing policy about authentication, not an authentication method.

I still don't understand what you think is unprotected.

Scott K

---

From: Dotzero <[email-masked]>
Date: Sun, 31 Oct 2021 13:50:29 -0400

On Sun, Oct 31, 2021 at 1:03 PM Scott Kitterman <[email-masked]>
wrote:

> Perhaps it's a pointless semantic distinction.  I think of DMARC as a
> mechanism for expressing policy about authentication, not an authentication
> method.
>

+1

DMARC allows the owners or administrators of a domain to express a policy
for email messages which fail to pass aligned DKIM or SPF and request
validators/receivers to act on that policy. In and of itself DMARC is not
an authentication method.

Michael Hammer

---

From: Douglas Foster <[email-masked]>
Date: Sun, 31 Oct 2021 21:29:19 -0400

To my mind, it is crazy talk to assert that DMARC is not an authentication
method.

My bank's phone app gives me the option of authenticating with either a
username+password or a fingerprint.   For remote access to work computers,
I use two authentication methods together.   Using two component methods to
accomplish an authentication process does not cause it to be something
other than an authentication process.

Specific to DMARC:
The sender's policy suggestion is probably the least important part of
DMARC v1.    The evidence given to this forum says that most senders do not
have a DMARC policy.  Of those that do, the policy is most often NONE, and
therefore useless.  Of all the mail that is blocked by
automation because of p=(reject | quarantine), a significant portion is
blocked for reasons that the recipient user considers incorrect.    So the
proportion of mail which is properly blocked because of a DMARC policy
looks rather tiny.

Nonetheless, about 85% of my incoming messages have FROM addresses that I
classify as "reliably identified".  This is mostly because of DMARC PASS,
but I also use some local policies serve as alternatives to DMARC PASS.   I
don't need a DMARC policy to produce DMARC PASS or FAIL.

A sender's policy expression is only meaningful because DMARC invented an
algorithm for authenticating the FROM address, something that had never
been done before.  Without an algorithm to generate PASS or FAIL, there is
nothing about which a sender can make a disposition suggestion.

Doug Foster

---

From: Douglas Foster <[email-masked]>
Date: Sun, 31 Oct 2021 22:19:02 -0400

Currently, the Publicssuffix.org list protects the PSL names.   Although I
don't believe it is covered anywhere in the DMARC v1 document, any DMARC
implementer will have to notice that a PSL name must produce DMARC FAIL,
because it cannot be authenticated itself, and it cannot be authenticated
by alignment with any other domain name.

If we could publish a rule which limits alignment to only work from an
authenticated domain name downward to a child subdomain, we would have a
secure design, because we would not need to worry about leaving the
authenticated organization.   But as long as upward alignment is
necessitated by current practice, we need to be concerned about leaving the
authenticated organization in the upward direction into the PSL.

A specific example:
MailFrom is "[email-masked]" and From is "trustme@com".
Any acceptable replacement for the PSL must ensure that this identifier
configuration is rejected.

When moving up the domain tree, the only way to avoid transiting from an
authenticated organization into the PSL, is to know what names are in the
PSL.    The alternatives seem to be (a) an externally obtained list, no
matter how imperfect, or (b) DNS entries, no matter how imperfect.    The
list seems the best option in the near term, but the DNS option might prove
valuable over time.

Doug

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Nov 2021 02:42:47 +0000

Ad hominem dismissal of things that you disagree with as "crazy talk" is not an effective form of technical argument.

Care to try again.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Nov 2021 02:46:28 +0000

>list seems the best option in the near term, but the DNS option might prove

What's wrong with what I already proposed?

Your analysis is backwards.  Modulo the few PSDs that have published records for PSD DMARC and for receivers that check for it, the DMARC results for mail to such domains is none, not fail.

Scott K