I'm working on the solution to this (co-authors from Google and Yahoo, it's legit):

https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...

Note that it doesn't help avoid Google actually sending out a message with user-provided text in it, but it does stop it being replayed to you without Google intending it, because the SMTP FROM/TO are protected.

The motivation draft doesn't include technical detail, see early drafts of the technical detail in the various related docs at:

https://datatracker.ietf.org/wg/dkim/documents/

▲

brongondwana a day ago | parent | next [-]

Bah, the datatracker doesn't list the candidate documents. Here's some direct links:

https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/

https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header...

https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi...

https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce...

https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...

▲

btown a day ago | parent | prev [-]

How would this work with mailing lists/groups? A common pattern is to have emails from third parties to e.g. accounts-payable@example.com be auto-forwarded to members of the relevant team.

Would the end recipient team member's receiving system need to be set to "trust" the mailing list forwarder, or internally track what lists it is on to be able to understand that the original recipient accounts-payable is a valid recipient?

▲

brongondwana a day ago | parent [-]

Glad you asked! In a similar way to ARC (but better). The mailing list/group would add its own signature, and potentially a Delta-Body or Delta-Headers describing what changes it made (so that the verifier could undo the changes and verify the original signature, plus determine which changes were made by which hop).

So you'd have something like:

DKIM2: i=1; mf=sender@trusted.com; rt=accounts-payable@example.com; d=trusted.com

DKIM2: i=2; mf=bounce@example.com; rt=me@mydomain.com; d=example.com

So I could tell that the message came through example.com, and verify their signature on the message, as well as verify that trusted.com had intended the message to go to example.com in the previous hop.

▲

latchkey a day ago | parent [-]

This is amazing and I really appreciate you commenting here, but wow, my gut feeling is that this just feels like a yearly car registration sticker on top of the previous year and then a razor blade cut through it to prevent someone from stealing it.

At what point do we rip it all off and restart?

	▲	igor47 18 hours ago \| parent [-]
		... When the message is delivered? I think 0 or 1 message-rewriting proxies is typical, anything more is out of the ordinary.