Re: [dmarc-ietf] Organizational Alignment Options

[Scott Kitterman <[e-mail]>]

Why.  

Walk one, jump to five, and then walk up adds complexity and matches no current behavior.

Complexity for complexities sake is a bad idea.  Has anyone posted to this list that they are having an actual problem that this would solve?

Also, it usually results in  clearer communication when you use the terminology that other people use instead of making up your own.  You're making distinctions that don't exist.  In example.com, example is the "host part" and it's hosts all the way down.

Scott K

On November 4, 2021 2:52:40 AM UTC, Douglas Foster <[e-mail]> wrote:
>This was more of an issue before your tree-walk took hold.  Now it is an
>edge case.   But I think it deserves explicit consideration.   I am sorry
>that it seems so obscure
>
>
>My terminology:
>
>An email domain-part that is a "DNS Domain" is associated resource records
>having an empty host portion, so that the domain-part name matches the name
>of the containing DNS directory structure.  Gmail.com is an example of an
>email domain-part that is also a DNS domain.
>
>An email domain-part that is a "host record" is associated with resource
>records that have a non-empty host portion, so that the name does not match
>the containing DNS directory structure.
>
>Either type of record can publish MX, A, SPF TXT, and DKIM TXT records, but
>only the empty host-portion names can have a corresponding entry in a
>"_dmarc." subdomain
>
>(I am open to improved vocabulary suggestions.   This is my best attempt.)
>
>
>Explaining the concern:
>With DMARCv1, email addresses which use "host record" domain-parts have
>only one possible policy match, the SP policy of the organizational
>policy.   It seemed to me that every valid domain-part should have two
>protection options, and the only way to achieve this would be to do a
>one-level tree walk to find the parent,.
>
>With normal DNS queries, we cannot determine whether the host portion of a
>resource record is empty or not, so there does not seem to be a way to
>specify conditional logic.  A one-level tree walk ensures that every name
>has at least one low-level policy option as well as an organizational
>policy option.
>
>
>How the constrained tree walk minimizes the problem:
>
>The proposed tree walk model says to initially look for a DMARC policy that
>exactly matches the email address domain-part.   If this fails and the
>address has many segments, jump to level five and move up until a policy is
>found or a termination signal is found (PSL list match or "I'm a PSL" in
>DNS or something else.)   This covers names with up to 6 segments.
>
>But what about names with more than 6 segments that are also "host record"
>names?   Such addresses are unusual, but they are not invalid, so they
>deserve a fair playing field, and I think that should include a granular
>DMARC policy.   Thus, my preference for a one-level tree walking before
>jumping across any levels.
>
>I hope this at least clarifies the concern.
>
>Doug Foster
>
>
>
>On Wed, Nov 3, 2021 at 1:23 PM John Levine <[e-mail]> wrote:
>
>> It appears that Douglas Foster  <[e-mail]>
>> said:
>> >-=-=-=-=-=-
>> >
>> >Correct, but you cannot query _dmarc.host1.domain because host1 is not a
>> >DNS domain, even though it can be a mail sender and receiver
>>
>> Sorry, but I also have no idea what you're talking about. Any mail
>> domain is a DNS domain because you have to use the DNS to publish an
>> MX or A or AAAA record.
>>
>> R's,
>> John
>>