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. > > [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. holger
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9