Mailman 3 March 2016 - Mailman-Developers

Re: [Mailman-Developers] Interest in "Implement module to process ARC headers" project GSoc
by nitish salwan March 27, 2016

March 27, 2016

Hello Stephen, I know that was late but I wanted to take part in GSOC. And now when the submission deadline is over,can I contribute in this project through GSOC or separate contribution? Thank you, Regards, Nitish Salwan

1 0

New lists at lists.mailman3.org
by Mark Sapiro March 27, 2016

March 27, 2016

I think I've made sufficient progress to ask others to look. There are two lists: test(a)mailman3.org and test2(a)mailman3.org. Info pages are at <https://lists.mailman3.org/mailman3/lists/>. Subscription to the "test2" list is confirm only. The "test" list is confirm and moderate. There are public HyperKitty archives, so be careful what you post. Note that the login page offers Persona, Google and Yahoo for login, but only Persona works Please feel free to subscribe and play. The intent is to set up a mailman-users(a)mailman3.org list as soon as we think the installation is viable, so we need to hammer it some and get some confidence. Also note that while I have dabbled off and on in the MM3 Core for literally years now, I know nothing about Postorius or HyperKitty or Mailman3 administration, so I may have made terrible mistakes. Let me know what you find. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 9

Re: [Mailman-Developers] Willing to contribute to GitLab/development tools integration project in GSoC
by Stephen J. Turnbull March 26, 2016

March 26, 2016

翁学平 writes: > But one thing is that I receive the response too late, so I have > not enough time to contribute to the mailman before the GSoC > applying deadline. So can I learn the project deeply and do some > extra contribution after the proposal submission deadline? You can contribute on the mailing list, but it would be unfair to other students to evaluate not your proposal, but other information you send us (and if Google caught us doing that, they would very likely boot us entirely from the program, if not this year, next). If I have some time I'll take a look at your proposal, but I already have all my time committed to other mentoring, so I will have very little influence on an eventual decision. Steve

1 0

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Mark Sapiro March 26, 2016

March 26, 2016

On 03/25/2016 06:06 AM, Aditya Divekar wrote: >> > My knowledge of anonymous mailing lists is a bit less. But from what I > understand, the address for the mailbox would not have a display name for > anonymity purposes whereas the user can have a display name, importing > which may cause anonymity concerns. The purpose of an anonymous list is to hide the identity of the author of a post. There is not a need on an anonymous list to hide the membership roster. There should be the normal controls on the visibility of the roster, i.e. list owners only, owners and members only or public (I'm not sure how this is handled in Postorius, I'm not up to speed there), but that is not the concern. The concern is that a post as archived and delivered to list members should have nothing in it's headers (including things like From:, Received:, Message-ID, etc.) that identify the poster or the poster's domain. This is a function of the core. Postorius is not involved nor are the archivers as the post has been anonymized before it gets to an archiver. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 3

Interest in "Implement module to process ARC headers" project GSoc
by Stephen J. Turnbull March 26, 2016

March 26, 2016

nitish salwan writes: > I am interested in ARC headers project and want to discuss about it. I'm sorry, but for the last 30 hours of submission period I've mostly either been asleep or busy with graduation ceremonies at my university, and haven't been able to address anything in GSoC except really urgent queries (I'm an org admin for Python, and the others are US based so nobody else is awake when I'm working). So you were just a little too late for me to help you with this. You're welcome to participate in ongoing discussions on Mailman Developers, of course. I hope you do!

1 0

Re: [Mailman-Developers] GSoC Project: pgp plugin
by Jonas March 26, 2016

March 26, 2016

Hi Abhilash Raj, Hi Steve Thank you both for taking the time and considering to mentor me. On 28.02.2016 04:48, Abhilash Raj wrote: > If you don't know, I worked on this project some time back in GSoC 2013. > The current state of that project is not very good and probably needs a > *lot* of rebasing to do. I did not know that. What were the problems? On 28.02.2016 04:48, Abhilash Raj wrote: > Here is a link[1] to discussions that have already been done before on this I think that link is missing, I'm very interested in looking into this. First of all, if this wasn't clear, my plan was to make a re-encryption gateway. Messages are encrypted to the listservers keypair and re-encrypted there for each of the recipients. How did your implementation work, Abhilash Raj? I had two modes of Operation in mind: (a) One that doesn't encrypt all of the mail but gives users the option to send and recieve pgp encrypted mails. This might be useful for very small private lists where some communication is protected against eavesdropping in other ways, when a list is in the progress of introducing encrypted communication or for (other) testing purposes. (b) A strict mode that keeps all the communication encrypted and won't ever send out mail without encrypting it. The strict (b) mode should certainly be default, and > 8. Optionally forced encryption (such a list never sends mail to an > adress to which it can't encrypt with a pubkey that has a certain > level of trust and/or won't accept inbound mail in plaintext) is in fact essential for the application to make sense. By Optionally, I meant that it should be possible to not force encryption which would be the (a) mode of operation. On 28.02.2016 04:48, Abhilash Raj wrote: > > I have a few small questions doubts about your features below... > > >> Some features could be: >> 1. Automatic pubkey collection from inbound mail >> > > What happens if I send a forged email with some user's email address as > FROM and use a fake key? Automatic public key collection isn't a very good > idea, you should be *very* careful about how you handle public keys. The idea was to collect the public keys so an authority (list admin) could manually set their trust levels which would be necessary in strict (b) mode in order to use a key at all. On 28.02.2016 04:48, Abhilash Raj wrote: >> 2. Outbound mail encryption and signature validation >> > > I would suggest you keep encryption as a part of extended goals in case of > GSoC. You'd be surprised how many students are not able to finish their > proposal in time. I will try to make a realistic evaluation of what's possible in my GSoC before i apply. On 28.02.2016 10:30, Stephen J. Turnbull wrote: > > 2. Outbound mail encryption and signature validation > > 4. Inbound mail decryption and outbound mail signature > > I don't understand these pairs. Why encrypt mail *to* the server if > it's only going to be decrypted on the way out? Why encrypt outgoing > posts if they might have been read in the clear before being received? On 28.02.2016 04:48, Abhilash Raj wrote: > Shouldn't both be working differently? Encrypted > emails distributed as encrypted email and signed email distributed as > signed. I paired them this way because outbound encryption and inbound signature validation requires the application to manage the subscribers public keys and inbound encryption requires the application to manage the lists keypair so I would probably implement 1. and 2. as well as 3. and 4. at the same time. 1-4 are part of the core functionality. My list is badly structured. On 28.02.2016 10:30, Stephen J. Turnbull wrote: > End-to-end encryption or signature or both seems to be the right > thing. The concept of a mailserver doesn't allow real end-to-end encryption if each recipient uses a different keypair. A user would have to have the public keys of all the subscribers at the time of sending a mail to the list and encrypt the mail for each of them. This would require modification to the client software for this to behave like a mailinglist, especially if subscribers join or leave the list. A method for real end-to-end mailinglists is described in Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 [1] but this is not what I want to do. Another alternative would be to have a pgp proxy outside the list server that does the re-encryption but this would not be as convenient as having a re-encrypting listserver. Considering that all subscribers recieve the mail and usually listserver admins are subscribers theirselves, I think than an implementation where the listserver recieves a copy as well definitly has some uses. Users would have to be aware that the privacy of communication relies on the protection of the listserver and listserver admins would have to be aware that they need to protect the lists keypair. On 28.02.2016 10:30, Stephen J. Turnbull wrote: > Out of scope for one summer IMHO. It's not obvious what the security > implications are. Better to do key generation off-line. What security implications are you refering to? Some servers have true hardware rngs. If there isn't enough entropy, no keys should generate with /dev/random as entropy source. Having the proper crypto libraries and random number sources is in the responsibility of the user. With this concept, there will be a private key on the listserver and this should be clear to the users. It has security implications but I think they are admissible. On 28.02.2016 10:30, Stephen J. Turnbull wrote: > > 5. A mailinterface for organizing the encrypted lists, subscribers > > public keys and trust levels > > 6. A webinterface > > These too are out of scope. Again, security implications are unclear. > > > 7. PGP Information in the messages (e.g. was the incoming mail signed > > by a trusted subscriber?) > > What does "trusted" mean? Trusted means that the key has been marked as trusted by an authority (list admin). The authority has to decide what actions have to be taken to mark a key as trusted. This could be exchanging fingerprints in real life or fingerprints could be confirmed by a trusted third party (eg a list member that already knows that public key). On 28.02.2016 04:48, Abhilash Raj wrote: >> 5. A mailinterface for organizing the encrypted lists, subscribers >> public keys and trust levels > > > I would like to know more on how you plan to do this. It could be one command to list all the pubkey fingerprints along with the corresponding subscriber email adress, the trust level and another command to set the trust level of a pubkey (by its fingerprint). This would require the list admin to securely identify, for example by pgp signing command mails. I did not yet research how to implement mail commands. On 28.02.2016 10:30, Stephen J. Turnbull wrote: > Yes, crypto support (both encryption and signatures) are a FAQ. > However, nobody has ever really provided specific requirements (ie, > the threat model to defend against), so it's very hard to decide what > to do, and documentation of whatever is done would be impossible. I'm not exactly sure what a threat model is. But a scenario this would protect from is eavesdropping on list communication by a mailserver – or anyone in case inter-mailserver communication or access to a mailbox isn't properly secured. A scenario where privacy could still be violated is when an eavesdropper gains access to the mailserver or any subscribers private key. I don't understand, why would documentation be impossible? [1]: http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf Jonas

3 8

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Stephen J. Turnbull March 26, 2016

March 26, 2016

Aditya Divekar writes: > The case we handled was regarding the welcome message. The display name > property of the address was not actually changed. So if the user has not > supplied a display name for the address, the display name will remain empty > in that case. Only the welcome message will temporarily use the user > display name. Would that still be a problem in this case? For the welcome message it's not going to cause a problem. Based on the explanation it would be reasonable for you to add, "so privacy problems are out of scope of the issue I'm working on."

1 0

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Aditya Divekar March 25, 2016

March 25, 2016

> A perhaps more convincing example would be an extension to anonymous >> lists with personal reply-to. This could be accomplished by creating >> a mailbox at the list host, which would be associated with the user so >> she can set options for it (eg, which address to forward to), but >> should not have a display name associated with it, and certainly not >> the user-level display name (which in organizational contexts -- >> including Python! -- is likely to be a real name). >> > My knowledge of anonymous mailing lists is a bit less. But from what I understand, the address for the mailbox would not have a display name for anonymity purposes whereas the user can have a display name, importing which may cause anonymity concerns. The case we handled was regarding the welcome message. The display name property of the address was not actually changed. So if the user has not supplied a display name for the address, the display name will remain empty in that case. Only the welcome message will temporarily use the user display name. Would that still be a problem in this case? I might be wrong here if my interpretation of the example is wrong! Aditya

1 0

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Stephen J. Turnbull March 25, 2016

March 25, 2016

BTW I made a few more comments on your proposal (after you finalized). I'm told you are allowed to revise the final copy until the deadline, it's just that we can't see it until then. I think it's basically in good shape. Aditya Divekar writes: > So according to what I've gathered from the conversation, the fall > back on the user name can be made implicit. If by "implicit" you mean "automatic, default", yes, but IMHO there should be a distinction between "None" and "InheritFromUser". That will make it easier to "fix" in the future if it turns out that there are more than a very few people who feel more strongly than me and Mark. A perhaps more convincing example would be an extension to anonymous lists with personal reply-to. This could be accomplished by creating a mailbox at the list host, which would be associated with the user so she can set options for it (eg, which address to forward to), but should not have a display name associated with it, and certainly not the user-level display name (which in organizational contexts -- including Python! -- is likely to be a real name). Also, in documentation please always write "the user's display name". "User name" has a strong connotation of "account identifier", and so could be quite confusing (especially since we don't have a user name separate from email addresses!) Steve

2 1

Mailman and Discourse Integration
by Ojas Shirekar March 25, 2016

March 25, 2016

Hello, I modified my proposal from the last time. It is slightly less ambitious now and includes more details about my plan to achieve this goal. Instead of a two-way interface between Mailman and Discourse and a one way Mailman to Discourse interface is certainly possible and beneficial to newbies who want to contribute but cannot follow the various conversations on a mailing list. It can also be helpful as a way to see the discussion time line and a means to archive old conversations. Not only that, I believe this is the first step towards a full integration between Mailman and Discourse Ojas Shirekar

1 0