On Thu 28/Jul/2022 20:19:36 +0200 Scott Kitterman wrote:
On July 28, 2022 3:26:45 PM UTC, Todd Herr
<[email protected]> wrote:
On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy <[email protected]>
wrote:
A couple of tweaks to suggest, edited in-place:
On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman <[email protected]>
wrote:
For Organizational Domain discovery, it will be necessary to perform one or
more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in
alignment. This means that each DNS Tree Walk to discover an Organizational
Domain will start at one of the following locations:
* The domain in the RFC5322.From header field of the message.
* The RFC5321.MailFrom domain if there is an SPF pass result for the
message.
* Any DKIM d= domain for which there is a DKIM pass result on the
message.
To determine the Organizational Domain for any of these domains, perform the
DNS Tree Walk as needed the selected domain. For each Tree Walk that
retrieved valid DMARC records, select the Organizational Domain from the
domains for which valid DMARC records were retrieved from the longest to the
shortest:
I just corrected a couple of typos, changed "header" to "header field",
and accounted for the fact that a message might have multiple signatures in
varying result combinations.
It's not clear to me from the thread whether or not the Note parts (see
below) should be kept, and if so where they should be located (end of
section 4.8?)
Note: There is no need to perform Tree Walk searches for Organizational
Domains under any of the following conditions: <#section-4.8-3>
- The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF
authenticated), and/or the DKIM d= domain (if present and authenticated),
are all the same and that domain has a DMARC record. In this case, this
common domain is treated as the Organizational Domain. <#section-4.8-4.1>
- No applicable DMARC policy is discovered for the RFC5322.From domain
during the tree walk for that domain. In this case, the DMARC mechanism
does not apply to the message in question. <#section-4.8-4.2>
- The record for the RFC5322.From domain indicates strict alignment. In
this case, a simple string compare between the RFC5322.From domain and the
RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain
(if present and authenticated) is all that is required.
My view is kept and moved to the end of the section.
I actually prefer it where it is, but in the interest of moving forward, I can
live with it at the end.
It is a question of taste. On the opposite, it is possible to specify the org
domain without referencing alignment, like so, say:
In general, it is not possible to determine DNS zone cuts by querying
various subdomains. However, DMARC users define DMARC records at their
Organizational Domain, so it is possible to discover them based on that.
Given a DNS Tree Walk (#dns-tree-walk) which retrieved at least one DMARC
record, determine the Organizational Domain by applying the following
rules, from the longest domain toward the shortest one:
1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n),
this is the Organizational Domain and the selection process is
complete.
2. If a valid DMARC record, other than the one for the domain where
the tree walk started, contains the psd= tag set to 'y' (psd=y),
the Organizational Domain is the domain one label below this one
in the DNS hierarchy, and the selection process is complete.
3. Otherwise select the record for the domain with the fewest number
of labels. This is the Organizational Domain and the selection
process is complete.
Clean, precise, foolproof, isn't it? After that we can discuss when it is
necessary to do discover the org domain, etcetera. One thing at a time.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
