Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

From: "Doug Foster" <[email-masked]>
Date: Tue, 17 Nov 2020 09:46:19 -0500

I did not see a definition of a “non-existent domain” (the np policy).   A definition is needed.

To my thinking, the obvious rule should be to query for a NS record for the domain.  If the record exists, then the domain owner could create a DMARC record for that domain, or could create a default entry for the domain at the organizational level.  If no record exists, it is because the domain owner chose to not create one.

However, the DMARC Bis document conflicts strongly with this.  In section A.4, it suggest several ways to do a test of this type, then repudiates all of them.  NS lookup is not one of the mentioned options.

There is a possible second-level policy test for a “mail-enabled domain”.  I would define that test as “MX record exists or SPF policy exists”.    That could be an additional option to NP, but should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general solution to a general problem.    If there are still objections to it becoming a general solution, this should be addressed soon.

Doug Foster

From: dmarc [mailto:[email-masked]] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: [email-masked]
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

All

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues raised with some of the document.   Most of them are editorial but the one big item was the description of the Experiment.   The chairs sat down and broke out the experiment section into three separate experiments, and included language on how to capture the data to confirm how the experiment worked.  

It's enough of a change that we wanted to do a second working group last call to make sure the working group agrees with our changes. The diff of the current version with the previous version is here: 

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08 <https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09> &url2=draft-ietf-dmarc-psd-09

This starts a *one* week second working group last call for  draft-ietf-dmarc-psd

Please review the changes and offer up comments to the working group.

This working group last call 20 November 2020

Thanks,

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Thu, 19 Nov 2020 22:30:17 +0000

Section 2.7. defines a non-existent domain as "a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records.  This is a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied.  

The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. Although there may be domains that send email but not receive email and so may not have an MX record. Also, even if there is no SPF record, the domain may still send email, but then it might be held to a more stringent DMARC policy that would further penalize it for not having an SPF record. 

Also, for the revision of the document I like the way that the three parts of the experiment are now laid out more clearly.  My only comment is that the title of Appendix A is overly specific to just one of the experiments and so should be broader.

Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster <[email-masked]> 
Sent: Tuesday, November 17, 2020 9:46 AM
To: 'IETF DMARC WG' <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Doug Foster

All

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09

Thanks,

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 19 Nov 2020 21:27:17 -0500

Thank you for the pointer Eric.

Can someone explain why the chosen algorithm, which requires testing multiple conditions, is preferable to a single query for a name server record?   Minimizing DNS traffic has been part of our recent discussion, and minimizing software complexity is always a good thing.

Can someone also explain why the DMARC appendix takes such a strong stance against all queries for non-existent domains, regardless of technique?  It seems like the philosophical incompatibilities need to be addressed before both documents advance.

DMARC is specified only as a test for the RFC5322.From domain.   RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, but that is an ambiguous result, and SPF has no organization default mechanism.   

- Is there data to indicate whether evaluators have found that checking the RFC5321.MailFrom for non-existence is useful?   
- Suppose that the NP policy becomes generalized, and a domain has asserted a "must-exist" DMARC policy.   Should a non-existent subdomain used in the RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate organization, in an attempt to get whitelisted by spam filters which primarily evaluate the RFC5321.MailFrom address.   This attack could be paired with an unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise not generally known to be suspicious,   So my instinct is that some extension of DMARC to the SMTP address will be beneficial.

Doug Foster

----------------------------------------

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' <[email-masked]>, 'IETF DMARC WG' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Thanks,

Eric Chudow

I did not see a definition of a "non-existent domain" (the np policy).   A definition is needed.

There is a possible second-level policy test for a "mail-enabled domain".  I would define that test as "MX record exists or SPF policy exists".    That could be an additional option to NP, but should not be a replacement for it.

Doug Foster

All

Thanks,

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 19 Nov 2020 22:44:22 -0500

Time to show my ignorance again.

How do I check a domain for presence or absence of A, AAAA, or MX records?
I thought most domains were protected from enumeration, so one had to know a name to find out if it is defined

DF

From: "Douglas E. Foster" <[email-masked]>
Sent: 11/19/20 9:27 PM
To: "IETF DMARC WG" <[email-masked]>
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Doug Foster

Thanks,

Eric Chudow

Doug Foster

All

Thanks,

---

From: "John Levine" <[email-masked]>
Date: 19 Nov 2020 23:04:19 -0500

In article <[email-masked]> you write:
>Section 2.7. defines a non-existent domain as "a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX
>records.  This is a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the
>domain is not intended to be used and therefore could have a more stringent policy applied.  
>
>The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting.
>Although there may be domains that send email but not receive email and so may not have an MX record.

These days I think you will find that if the domains in your bounce
address and your From: headers don't have an MX or A record, very few
recipients will accept your mail. This seems like an edge case. In
practice I find that the domains caught by the Org domain or I suppose
PSD have A records but no mail server because they're actually web
hosts rather than mail hosts.

We have the Null MX to indicate that a domain receives no mail and SPF
plain -all to indicate that it sends no mail so I hope we don't try to
reinvent these particular wheels.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 19 Nov 2020 23:04:24 -0500

Doug

In looking for domain presence most folks will look at the domain itself.
There are a few web tools to enumerate
such as https://dnschecker.org/

Some examples
https://dnschecker.org/#MX/dmarc.org
https://dnschecker.org/#TXT/dmarc.org
https://dnschecker.org/#TXT/_dmarc.dmarc.org

There are unix tools - such as 'dig' - which are also quite useful.

hope this helps
tim

On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> ------------------------------
> *From*: "Douglas E. Foster" <[email-masked]>
> *Sent*: 11/19/20 9:27 PM
> *To*: "IETF DMARC WG" <[email-masked]>
> *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:
> Definition of NP
>
> Can someone explain why the chosen algorithm, which requires testing
> multiple conditions, is preferable to a single query for a name server
> record?   Minimizing DNS traffic has been part of our recent discussion,
> and minimizing software complexity is always a good thing.
>
> Can someone also explain why the DMARC appendix takes such a strong stance
> against all queries for non-existent domains, regardless of technique?  It
> seems like the philosophical incompatibilities need to be addressed before
> both documents advance.
>
> DMARC is specified only as a test for the RFC5322.From domain.
> RFC5321.MailFrom domains may also be non-existent.  They will return SPF
> NONE, but that is an ambiguous result, and SPF has no organization default
> mechanism.
>
>    - Is there data to indicate whether evaluators have found that
>    checking the RFC5321.MailFrom for non-existence is useful?
>    - Suppose that the NP policy becomes generalized, and a domain has
>    asserted a "must-exist" DMARC policy.   Should a non-existent subdomain
>    used in the RFC5321.MailFrom address be treated skeptically?
>
> I can imagine a scenario where a spammer uses a bogus subdomain of a
> legitimate organization, in an attempt to get whitelisted by spam filters
> which primarily evaluate the RFC5321.MailFrom address.   This attack could
> be paired with an unrelated and non-DMARC RFC5322.From address which is
> newly minted or otherwise not generally known to be suspicious,   So my
> instinct is that some extension of DMARC to the SMTP address will be
> beneficial.
>
> Doug Foster
>
>
>
>
> ------------------------------
> *From*: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
> *Sent*: 11/19/20 5:31 PM
> *To*: 'Doug Foster' <[email-masked]>, 'IETF DMARC WG' <
> [email-masked]>
> *Cc*: "[email-masked]'" <[email-masked]>
> *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:
> Definition of NP
>
> Section 2.7. defines a non-existent domain as "a domain for which there is
> an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a
> broader definition than that in NXDOMAIN [RFC8020]." This should be
> sufficient for determining that the domain is not intended to be used and
> therefore could have a more stringent policy applied.
>
> The idea of looking for a "mail-enabled domain" based on if an "MX record
> exists or SPF policy exists" is interesting. Although there may be domains
> that send email but not receive email and so may not have an MX record.
> Also, even if there is no SPF record, the domain may still send email, but
> then it might be held to a more stringent DMARC policy that would further
> penalize it for not having an SPF record.
>
> Also, for the revision of the document I like the way that the three parts
> of the experiment are now laid out more clearly. My only comment is that
> the title of Appendix A is overly specific to just one of the experiments
> and so should be broader.
>
> Thanks,
>
> Eric Chudow
> To my thinking, the obvious rule should be to query for a NS record for
> the domain.  If the record exists, then the domain owner could create a
> DMARC record for that domain, or could create a default entry for the
> domain at the organizational level.  If no record exists, it is because the
> domain owner chose to not create one.
>
> However, the DMARC Bis document conflicts strongly with this.  In section
> A.4, it suggest several ways to do a test of this type, then repudiates all
> of them.  NS lookup is not one of the mentioned options.
>
> There is a possible second-level policy test for a "mail-enabled domain".
> I would define that test as "MX record exists or SPF policy exists".
>  That could be an additional option to NP, but should not be a replacement
> for it.
>
> PSD for DMARC clearly intends for the NP policy to be a general solution
> to a general problem.    If there are still objections to it becoming a
> general solution, this should be addressed soon.
>
> Doug Foster
>
>
> During the IESG reviews of draft-ietf-dmarc-psd, there were several issues
> raised with some of the document.   Most of them are editorial but the one
> big item was the description of the Experiment.   The chairs sat down and
> broke out the experiment section into three separate experiments, and
> included language on how to capture the data to confirm how the experiment
> worked.
>
> It's enough of a change that we wanted to do a second working group last
> call to make sure the working group agrees with our changes. The diff of
> the current version with the previous version is here:
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Nov 2020 22:03:06 -0800

> a name to find out if it is defined

Do you mean what does the DNS question look like?  Or what tool can you use
to make the query yourself?  Or something else?

-MSK

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Fri, 20 Nov 2020 11:29:29 +0000

Thank you, John. I agree that it's an edge case and not worth addressing separately. 

Eric Chudow

-----Original Message-----
From: John Levine <[email-masked]> 
Sent: Thursday, November 19, 2020 11:04 PM
To: [email-masked]
Cc: Chudow, Eric B CIV NSA DSAW (USA) <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

In article <[email-masked]> you write:
>Section 2.7. defines a non-existent domain as "a domain for which there 
>is an NXDOMAIN or NODATA response for A, AAAA, and MX records.  This is 
>a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied.
>

These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts.

We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels.

R's,
John

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 20 Nov 2020 06:57:20 -0500

I fear that I muddied the waters by asking about the RFC5321.MailFrom address.   Let's return to the main issue of the RFC5322.From address which DMARC protects.

This is not an edge case.   If spam filters were already blocking messages with RFC5322.From addresses with non-existent domains, we would not be having this discussion.

The RFC5322.From address can be very ethereal.   Consider the following situation:

The marketing department of Example.com hires a mass mailer to do a campaign from [email-masked].   
ChristmasSale.Example.Com does not currently exist.
The email service provider does its due diligence during account setup:

- The client has sent email communication from example.com and account paperwork for the same organization.   I have the client identified correctly,.
- The client has no DMARC policy on Christmas.Example.com, and an organization or PSD DMARC policy of SP=none, so I do not need to acquire a DKIM signing key.
- But the organization or PSD policy does specify NP, so I need the client to prove that ChristmasSale.Example.Com exists.

Requiring the client to create a bogus host record with a bogus IP address makes no sense, and is likely to be rejected by the client DNS administrator.

Requiring the client to create a name server record to prove domain existence does make sense, and should be easily approved and implemented by the client DNS administrator.

Ergo, defining the NP policy based on A, AAAA, and MX is not appropriate.

Doug Foster

From: eric.b.chudow.civ=[email-masked]
Sent: 11/20/20 6:30 AM
To: 'John Levine' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Eric Chudow

-----Original Message-----
From: John Levine <[email-masked]>
Sent: Thursday, November 19, 2020 11:04 PM
To: [email-masked]
Cc: Chudow, Eric B CIV NSA DSAW (USA) <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

R's,
John

---

From: "Doug Foster" <[email-masked]>
Date: Fri, 20 Nov 2020 08:57:18 -0500

To return briefly to the muddy waters that I created.  John is correct that
"mail enabled" is not useful for the RFC5322.From address, and my last note
expanded on reasons why that is correct.   

However, spoofing of non-existent subdomains is a potential problem for the
RFC5321.MailFrom domain, which then becomes an attack vector for the
RFC5322.From address as well.  The problem exists because because SPF has no
organizational default.   

We need to think about intermediate nodes, non-mail leaf nodes, and
non-existent subdomains.  Assume that a spammer tries to spoof a legitimate
organization by using a non-mail  or non-existing node for both the SMTP
MailFrom address and the message From Address.   The message will be
evaluated as 
- SPF=None, 
- DomainAligned=True, and 
- (if checked by some unknown algorithm)  OrganizationReputation=good.      

Can we assume that all such messages will be blocked by all recipients?   It
seems better to have a published policy to say that it should be blocked.
Based on existing specifications, the organization has these defenses:

- All possibilities are protected if the organization DMARC sp policy is
enforceable (p<>none and pct<>0).   However, we know that this is
problematic for many organizations.

- Mail-enabled nodes should have an SPF record, so those domains will be
protected.

- Existing but non-mail domains are only protected if they have an SPF -ALL
policy.   This may be difficult and error-prone for the organization to
maintain.

Conclusions:
Assuming that many organizations are still at sp=none, we have an attack
surface from non-existent domains.  The "must exist" policy provides the
only defense for non-existent nodes when the DMARC sp policy is
non-enforcing.

Assuming that many organizations will have trouble managing deployment of
SPF -ALL universally, we have an attack surface for non-mail subdomains.
The "must be mail enabled" policy provides a simpler defense mechanism than
deploying SPF -ALL to every non-mail node.

DF

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Chudow, Eric B CIV
NSA DSAW (USA)
Sent: Friday, November 20, 2020 6:29 AM
To: 'John Levine'; [email-masked]'
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
of NP

Thank you, John. I agree that it's an edge case and not worth addressing
separately. 

Eric Chudow

-----Original Message-----
From: John Levine <[email-masked]>
Sent: Thursday, November 19, 2020 11:04 PM
To: [email-masked]
Cc: Chudow, Eric B CIV NSA DSAW (USA) <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
of NP

In article
<[email-masked]> you
write:
>a broader definition than that in NXDOMAIN [RFC8020]." This should be
>The idea of looking for a "mail-enabled domain" based on if an "MX record
exists or SPF policy exists" is interesting.
>Although there may be domains that send email but not receive email and so
may not have an MX record.

These days I think you will find that if the domains in your bounce address
and your From: headers don't have an MX or A record, very few recipients
will accept your mail. This seems like an edge case. In practice I find that
the domains caught by the Org domain or I suppose PSD have A records but no
mail server because they're actually web hosts rather than mail hosts.

We have the Null MX to indicate that a domain receives no mail and SPF plain
-all to indicate that it sends no mail so I hope we don't try to reinvent
these particular wheels.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 20 Nov 2020 08:52:41 -0800

> - (if checked by some unknown algorithm)  OrganizationReputation=good.

Presuming no DKIM signature is involved, SPF=None is not the required
"PASS" that DMARC enforces so I don't see the point of your argument.

--Kurt

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 21 Nov 2020 12:02:03 -0500

Restating what we all know:
- The Internet is dependent on the reliable operation of the DNS name system.
- The DNS name system is dependent on the reliable operation of the name registration processes.
- The registrars are given ownership of all unregistered domain names within their portion of the hierarchy.
- The public evidence of registration is the existence of a DNS entry, and a NS record is always the first one configured. 

Conclusions
- Unregistered use of any domain name is an attack on the architecture of the Internet.
- PSD for DMARC is asking us to give public suffix operators what they are supposed to already have:   control over unregistered names.
- We should implement new and universal policies:- Unregistered names used as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.- Unregistered names used as message From header addresses MUST generate DMARC FAIL and SHOULD be rejected.

Protecting the integrity of the name registration system is not an optional activity to be implemented by a few organizations with the most sophisticated implementations of the DMARC specification.   It should be a mandatory duty of every legitimate participant on the network.

Starting from the assumption that unregistered domains might be allowable creates many problems when trying to design solutions for protecting the names that are registered.   This assumption needs to be rejected.

Addressing some straw-man questions:
Q:  The idea is fine for public suffixes, but my organization doesn't need to do that for subdomains under its control.
A:  Every level of the DNS tree needs coordination of name usage.    Publishing an NS record for an organization subdomain proves that the organization's process has been followed.   Besides, the boundary between public suffixes and organizational domains is imprecise, so recipients cannot be expected to apply differential expectations.

Q: My business partner and I exchange information using unregistered subdomains, and it is working fine.   Leave me alone.
A: Of course, senders can register with recipients, to obtain a filtering exception, as an alternative to registering in the public DNS.   But the default behavior should be to block messages.   Note that private use of unregistered subdomains may cause subsequent conflicts if the organization assigns the name to another purpose.

Q. How do we get all incoming filters to change to default block for unregistered domain names?
A.  I would suggest using the CVE/CCE process.

Q. What does this mean for the PSD for DMARC process?
A.  I think it becomes unnecessary.   Getting all participants to block all unregistered domains is a better goal, and can probably be achieved more easily.   It should involve relatively simple software changes, minimal DNS load, and minimal evaluation-time overhead.

Doug Foster

From: fosterd=[email-masked]
Sent: 11/20/20 8:58 AM
To: <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Conclusions:

DF

-----Original Message-----

Eric Chudow

-----Original Message-----
From: John Levine <[email-masked]>
Sent: Thursday, November 19, 2020 11:04 PM
To: [email-masked]
Cc: Chudow, Eric B CIV NSA DSAW (USA) <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
of NP

In article

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Nov 2020 11:11:49 -0800

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> - The public evidence of registration is the existence of a DNS entry, and
> a NS record is always the first one configured.
>
> Conclusions
> - PSD for DMARC is asking us to give public suffix operators what they are
> supposed to already have:   control over unregistered names.
> - We should implement new and universal policies:
>     - Unregistered names used as SMTP addresses MUST generate SPF FAIL and
> SHOULD be rejected.
>

That is certainly a defensible assertion, but I would claim it is out of
scope for DMARC.  You're talking about a detail of SPF or perhaps of SMTP
in general, although one could also even argue that this is a local policy
decision and outside the scope of those protocols.  I suspect the SMTP
greybeards would claim that this is not part of SMTP, but rather an
enforcement choice made by implementations.

I believe this falls within the realm of what the IETF calls an
Applicability Statement, which would be a standards track document (if you
could get consensus for it).  You could also include this in the DMARC
usage document, or as non-normative advice in DMARC itself with an
explanation of why it's a good idea, if you can develop consensus to do so.

You also need to account for transient DNS outages.  If your resolver
temporarily thinks "gmail.com" doesn't exist, you will bounce all mail
coming from that domain, and you might seriously piss off your users.
There's a backscatter problem here too: If I send mail to a list you're on
and you temporarily think my domain doesn't exist and you bounce mail
coming from me, the list will unsubscribe you.

    - Unregistered names used as message From header addresses MUST
> generate DMARC FAIL and SHOULD be rejected.
>

This is more in scope for DMARC discussions, though also arguably outside
of the protocol itself, for the same reasons.  I would suggest that it's a
viable discussion for the DMARC usage document, whenever we get around to
working on that again.  But you could certainly test the working group
opinion on this point.

Protecting the integrity of the name registration system is not an optional
> activity to be implemented by a few organizations with the most
> sophisticated implementations of the DMARC specification.   It should be a
> mandatory duty of every legitimate participant on the network.
>
> Starting from the assumption that unregistered domains might be allowable
> creates many problems when trying to design solutions for protecting the
> names that are registered.   This assumption needs to be rejected.
>

These are both probably true statements, but is DMARC the right place to
wage this battle?  For example, isn't it also true for TCP connections for
which PTR records make false claims (or no claim)?

Addressing some straw-man questions:
> Q:  The idea is fine for public suffixes, but my organization doesn't need
> to do that for subdomains under its control.
> A:  Every level of the DNS tree needs coordination of name usage.
>  Publishing an NS record for an organization subdomain proves that the
> organization's process has been followed.   Besides, the boundary between
> public suffixes and organizational domains is imprecise, so recipients
> cannot be expected to apply differential expectations.
>

I still don't understand what the presence or absence of NS tells you that
the presence or absence of MX/A/AAAA doesn't.  If you have a message that
fails the latter test but passes the former, does that change your handling
decision?  If not, why do it?

Q. How do we get all incoming filters to change to default block for
> unregistered domain names?

That seems like a big hammer, and certainly outside of the IETF's purview.
We're not the protocol police.  You might try having this discussion in a
context like M3AAWG though; many large operators congregate there to
discuss stuff like this.

-MSK

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 21 Nov 2020 18:12:22 -0500

What are the complications to DMARC of tolerating unregistered domains?

- If unregistered domains are tolerated, PSD for DMARC helps address the problem of a unauthorized domains underneath a public suffix, such as "example.uk".  But what DMARC policy will solve the problem of an invalid TLD, such as "example.q"?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes unusable.   A spammer would be able to  fabricate a few levels of non-existent subdomains, and suddenly PayPal.com becomes a domain tree with no detectable DMARC policy.   Besides, a scope-limited tree walk conflicts with the requirements of PSD for DMARC.   An unlimited-scope tree walk has performance risks to both the evaluator and the DNS infrastructure.

Doug Foster

From: "Murray S. Kucherawy" <[email-masked]>
Sent: 11/21/20 2:12 PM
To: Doug Foster <[email-masked]>
Cc: Doug Foster <fosterd=[email-masked]>, IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster <fosterd=[email-masked]> wrote:

Conclusions
- Unregistered use of any domain name is an attack on the architecture of the Internet.
- PSD for DMARC is asking us to give public suffix operators what they are supposed to already have:   control over unregistered names.
- We should implement new and universal policies:- Unregistered names used as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.

That is certainly a defensible assertion, but I would claim it is out of scope for DMARC.  You're talking about a detail of SPF or perhaps of SMTP in general, although one could also even argue that this is a local policy decision and outside the scope of those protocols.  I suspect the SMTP greybeards would claim that this is not part of SMTP, but rather an enforcement choice made by implementations.

I believe this falls within the realm of what the IETF calls an Applicability Statement, which would be a standards track document (if you could get consensus for it).  You could also include this in the DMARC usage document, or as non-normative advice in DMARC itself with an explanation of why it's a good idea, if you can develop consensus to do so.

You also need to account for transient DNS outages.  If your resolver temporarily thinks "gmail.com" doesn't exist, you will bounce all mail coming from that domain, and you might seriously piss off your users.  There's a backscatter problem here too: If I send mail to a list you're on and you temporarily think my domain doesn't exist and you bounce mail coming from me, the list will unsubscribe you.
- Unregistered names used as message From header addresses MUST generate DMARC FAIL and SHOULD be rejected.

This is more in scope for DMARC discussions, though also arguably outside of the protocol itself, for the same reasons.  I would suggest that it's a viable discussion for the DMARC usage document, whenever we get around to working on that again.  But you could certainly test the working group opinion on this point.

These are both probably true statements, but is DMARC the right place to wage this battle?  For example, isn't it also true for TCP connections for which PTR records make false claims (or no claim)?

I still don't understand what the presence or absence of NS tells you that the presence or absence of MX/A/AAAA doesn't.  If you have a message that fails the latter test but passes the former, does that change your handling decision?  If not, why do it?

That seems like a big hammer, and certainly outside of the IETF's purview.  We're not the protocol police.  You might try having this discussion in a context like M3AAWG though; many large operators congregate there to discuss stuff like this.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Nov 2020 17:02:47 -0800

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> - If unregistered domains are tolerated, PSD for DMARC helps address the
> problem of a unauthorized domains underneath a public suffix, such as "
> example.uk".  But what DMARC policy will solve the problem of an invalid
> TLD, such as "example.q"?
>

Why is this a DMARC problem that needs solving?

- If unregistered domains are tolerated, then a limited-scope tree walk
> becomes unusable.   A spammer would be able to  fabricate a few levels of
> non-existent subdomains, and suddenly PayPal.com becomes a domain tree with
> no detectable DMARC policy.
>

You're going to have to give us an example of what you're imagining here.
Presumably fabricating a few levels of non-existent subdomains of paypal.com
would look like foo.bar.baz.paypal.com; a simple tree walk then would be to
look for records in these places:

foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com

I would expect a policy to be present at least at "paypal.com", so the walk
stops there.  How is that "unusable"?

The PSL mechanism is a heuristic allowing a short-cut from the top one to
the bottom one, so there are only two lookups, based on the PSL which
provides a hint about where to jump after the first query.  But the PSL has
aspects of its management that are not desirable, and the tree walk is an
alternative.

Besides, a scope-limited tree walk conflicts with the requirements of PSD
> for DMARC.

Well sure; as I understand it, a tree walk would obviate the need for PSD.

An unlimited-scope tree walk has performance risks to both the evaluator
> and the DNS infrastructure.
>

So the theory goes.  I believe what John is saying is that he's asked the
DNS community, and they no longer think it's a concern, which means we
don't need to worry at least about the latter, and the former is probably
at least partially resolved by caching.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Nov 2020 17:04:56 -0800

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy <[email-masked]>
wrote:

> Presumably fabricating a few levels of non-existent subdomains of
> paypal.com would look like foo.bar.baz.paypal.com; a simple tree walk
> then would be to look for records in these places:
>
> foo.bar.baz.paypal.com
> bar.baz.paypal.com
> baz.paypal.com
> paypal.com
>
> I would expect a policy to be present at least at "paypal.com", so the
> walk stops there.  How is that "unusable"?
>

Someone in DNSOP, I think, proposed doing the tree walk in the other
direction.  The reason: If you're going to get an NXDOMAIN, it is more
likely to come earlier, and it's dispositive that way.  For instance, if
the above sequence is reversed, you would probably get an NXDOMAIN at the
second query ("baz.paypal.com") and then you know you don't need to look
any further.

-MSK

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 21 Nov 2020 20:32:06 -0500

I am arguing for the position that all unregistered domains are inherently invalid, because they are not registered.

PSD for DMARC proposes that non-existent domains should be blocked.    In their discussions, I remember the UK government reporting that they had registered 27,000 domains simply so they could publish SPF -ALL, in an attempt to block spammers from spoofing their government agencies.   I have a problem with the definition they chose in their document, but I fully agree that this is a problem that should be fixed.

They have also suggested that their "np" policy has general applicability, an argument which I find compelling.   By "general", I mean non-existent TLDs, non-existent public suffixes below the TLD, non-existent organizations, and non-existent subdomains of organizations.

Their experience demonstrates that an undefined domain is very difficult to protect.
....

On tree walk, I was working from John Levine's proposal, which assumes that a tree walk has to be distance limited for performance reasons.   He tentatively proposed four levels.   If you walk up the tree and find no DMARC entry, the walk stops with the conclusion that no policy has been issued.   This approach works if (and only if) the tree exists, so that the organization can place a policy at every fourth level.   The approach cannot work if the tree can be extended with non-existent domains.    It also conflicts with the PSD proposal which requires checking the top of the tree structure.

I had considered the top-down approach also, for the same reasons as you mentioned.   I assumed that it would be rejected because of the load placed on upper levels of the DNS hierarchy.

But when mulling the PSD problem with the tree-walk problem, I realized the unifying problem in all of these scenarios was unregistered domains.   Eventually the problem became further defined as, "Why should unregistered domains be considered acceptable by default, despite a network-wide requirement for all domains to be registered."

For the moment, it is a DMARC issue to me because DMARC has accepted the notion that unregistered domains are acceptable by default.   If that can be changed, I agree that there are other documents that need to be updated as well.

DF

From: "Murray S. Kucherawy" <[email-masked]>
Sent: 11/21/20 8:05 PM
To: Doug Foster <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy <[email-masked]> wrote:

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster <fosterd=[email-masked]> wrote:

- If unregistered domains are tolerated, then a limited-scope tree walk becomes unusable.   A spammer would be able to  fabricate a few levels of non-existent subdomains, and suddenly PayPal.com becomes a domain tree with no detectable DMARC policy.

You're going to have to give us an example of what you're imagining here.  Presumably fabricating a few levels of non-existent subdomains of paypal.com would look like foo.bar.baz.paypal.com; a simple tree walk then would be to look for records in these places:

foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com

I would expect a policy to be present at least at "paypal.com", so the walk stops there.  How is that "unusable"?

Someone in DNSOP, I think, proposed doing the tree walk in the other direction.  The reason: If you're going to get an NXDOMAIN, it is more likely to come earlier, and it's dispositive that way.  For instance, if the above sequence is reversed, you would probably get an NXDOMAIN at the second query ("baz.paypal.com") and then you know you don't need to look any further.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 21 Nov 2020 21:23:46 -0500

In article <[email-masked]> you write:
>direction.

Turns out that won't work because here's what you'd be checking:

> _dmarc.paypal.com
> _dmarc.baz.paypal.com
> _dmarc.bar.baz.paypal.com
> _dmarc.foo.bar.baz.paypal.com

You can have a NXDOMAIN at _dmarc.paypal.com but a TXT record at
_dmarc.bar.baz.paypal.com. You could certainly add heuristics and
check plain baz.paypal.com to see if it gives you an NXDOMAIN stop but
I have no reason to think that on average it'd actually save queries.

It is my impression that most real From: domains are pretty short. I
don't think I've ever seen one more than four labels long that wasn't
deliberately contrived. Anyone got data on that?

R's,
John
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Nov 2020 21:59:06 -0800

On Sat, Nov 21, 2020 at 5:32 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> On tree walk, I was working from John Levine's proposal, which assumes
> that a tree walk has to be distance limited for performance reasons.   He
> tentatively proposed four levels.   If you walk up the tree and find no
> DMARC entry, the walk stops with the conclusion that no policy has been
> issued.   This approach works if (and only if) the tree exists, so that the
> organization can place a policy at every fourth level.   The approach
> cannot work if the tree can be extended with non-existent domains.    It
> also conflicts with the PSD proposal which requires checking the top of the
> tree structure.
>

What does "extended with non-existent domains" mean in the context of a
tree walk?  You're going to have to give an example.

I had considered the top-down approach also, for the same reasons as you
> mentioned.   I assumed that it would be rejected because of the load placed
> on upper levels of the DNS hierarchy.
>

It strikes me that the infrastructure near the root of the tree is likely
very robust compared to that at many leaf nodes.

For the moment, it is a DMARC issue to me because DMARC has accepted the
> notion that unregistered domains are acceptable by default.   If that can
> be changed, I agree that there are other documents that need to be updated
> as well.
>

I think that assertion goes too far.  As I recall, DMARC doesn't claim that
unregistered domains are acceptable by default.  Rather, it cannot make an
assertion about a domain for which a policy cannot be found.  That's
certainly true of an unregistered domain.  DMARC follows DKIM and SPF in
this regard; they can only make assertions about a message when the parts
fall into place.  When they don't, none of those protocols can form a
conclusion.  That's different from deciding something is "acceptable".

In any case, it's unclear to me whether "bounce/discard anything from a
domain that appears not to exist" fits inside DMARC.  If you believe the
entire ecosystem should be doing this, not just DMARC-aware operators, then
I suggest these are the wrong documents in which to push for it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Nov 2020 22:06:56 -0800

> deliberately contrived. Anyone got data on that?

I'd bet there are some in .gov or .mil, especially the latter, but
otherwise I think the longest one I've seen is five, and that was not a
host that receives mail.

I'm sure we can all scrape our own mail logs for evidence either way.

-MSK

---

From: Laura Atkins <[email-masked]>
Date: Mon, 23 Nov 2020 13:19:05 +0000

> On 22 Nov 2020, at 06:06, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Sat, Nov 21, 2020 at 6:23 PM John Levine <[email-masked] <mailto:[email-masked]>> wrote:
> I'd bet there are some in .gov or .mil, especially the latter, but otherwise I think the longest one I've seen is five, and that was not a host that receives mail.
> 

This might be a place where one (or more) of the big ESPs can help. They’re going to have billions of email addresses and know which ones have MXs. I’m happy to ask for that data if it would be of use. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 23 Nov 2020 09:24:58 -0500

My longest addresses are from SalesForce.com, with 6 segments.
Relatively small dataset.

From: Laura Atkins <[email-masked]>
Sent: 11/23/20 8:19 AM
To: "Murray S. Kucherawy" <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

This might be a place where one (or more) of the big ESPs can help. They're going to have billions of email addresses and know which ones have MXs. I'm happy to ask for that data if it would be of use. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Mon, 23 Nov 2020 14:28:22 +0000

Even for .mil, the vast majority of email domains are fairly short with four or fewer labels. Most of the other ones tend to be individual servers that send automatic performance emails, and I think should be considered more of an edge case and less of our concern.

Thanks,

Eric Chudow

________________________________
From: Laura Atkins [[email-masked]]
Sent: Monday, November 23, 2020 8:19 AM
To: Murray S. Kucherawy
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

On 22 Nov 2020, at 06:06, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Nov 21, 2020 at 6:23 PM John Levine <[email-masked]<mailto:[email-masked]>> wrote:
It is my impression that most real From: domains are pretty short. I
don't think I've ever seen one more than four labels long that wasn't
deliberately contrived. Anyone got data on that?

laura

Laura Atkins
Word to the Wise
[email-masked]<mailto:[email-masked]>
(650) 437-0741

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 23 Nov 2020 11:40:48 -0600

> Even for .mil, the vast majority of email domains are fairly short with four or fewer labels. Most of the other ones tend to be individual servers that send automatic performance emails, and I thin…

This is the case for us as well (e.g. our comp sci high throughput compute cluster servers send automatic emails to both internal and external research collaborators).  I suppose universities are different than the military since the military probably doesn't want their servers to be sending email externally, whereby with a research university cross-institutional collaboration is inherent.

I suppose I consider it an edge case too (a large edge case - I see over 200 of these 4th level domains in or DMARC aggregate reports for the example cluster I cite), but the long tail of servers also aren't likely to change the way they are sending email nor will sysadmins implement SPF/DKIM for every server hostname, etc, so these subdomains are a blocker for publishing sp=reject at the org domain (hence a concern within the context of tree walking).

While I understand that there are implementation challenges that may make this infeasible, what I would *like* to do is ask each of these departments/research teams to publish sp=none at their 3rd level domains (and take over DMARC responsibilities for their parts of the tree) so that we can publish sp=reject at the org domain to protect/manage the rest of the university.

Jesse

P.S. Here are some stats.  Unique domains used in the RFC5322.From resulting from mail sent externally to DMARC reporting organizations in the past 2 weeks:
23 2nd level (org domains)
464 3rd level (359 are subdomains of wisc.edu)
522 4th level (all are subdomains of wisc.edu)
13 5th level
2 6th level

> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Laura Atkins [[email-masked]]
> *Sent:* Monday, November 23, 2020 8:19 AM
> *To:* Murray S. Kucherawy
> *Cc:* IETF DMARC WG
> *Subject:* Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd
> 
> 
> 
>> On 22 Nov 2020, at 06:06, Murray S. Kucherawy <[email-masked] <mailto:[email-masked]>> wrote:
>>
> [email-masked] <mailto:[email-masked]>
> (650) 437-0741
> 
> Email Delivery Blog: https://wordtothewise.com/blog <https://wordtothewise.com/blog>
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Doug Foster" <[email-masked]>
Date: Mon, 23 Nov 2020 13:43:02 -0500

I was misinterpretation the language to require detection whether any host existed in the zone, rather than checking whether there is a host name which matches the domain name.  Thank you to Murray for straightening me out.

That aside, we still have a problem.   The specification is applying SPF-type logic to an address that has no necessary connection to SPF.   A typical advertising message, sent be a third party, will pass SPF using the third-party sender’s domain.    The message From address becomes a label to identify the client organization in some manner, and possibly to identify the identity of the marketing campaign.  The domain name used for that purpose may not exist anywhere else, often does not accept replies, and may not exist as a mail server domain anywhere.    Consequently, these may very well be unregistered domains, but it may be reasonable to insist that domain owners get them registered to avoid false positives from the test.   The least disruptive test will be for NS.   Anything stricter will produce false positives.

The logic that seems to work is:

-          Check SPF and DKIM for domain alignment.   If the DMARC criteria are satisfied by either method, the message domain does not need to exist, because it has been validated.

-          If the message does not pass DMARC alignment, then we need to look for a DMARC policy to see if P/SP/NP applies.  If NP applies, and NS does not exist, the NP policy is applied.

Using the example domain from the document, I am assuming that we are trying to block all three of these non-existent domains:

-          T4x.gov.example

-          Spammer.t4x.gov.example

-          Spammer.tax.gov.example

If the goal is only to block t4x.gov.example, then the current NP algorithm is slightly less problematic.

Doug Foster

From: Tim Wicinski [mailto:[email-masked]] 
Sent: Thursday, November 19, 2020 11:04 PM
To: [email-masked]
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Doug

In looking for domain presence most folks will look at the domain itself.  There are a few web tools to enumerate

Some examples

hope this helps

tim

On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster <fosterd=[email-masked]> wrote:

DF

  _____  

*	Is there data to indicate whether evaluators have found that checking the RFC5321.MailFrom for non-existence is useful?   
*	Suppose that the NP policy becomes generalized, and a domain has asserted a "must-exist" DMARC policy.   Should a non-existent subdomain used in the RFC5321.MailFrom address be treated skeptically?

Doug Foster

 

  _____  

Thanks,

Eric Chudow

Doug Foster

To: IETF DMARC WG

 

All

 <https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09

Thanks,

---

From: "John Levine" <[email-masked]>
Date: 23 Nov 2020 16:05:43 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>Even for .mil, the vast majority of email domains are fairly short with four or fewer labels. Most of the other ones tend to be
>individual servers that send automatic performance emails, and I think should be considered more of an edge case and less of our concern.

I scraped my logs for the past few months and that's what I found.
Nearly everything was four labels or less. Spot checking the few
five-label names, I found that most of the mail was all from
MAILER-DAEMON@<long-mailhost-name> and it appeared to be spam
blowback.  There was a trickle of what looked like real mail
from stumail.zcs.k12.in.us and feedback.retail.voice-your-views.hsbc.com,

I found nothing at all with six labels or longer.

So if we made the tree walk limit six or seven I think we'd be
unlikely to lose any mail that anyone would miss.

R's,
John

---

From: "Brotman, Alex" <[email-masked]>
Date: Tue, 24 Nov 2020 12:52:43 +0000

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

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

> From: dmarc <[email-masked]> On Behalf Of John Levine
> Sent: Monday, November 23, 2020 4:06 PM
> To: [email-masked]
> Cc: [email-masked]
> <[email-masked]
> a.mil> you write:
> >-=-=-=-=-=-
> >
> >Even for .mil, the vast majority of email domains are fairly short with
> >four or fewer labels. Most of the other ones tend to be individual servers that
> send automatic performance emails, and I think should be considered more of
> an edge case and less of our concern.
>
> Nearly everything was four labels or less. Spot checking the few five-label
> names, I found that most of the mail was all from MAILER-DAEMON@<long-
> mailhost-name> and it appeared to be spam blowback.  There was a trickle of
> what looked like real mail from stumail.zcs.k12.in.us and feedback.retail.voice-
> your-views.hsbc.com,
>
> So if we made the tree walk limit six or seven I think we'd be unlikely to lose any
> mail that anyone would miss.
>
> R's,
> John
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!TIKw8O7ptxZvJLkZ0GxAxe4haD43V7NWTdLfVAZUiJUaCqFVIV1co
> wazKVYiV8c2YXTskHmvzw$

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 24 Nov 2020 17:50:55 +0100

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

If the message happened to authenticate, negative reputation is better added to 
that org domain rather than to .com or to some random mta-sts.mail.something.

IOW, if we need the OD anyway for alignment, there's no point in discovery 
DMARC records by tree walk.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 24 Nov 2020 12:06:21 -0500

In article <[email-masked]> you write:
>> I had one spam message that had 13 parts.  It included both "_mta-sts" and "mta-sts" in there, as well as
>"mail" nine times.  The last two parts were the org domain.
>

Why would you think that spam was sent by the actual holder of that
org domain? Since the address contained an underscore, it's invalid
anyway so you could probably reject the message without a lot of extra
checks.

>DMARC records by tree walk.

My plan is that whatever you discover by the tree walk replaces the OD.  In the likely
common case that the tree walk ends at _dmarc.<orgdomain> you get the same result either
way.

R's,
John