On October 31, 2021 11:29:41 AM UTC, Alessandro Vesely <[email protected]> wrote:
>On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote:
>> On October 30, 2021 8:47:51 PM UTC, John Levine <[email protected]> wrote:
>>> According to Scott Kitterman <[email protected]>:
>>>>>That usage has proven to work quite well. And some respect for the
>>>>>installed
>>>>>base wouldn't hurt.
>>>>
>>>> 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 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.
>>>> 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...
Completely separate issue, please don't.
>>>> I'm not sure how much more respectful we can manage to be.
>>>
>>> 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 protected], 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.
>
>
>Agreed.
Great.
>>> 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.
>> 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.
>
>
>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?
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.
>> 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.
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.
>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.
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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
