Re: [dmarc-ietf] What if... Sender:

Douglas E. Foster Wed, 24 Jun 2020 18:56:25 -0700

The core issue is that most of us want senders to prove their right to send on behalf of any asserted identities, of which From is the most important.

SPF did not solve the problem because validating an invisble field was insufficient for detecting unauthorized identity claims.

Turning DMARC into another SPF will emasculate it.

You deny anyone the right to care about validating From, and then argue that From is unimportant because no one cares about it. This is claimed even though you care very much about which From address appears on your DMARC mailing list messages, and are determined to weaken DMARC to get what you want.

The theoretical problem is that mailing lists cannot demonstrate their authority to send modified content on behalf of the originator domain. This right is explicitly granted or implicitly assumed during the subscription process, but no evidence of that transaction is available to the recipient system when a message is received.

To solve the problem correctly, we have to find a way to grant that authority. Right now, that authority is only granted at the sender domain level through DNS, or at the recipient domain level through filtering policies.

I do not know how to give indidiuals the right to delegate signing permission for themselves, because individuals do not have DNS control. A whole new trust channel would need to be created.

If delegation remains a domain-only authority, then the domain owners need to be involved. That leaves us very few possible scenarios:

- the originating domain owner publishes a rights delegation notice, the mailing list does something to claim that right, and the recipient domain does something to calidate that right. John Levine's dual sugnature proposal (which I still have not read) appears to be of this type. DKIM scopes are another example, but already available.

- the originatong domain owner does nothing, but the recipient domain owner does something in the email filter to treat the mailing list preferentially. This was my propsal. Of course, all domains act as both originator and recipuent.

- the mailing list stops making changes.

- the mailing list does header munging forever.

Are there any other options?

I do not like the last third or fourth options because neither evaluates the originator and forwarder jointly, but the objection is small.

The second option seems much easier to implement than the first, and has a stated transition process.

I think the first option will encounter significant political objections from domain owners, as well as significant technical issues. My proposal was a serious attempt to addtess your objection.

I will support any solution which demonstrates trust in a form acceptable to cooperating recipient systems.

I will resist solutions which assert that trust does not matter when the sender mivht be an MLM.