Hi all,

I worked in GSoC 2013 (thanks to Steve and Barry!) to add support for verification and re-signing of emails in mailman3. I am working on the branch to rebase it with the recent changes in the trunk and make it ready to be merged. The reason for this post is to discuss about the current feature set and possible enhancements/changes to it (which probably was not included in my proposal due to time-limit of 3 months).

• A new signature rule checks for validity and age of the signature in all the emails and appropriate action is taken according to the configuration variable default_badsignature_action which can also be configured from postorius.

• For now, I have added this rule to the default pipeline which may or may not be desirable. I think if someone wants to accept unsigned emails as well, one can set default_badsignature_action to always accept. Thoughts on this?

• Each list has a public/private key pair that can be generated from Postorius, the public is displayed in ascii-armor on the list-summary page on the postorius from which it can be imported. I think would be easy to just publish the public key to a keyserver (not implemented yet).

• Users can import their public key from the keyservers (just paste your key-id and hit import) or by copy-pasting the ascii-armor'ed format in postorius.

• A signmessage handler signs the email using its own private key (yes even those which are already signed). The structure of the email was decided so that both the signatures can be verified with maximum *unix based mail-clients. I tested with notmuch, mu4e, claws-mail, thunderbird (was able to verify the outermost signature iirc, but not the inner one i.e. by the actual sender). The structure is of this form:

multipart/signed multipart/mixed multipart/signed text/plain application/pgp-signature text/plain application/pgp-signature

For other structures that I tested with refer this1 post.

• For now all the outgoing messages are signed by default. Is a setting required to make this optional?

Anything else that could be added or changed in this implementation?

-- thanks, Abhilash Raj