I mean something different. By "user-to-domain" I mean a DNS function which asserts:
- When the message is signed by IETF, and the From address is my account, the message is considered authenticated by this DNS entry. - If the message is signed by IETF but the From address is a different account in the same domain, the message is not authenticated by this DNS entry. We have three uses cases: 1. The owner of an account on a mailbox provider such as Gmail, who wants to create an ESP account for mass mailings. Girl Scout troops were mentioned as a community that had this problem after the Yahoo lockdown. 2. The subscriber to a mailing list who wants to authorize the list owner to send messages using his From identity. We all have this problem. 3. And the newly introduced problem of the domain owner who is not willing to delegate a DKIM scope. They might be willing to authorize the ESP to send messages on behalf of [email protected], until they realize that it also authorizes the ESP to send on behalf of [email protected] . The ESP is willing to accept a DKIM scope, but the management sees the delegation as too risky. To solve these use cases, we need a DNS lookup that is based on the fully qualified From address and the DKIM domain. In concept, it seems like a straightforward extension of any of the third-party signing strategies. What I see as the primary difficulty is the need to publish a DNS entry which is specific to my email account, without announcing to every spammer in the world that my account is an available spam target. Hashing helps, but creates collisions. To avoid side-channel authorizations, we need a way to disaggregate collisions. ATSP does that by providing the domain name in cleartext, but that I don't see that as acceptable for a user account. Some critics may argue that hashing is not an adequate data-hiding technique anyway, It would be the solution to the great mailing list problem if we can make it work. But is that possible? Doug Foster On Fri, Apr 21, 2023 at 4:47 PM Hector Santos <[email protected]> wrote: > > > On Apr 21, 2023, at 2:14 PM, Douglas Foster < > [email protected]> wrote: > > > > Can it provide a user-to-domain authentication solution? > > Unless I am not following you, DKIM inherently provides "user-to-domain" > authentication by hash binding the 5322 From: and To: headers. > > > That is what mailing lists need and that is what mailbox provider > clients need. These use cases are pretty fundamental to our objective of > getting mail authenticated without causing damage > > A mailing list is a 1 to Many distribution. Legacy mail integrity lost > was a normal practice for a list system, i.e, footers. Well, technically > no. For DKIM, if you used the l= content length tag and did not change the > subject line, the original signature could survive. > > > GMAIL could easily provide a box for their users that authorized signers > and MTAs. Come inbound time, it can check for the authorize the MTA and > 3rd party signer. > > What I am missing, Google boys? <g> > > > — > HLS > > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
