[Mailman-Developers] [GSoC] Encrypted mailing lists

2017-05-10 Thread Jan Jancar 
Hi Mailman Developers.

I am sending this mail as my proposal of encrypted mailing lists for
GNU Mailman got accepted and I will be working on it this summer.

Sorry about not contacting you earlier, I had some issues where
my site and mail server were down. If any of you tried to reach me
and failed in the last ~week you can try next time on my backup mail
jancar...@gmail.com which should always work.

You can find the original (accepted) version of my proposal on:
https://neuromancer.sk/static/mailman.pdf

# Status report so far into the Community bonding period:

 - As it was proposed on this list a plugin-like implementation of
encrypted mailing lists is really the only way to go forward here,
as just pushing in what might end up being a rather niche feature
into Mailman Core is not maintainable / wanted.
 - I started evaluating how much of my current proposal can be 
implemented without touching Mailman Core at all (as a plugin), 
what would require general changes and what might require specific
changes (that means it needs a better solution).
 - So far it seems most functionality of encrypted mailing lists
can be easily implemented out-of-tree with only minor general changes
to Mailman Core with the following exceptions that I'm currently solving:

* Making all commands require a confirmation (as subscribe / unsubscribe
has). This is necessary to stop replay attacks.

* Subscription command needs to contain users public key, either as an
argument or attachment or any other way the plugin might get it.

* List key fingerprint and per-address/user key fingerprints need
to be stored somehow, directly in the mailing list model would make 
the most sense, but that's very specific so the plugin should store
this itself. Although that means data duplication.

* Plugins don't seem to have a way to add features to the core REST
API, so exposing key administration for Postorious that way is out.

+ Some questions that I had in my original proposal:
+ Is exposing key management through the REST api and Postorius a 
good idea at all? Those have very different level of access control,
changing a key on a list requires a signed request + signed confirmation
token whereas doing it in Postorius might only require a password.
+ A way of sharing the lists public key that makes the user trust it
the most.

# What I would like to definitely finish in the Community bonding period:

 - Finish SMTPS/STARTTLS support for Mailman Core (really only needs 
tests now): https://gitlab.com/J08nY/mailman/tree/mta-smtps-starttls
 - Establish real-time communication channels with mentors (text/voice?)
and have a meeting to discuss the proposal.
 - Add proper objective milestones to the proposal.
 - Change the proposal to reflect movement towards a more plugin-like
implementation.


Cheers,
-- 
Jan
__
   /\  # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D
  /__\  # https://neuromancer.sk
 /\  /\  # Eastern Seaboard Phishing Authority
/__\/__\  # 






signature.asc
Description: OpenPGP digital 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

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

2017-05-10 Thread John Levine 
In article <20170510133609.61fba...@subdivisions.wooz.org> you write:
>I probably need more convincing that it would actually be used out in the
>field, ...

Gmail's already implemented it.  I'm pretty sure Yahoo is also planning to.

>  But OTOH, if it's of some utility it doesn't look
>like it would be difficult in core to support the extra header.  We'd need a
>small bit of REST and db schema/style setting work so that the list itself
>could be configured for one-click or not, depending on the web u/i being
>used.  (E.g. maybe one-click unsub is supported in Postorius, but other sites
>might not support it.)

Keep in mind that the list and user info have to be encoded in the
existing List-Unsubscribe header, and one-click just adds a fixed
List-Unsubscribe-Post header to tell the recipient that it can do a
POST for one click.  The encoded header makes regular unsub work
better too, since it knows what address to remove and needn't ask the
user.

R's,
John

>>It would certainly make it easier to deal with grumpy gmail users,
>>since gmail does not provide junk button feedback.
>
>Let's call that the Grumpy 800lb Gorilla principle. :)

Yes indeed.
___
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

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

2017-05-10 Thread Barry Warsaw 
On May 10, 2017, at 05:05 PM, John Levine wrote:

>>I'm not sure if anyone has followed development of RFC 8058 "Signaling
>>One-Click Functionality for List Email Headers" located at
>> and brought this topic up on this
>>list.
>>
>>Is that something mailman(2|3) should support? To me it looks useful.

I probably need more convincing that it would actually be used out in the
field, since there are a lot of email standards that have been ignored (by
some tools) for decades.  But OTOH, if it's of some utility it doesn't look
like it would be difficult in core to support the extra header.  We'd need a
small bit of REST and db schema/style setting work so that the list itself
could be configured for one-click or not, depending on the web u/i being
used.  (E.g. maybe one-click unsub is supported in Postorius, but other sites
might not support it.)

>It would certainly make it easier to deal with grumpy gmail users,
>since gmail does not provide junk button feedback.

Let's call that the Grumpy 800lb Gorilla principle. :)

>The disadvantage is that every recipient needs to get a separate copy
>of each message, because the list and user info has to be encoded in
>the list-unsubscribe URL.  That's been standard in commercial e-mail
>for a decade, but a lot of discussion list operators still imagine
>that it's too slow.

For a while now I've thought about changing the defaults to individual
personalization (i.e. everyone gets a unique copy, but we don't modify the
headers).  I think the constraints leading us to no personalization may not
be all that prevalent any more, and there's no question that personalization
improves the user experience.

-Barry
___
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

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

2017-05-10 Thread John Levine 
In article <20170510120723.xgg3apmj65cmv...@sys4.de> you write:
>Greetings,
>
>I'm not sure if anyone has followed development of RFC 8058 "Signaling
>One-Click Functionality for List Email Headers" located at
> and brought this topic up on this
>list.
>
>Is that something mailman(2|3) should support? To me it looks useful.

It would certainly make it easier to deal with grumpy gmail users,
since gmail does not provide junk button feedback.

The disadvantage is that every recipient needs to get a separate copy
of each message, because the list and user info has to be encoded in
the list-unsubscribe URL.  That's been standard in commercial e-mail
for a decade, but a lot of discussion list operators still imagine
that it's too slow.

R's,
John
___
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

[Mailman-Developers] Signaling One-Click Functionality for List Email Headers

2017-05-10 Thread Patrick Ben Koetter 
Greetings,

I'm not sure if anyone has followed development of RFC 8058 "Signaling
One-Click Functionality for List Email Headers" located at
 and brought this topic up on this
list.

Is that something mailman(2|3) should support? To me it looks useful.

p@rick


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 
___
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