Hi Jan,
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.
sounds good!
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.
thanks a bunch for your feedback and links.
holger