Martin Schulte writes:

in the archives of the developer mailing list I read that there have been efforts to implement the Authenticated Received Chain (ARC) Protocol in Mailman.

Then that's where you should be asking about it. It hasn't been mentioned on this list because it's not ready for prime time, and may never be (see below).

That said, it's a GSoC project. The protocol implementation is complete, and Mailman integration is well along, but it has not yet been tested against other implementations for interoperability. This is for Mailman 3 only. Most of the code is quite independent of Mailman, so could probably be installed as a Handler in Mailman 2, but we have made no effort in that direction, and probably won't.

However, this implementation is really just a proof of concept. You not want to be implementing this protocol in Mailman if you can possibly avoid it. You want to be doing it in your MTA because Mailman can't validate SPF (it will always be receiving mail from localhost, not the remote boundary system).

Worse, it requires rather high privileges on the host system. You need access to the DNS to provide public keys to verify the signatures you add, and to the private keys to add those signatures. These are the same keys used for DKIM signatures, which means Mailman can be used to impersonate any user of that system. As far as I know, taking over Mailman to that extent is pretty much as difficult as taking over the MTA itself, but why double the attack surface?

Note that this is *different* from the argument against doing spam- checking in Mailman. Spam-checking is Mailman is inefficient and less friendly to the mail system compared to doing it in the MTA, but the risks involved are just those of doing a poor job of spam-checking (including backscatter, etc). This facility gives new powers to the successful attacker.