Subject: Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

From: Alessandro Vesely <[email-masked]>
Date: Mon, 1 Nov 2021 20:17:16 +0100

On Sun 31/Oct/2021 16:01:03 +0100 John Levine wrote:
> It appears that Alessandro Vesely  <[email-masked]> said:
> >> 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?
> 
> I don't understand what you're proposing.  Are you saying to look for DMARC records at
> the d= domains in the signatures on a message?

Yes, it might be a valid hint in some cases.

>  What if it has no signatures but might be SPF aligned?

The existence of an SPF record is less indicative, as the protocol 
suggests to publish a record for each host.  Yet, in case the SPF 
identifier is a parent domain, it might be a valid hint too.

>> The concept of Organizational Domain is still useful for receivers, as it helps
>> setting up reputation databases.
> 
> Sure.  You get the org domain via the tree walk.

The tree walk doesn't distinguish among intermediate, organizational, 
and public suffix domains.

>> In this respect, the PSL is also useful outside the DMARC
>> protocol; for example, to get the organizational domain of HELO
>> arguments. >
> I don't immediately see the utility of the org domain of the HELO unless you're
> checking SPF on a bounce, but why wouldn't you do the same tree walk?

If you don't receive so many messages, keying under organizational 
domain helps reducing the size of the database, thereby increasing 
per-record data.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 1 Nov 2021 16:35:07 -0400

On Mon, 1 Nov 2021, Alessandro Vesely wrote:

>> >> Another criterion, beside tree-walk and PSL, could be to look at the d= tag of
>> I don't understand what you're proposing.  Are you saying to look for DMARC 
>> records at the d= domains in the signatures on a message?

> The existence of an SPF record is less indicative, as the protocol suggests 
> to publish a record for each host.  Yet, in case the SPF identifier is a 
> parent domain, it might be a valid hint too.

I still don't understand.  If a message has no DKIM signatures, and the 
sender uses SPF alignment, where do you look for _dmarc records?  A 
concrete example or two would be helpful.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Nov 2021 17:31:42 +0100

On Mon 01/Nov/2021 21:35:07 +0100 John R Levine wrote:
>>>> 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? >>>
>>> I don't understand what you're proposing.  Are you saying to look for 
>>> DMARC records at the d= domains in the signatures on a message? >>
> I still don't understand.  If a message has no DKIM signatures, and the sender 
> uses SPF alignment, where do you look for _dmarc records?  A concrete example 
> or two would be helpful.

Today I couldn't find the time to look for messages where the Return-Path: has 
a domain that is an ancestor of the From: domain.  (Albeit I see not so many 
messages, I'll try and fill Scott's request[*] when time permits.)

With DKIM it's more likely to find the org domain.  Mail sites that use 
subdomains, possibly in order to receive replies at different MXes, can still 
publish DKIM keys there.  In that case, a receiver can try d= rather then 
walking the tree.

For example:

From: Mr. User <[email-masked]>
Subject: Isn't this quite common?

It could happen with SPF too, but I think it's unlikely.

In any case, an aligned identifier would be just a hint.  If there's no DMARC 
record, the receiver has to walk the tree.

Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/_Hoj9JrsJrZzPnjnRbsX0zRgOJg