[Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt

holger krekel holger at merlinux.eu
Thu Jan 25 06:21:27 EST 2018

Hi Barry, all,

thanks for your encouragement and feedback!  more inline ...
also would appreciate some quick feedback on the rough
technical design at the end. 

On Tue, Jan 23, 2018 at 11:51 -0500, Barry Warsaw wrote:
> > In the last year i co-instigated a new opportunistic mail encryption
> > effort called Autocrypt (https://autocrypt.org). With Autocrypt Level 1,
> > mail clients (e.g. enigmail, K-9 mail, Delta.chat, ...) send and parse
> > public keys in "Autocrypt" e-mail headers and offer single-click
> > encryption.  Releases are upcoming in spring 2018, we have been
> > doing fun and well-received user-testing sessions already
> > with in-development versions.
> Have there been any talks about creating plugins for commercial MUAs like Mail.app, Postbox, and Outlook?  Do you have plans for webmail clients like Gmail or Outlook?

We are working with Mailvelope and Roundcube developers, also have contacts
to several others. It's going to be a long game ... Getting 3-4 MUAs
to seemlessly work and have happy users will hopefully convince others
to join efforts. Autocrypt itself has no funding and does not employ
anyone at this point.

> > Also, i am considering to submit a project proposal for the
> > Mozilla Mission Partners program which would include a few more
> > things ... OnionMX routing for postfix, and documentation on
> > how to setup a best-practise MM3 mail instance, and maybe organizing
> > a sprint around the mentioned topics.
> Cool.  I think for best-practices in standing up an instance, you should definitely look at Abhilash’s docker images.  A sprint would be fun for sure.  Are you thinking Pycon US 2018 or elsewhere?

I am thinking of one in Freiburg (germany, black forest) where i live :)

> I’ll say this; there have been countless discussions on the mailing list about whether list traffic encryption really helps or not, how easy it would be to subvert, and other related topics.  I still think it’s an interesting and useful feature that will satisfy enough use cases to make it worth working on.  Then we have to ask whether this is of general utility to make it a built-in Mailman 3 feature.  That decision can certainly be deferred because you can probably get pretty far with the much better plugin support in Mailman 3.  I’m sure you could do a pretty good PoC as a plugin.

Indeed, i guess a plugin should get us >90% there.  Here are my
current technical considerations in a quick list: 

- Autocrypt L1 specifies how to generate an Autocrypt key, transfer and 
  parse public keys and settings through headers of regular e-mails.  

- Mailman is to create and maintain a per-list Autocrypt account 
  (managed through "muacrypt") which keeps track of 
  subscriber's encryption settings by parsing incoming mail messages. 
  muacrypt in turn uses "gpg" or "gpg2" and would maintain 
  keyring/account data on a per-list basis.  muacrypt also implements
  mime-encryption and decryption and needs to intercept incoming/outgoing
  mails.  Can a plugin modify outgoing messages on a per-recipient basis? 

- No special interface is needed on the mailing list web page
  maybe except from enabling/disabling the plugin/support. 

- With the current Autocrypt specification, a mailman list 
  will need to have the DMARC-mitigation "replace-from" action enabled
  to a) allow the list's public key to be added to outgoing mails 
  in an Autocrypt compliant way b) send properly signed and encrypted mails
  to those subscribers which are Autocrypt-capable and have a "mutual"
  prefer-encrypt settings (see Autocrypt spec for details "prefer-encrypt").
  If we get this to work nicely i think we can see about advancing the
  Autocrypt spec to support other ML modes (i.e. not replacing From).

- For a mixed set of subscribers (some with and some without Autocrypt
  support) mailman will send out encrypted and unencrypted mails
  respectively.  The status of the group might be added to a group's
  footer so that subscribers know about the group's security status
  (and get incentivized to upgrade their e-mail program).

Does that sound sensible? And achievable through a plugin, leaving the
core (largely) untouched? 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20180125/cced0db7/attachment.sig>

More information about the Mailman-Developers mailing list