Re: [dmarc-ietf] 5.5.4. Publish a DMARC Policy for the Author Domain - dmarcbis-06

[Douglas Foster <[e-mail]>]

Ale is correct on these points:

1. The exact-match test should be applied before any tree walk, not at the
end.

2. The design MUST distinguish between a public suffix operator and a
private registrar.   When the exact-match domain is a public registrar, the
result is FAIL-FromInvalid, triggering a hard reject.   When the
exact-match domain is a private registrar, we SHOULD have an indicator to
know whether or not the domain is used for mail, but with that omitted, we
have to assume that the private registrar domain sends mail and may be
either an organizational domain or a subdomain of an organization.


Additionally, the specification would be much improved if it first defined
the interfaces to the two functions, and then explained the
implementations.  The actual processing logic has significant differences
between the two functions.

While the current text treats the organizational domain search and default
policy search as different tasks, they are easily handled as a single
function.   When either lookup is needed, we invoke:

Status = FindOrgData(  RFC5322.From IN,  OrganizationalDomainFQDN OUT,
DefaultPolicyRecord OUT)
Where Status =  ( SUCCESS | PERMERROR )


When the Relaxed Alignment test is needed, the interface definition is:

Status = CheckRelaxedAlignment( CandidateDomainFQDN IN,
OrganizationalDomainFQDN IN, RFC5322.From IN )
Where Status = ( ALIGNED | UNALIGNED )


Notes on FindOrgData
The exact-match policy is checked first.
1. If a policy is found and specifies Strict Alignment for both SPF and
DKIM, the organizational data is not needed, so the function is not called.
2. If a policy is found and it is tagged as an organizational domain
policy, then the organizational data is already known, so the function is
not called.
3. If a policy is found, and is not tagged as a PSD policy, and the
RFC5322.From domain is only two segments, then the organizational data is
already known, so the function is not called.

Notes on CheckRelaxedAlignment:
1. The CheckRelaxedAlignment is called for each verified SPF or DKIM
domain, until ALIGNED status is returned or the list of candidates has been
exhausted.
2. If the policy specifies strict alignment for the candidate domain type
(SPF or DKIM), then the function is not called for that candidate domain.
A string match is used instead
3. The CheckRelaxedAlignment function could be implemented without using
the RFC5322.From address as a parameter, but this data element permits a
number of optimizations, including an embedded exact-match test.

We have two proposed implementations of these functions, one based on the
PSD and one based on Tree Walk.  However, as an evaluator, the Tree Walk
does not yet earn my trust.

Doug


On Mon, Apr 4, 2022 at 4:19 AM Alessandro Vesely <[e-mail]> wrote:

> On Sun 03/Apr/2022 18:07:29 +0200 John R Levine wrote:
> > On Sun, 3 Apr 2022, Alessandro Vesely wrote:
> >
> >>> (If the one beneath it has no DMARC record, is it still the org
> domain? I
> >>> think it is.)
> >>
> >> This seems to be inconsistent with the sentence that follows.  Would
> the
> >> landscape change if .com suddenly publishes psd=y?
> >
> > Currently with the PSL lookup, foo.com is an org domain whether or not
> it
> > publishes a DMARC record, and mail.foo.com and sales.foo.com are in
> relaxed
> > alignment.  While I think it would be reasonable to say that an org
> domain has
> > to publish a DMARC record if it's going to be used for relaxed
> alignment, that
> > would be a change from the current rule.
>
>
> The current definition, Section 3.2.7, replicates the original semantic:
>
> 3.2.7.  Organizational Domain
>
>     The Organizational Domain is typically a domain that was registered
>     with a domain name registrar.  More formally, it is any Public Suffix
>     Domain plus one label.  The Organizational Domain for the domain in
>     the RFC5322.From domain is determined by applying the algorithm found
>     in Section 4.8.
>
> The last sentence is particular in that Section 4.8 aims at determining
> the
> Organizational Domain for /any/ identifier, not just the From: domain.  We
> are
> assuming that an org domain can be determined for any domain, always.
>
> At the end of Section 4.8, in order to fulfill that assumption, in the
> absence
> of DMARC records, "the initial target domain" is promoted to the rank of
> Organizational Domain of itself.  That way, a PSD /is/ an org domain,
> which
> formally counters the second sentence in 3.2.7.
>
>
> > Since there is no chance that .com .net .org or other large TLDs will
> ever
> > publish a PSD record it makes little difference in practice, but if we
> agree
> > the org domain needs a DMARC record, we should make clear that this is a
> > deliberate change.  It's a good idea since if foo.com has no DMARC
> record and
> > .com has no PSD record, it won't work as an org domain anyway.
>
>
> To make the change clearer, I suggest to use different terms to indicate
> "working" org domains and registered domains with no DMARC record.
> Perhaps
> using the circumlocution DMARC Organizational Domain could suffice.
> However,
> along with the ubiquitous use of other longish terms (such as the above
> domain
> in the RFC5322.From domain), it makes for a rather wordy spec.  Better
> names?
>
>
> Best
> Ale
> --
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>