• 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