[Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt
holger at merlinux.eu
Wed Jan 31 12:27:24 EST 2018
On Wed, Jan 31, 2018 at 15:28 +0100, Jan Jancar wrote:
> Hi all!
> On 01/25/2018 12:21 PM, holger krekel wrote:
> > 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?
> Yes a plugin can do that, although it has to go through some hoops as
> when I was making the delivery part of the plugin support I didn't want
> to change Mailman's delivery mechanisms too much, which means a plugin
> doing this will have some code duplication/boilerplate. As there are
> only 2 plugins currently([mailman-pgp] and [mailman-rest-events]), I
> think the plugin API could still evolve.
> If you would like to use a Python OpenPGP implementation you could look
> at [PGPy] and how I used it in mailman-pgp.
It's under consideration here: https://github.com/hpk42/muacrypt/issues/32
Are your experiences with pgpy indicating it's compatible with
enigmail and k9-mail? (see the questions on that issue)
> > - No special interface is needed on the mailing list web page
> > maybe except from enabling/disabling the plugin/support.
> Plugin configuration is done through the Mailman configuration and those
> are read-only through the REST interface. However a plugin might supply
> it's own REST endpoints for example for per-list setup/configuration.
I guess read-only REST would allow for a command line interface for
debugging or other low-level configuration wrt to autocrypt key
status for peers. Can a plugin add per-list configuration
options (enable/disable, maybe a choice between 2-3 policies?)
> > - 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?
> I definitely think so.
> [mailman-pgp]: https://gitlab.com/J08nY/mailman-pgp
> [mailman-rest-events]: https://gitlab.com/J08nY/mailman-rest-events
> [PGPy]: https://github.com/SecurityInnovation/PGPy
thanks a bunch for your feedback and links.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 474 bytes
Desc: not available
More information about the Mailman-Developers