On Thu, Apr 6, 2023, at 11:43 AM, Murray S. Kucherawy wrote:
>
>
> On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson <z...@fastmail.com> 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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
