[Mailman-Developers] Two more DMARC mitigations

[John Levine]

* Forwarding signature

The IETF DMARC list is discussing a mutant weak DKIM signature from a
sending system (e.g. Yahoo and AOL) that would survive forwarding, but
contains a list of forwarding target domains.  It's only considered
valid if it's with a signature from the forwarding domain, i.e., the
list.

This is nice for list operators, since it requires nothing beyond
not stripping the signature header, and signing on the way out.

* Submit and sign

When a user at a p=reject signs up for a list, you demand an OAUTH API
token if the the provider supports it, otherwise their host system
password.  You can check it on the spot and skip the challenge email
to confirm opt-in.

When the user sends mail to the list, the list makes whatever changes
it's going to make (subject tag, footers, whatever) and then uses the
API or SUBMIT to resend it through the host system.  When it arrives
back at the list, it has the host system's DKIM signature and the list
can resend it to the subscribers with the valid signature.

It also has to checks DMARC on incoming messages, and if the policy
has changed, holds onto the message and send a notice saying go back
to the web site and give us your credentials to stay on the list.

This is less nice, it's a lot of software development.  Collecting
credentials gives the mail operators heartburn, but as I told them at
a meeting today, if you want all mail to be authenticated, that's what
you asked for.

There is definite interest at large mail providers at least for the
first one.  Dunno if they're interested in the second, but since it
uses features they already have, it matters less.

R's,
John