Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Jesse Thompson <[e-mail]>]

On Thu, Apr 6, 2023, at 11:43 AM, Murray S. Kucherawy wrote:
> 
> 
> On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson <[e-mail]> wrote:
>> __
>> I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't remember)
>> 
>> I'm struggling to understand how ATPS is significantly better than delegation via DKIM CNAME records. I can see that it's simpler for a domain owner because they need only set 1 ATPS record vs. sometimes 3 CNAME records (for key rotation). But that's not enough to justify adoption.
> 
> ATPS is Experimental.  I don't think it's a serious candidate for solving the DMARC problem.  There's also a "conditional signatures" draft floating around someplace.

I'm just spit balling experimental ideas, of course, under the assumption of my prior statement, which was something along the lines of: equipping domain owners with more fine-grained delegation capabilities would reduce the amount of p=reject breakage for perpetual mixed-use domains.


> To answer your question, ATPS was among other things a substitute for delegation via CNAME when the author domain doesn't want to give some other party the ability to generate its own signatures as the author domain.  There was never, at the time it was written, a demand for doing this at a user level.  Also, DKIM has never been tied to specific individual email addresses because there's no reliable way for an external entity to verify that the email address is even real, much less meaningful within the domain.  This was ultimately why use of "i=" in the DKIM signature never really took off.

If my understanding is correct, the "i=" in the signature can be arbitrarily set by the signer, which already has delegated authority of the entire domain, so what's the purpose of setting it? That [lack of purpose] seems like a more likely reason it never took off (if I had to make a wild guess)

I don't think that particular usage of "i=" is an apt comparison to a domain owner delegating [via some DNS record] signing authority for a single address. 

The DNS entry could reference any 'non-real' address, of course... until it is seen in the rfc5322.from and the receiver finds the DNS entry, at which point it becomes as real as the domain owner intended it to be used by the signer for that purpose.

Jesse