Mailman-Developers February 2016

mailman-developers@python.org

28 participants
69 discussions

Re: [Mailman-Developers] GSoC Project: pgp plugin

by Jonas

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

5 years, 2 months

Re: [Mailman-Developers] Gitlab integration, GSOC'16

by Terri Oda

On 2016-02-28 1:34 PM, aahan bhatt wrote: > Please explain about the gitlab integration in layman terms. I would like > to contribute to the project. Gitlab integration can mean a lot of things, and we've left this particular project pretty open to see what people will suggest. The tweet linked talks about moving a discussion from a mailing list to a bug tracker. So imagine that you have a bunch of people discussing an issue on a mailing list and after a few posts someone says "hm, that configuration didn't work the way I expected, this sounds like a bug, maybe we should file it" -- we want a way to dump the whole discussion into a bug so when someone goes to fix it they have all the information. You'd need to think a bit about privacy (were the mailing list posts public? what about the bug tracker?) and relevance of information (what if I only want some of the posts? what if I want to link the discussion but only provide a summary?) to go from the idea of "make it easier to file bugs using information from a mailing list discussion" to an actual workable interface for doing that, but that's the core of it. If you want to understand the whole gitlab integration idea better beyond that one use case, try brainstorming a little bit about how the pieces could work together. How could a mailing list integrate better with a bug tracker? How could it integrate better with merge requests? What information would people want to pass from one system to the other and why? For an example you might want to take a look at idea #27 on this page: http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/

5 years, 3 months

Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .

by Abhilash Raj

On 02/10/2016 10:03 AM, Harshit Bansal wrote: > Hi Abhilash, > In our previous discussion you mentioned that : > >> Permissions should also consider if the user wants to make his new style >> public or keep it private. And should public styles be editable by >> anyone or just read-only? > > I am unable to think of a use case in which it will be useful to have > private styles.. Can you please suggest a suitable use case? Well, i agree there is nothing "private" in list styles. We could just make all styles read-only for everyone. But if someone wants to use the style created by other users, it would be better idea to first make them copy the style so that the behavior or their list doesn't change when the owner changes the style. Barry: If you have some time, I would like to hear some of your thoughts on this thread? I believe you have some ideas of your own on how this is supposed to work. > > Thanks, > Harshit Bansal. > -- thanks, Abhilash Raj

5 years, 3 months

Re: [Mailman-Developers] ARC module implementation [was: GSOC 2016]

by Stephen J. Turnbull

[Aside @Barry: what's the current state of DMARC handling in Mailman 3? (I assume below that there isn't any yet.) I guess porting some or all of the Mailman 2 facilities be a good GSoC project?] Please keep GSoC traffic on Mailman-Developers. Other developers have need-to-know, as do other students. Also, there's a good chance one of the other developers will get around to answering before I do, especially as I just got a pile of work dumped on me at work (one of our adjunct faculty got suddenly recalled to the Bank of Japan, leaving 8 units of courses unstaffed from April 1). I'll stay current with Mailman as much as a I can, but for the next few weeks that means responding to non-work mail in 48 hours. > The deliver method in deliver.py is responsible for sending the > messages, and the errors are caught here and then classified as > permanent or temporary. So currently, if I am not wrong, all the > rejections that Mailman faces due to the dmarc reject policy of > some domains, permanent error 550 I think, are caught here if there > are any. I don't think so. You'll not catch them in mta.deliver.py, which talks to your outgoing SMTP gateway, which normally does not do DMARC processing. On the other hand, the outgoing gateway doesn't make Mailman wait until it knows what its remote peer will do; it queues the message. So any rejections you see in mta.deliver.deliver() are a local matter. Permanent failures likely indicate a configuration problem, while temporary failures are probably due to maintenance on the MTA or network problems or the like. It's the final recipient MTA[1] that does DMARC processing, perhaps hours or days after deliver() has returned :-). At that point a (new!) bounce message is created and sent back through the mail system to Sender or Errors-To, which is <list>-bounces. So this is handled by the bounce runner, not the outgoing runner. > I was curious to know how this specific problem is being handled by > mailman right now. As in, how are the cases of subscribers of yahoo > using mailman currently being handled? First, subscribers using Yahoo! are not the problem. The DMARC problem is that when anybody from Yahoo! posts, *all* subscribers are at risk[2] of having their service bounce the post. If it was just Yahoo! subscribers, we wouldn't have to do anything except tell them that their mail service is deliberately sabotaged by Yahoo! It's the collateral damage to well-behaved third parties that makes DMARC abuse by AOL and Yahoo! so horrible. Second, in Mailman 3, currently nothing is done AFAIK. The first patch was submitted against Mailman 2 before release of Mailman 3.0. People using Mailman 3 at this point are unlikely to have large populations of p=reject posters. In Mailman 2, there are a number of options. The one I recommend is adding aol.com and yahoo.com to the subscription and poster ban lists.<0.7 wink/> This has the advantage (?) of also being usable in Mailman 3. A second is to configure the list without transforming the message at all (no Subject tags, header, or footer), thus preserving any valid DKIM signature. This also works in Mailman 3. These are standard configuration options which you might use anyway for completely different reasons. However, they sort undermine the argument for using Mailman in the first place for many sites. The third, more pleasant, alternative is to configure the list to transform the message by changing the *address* in RFC5322.From to the list, and putting some amount of user identity in the display name of the RFC5322.From (eg, "From Aditya Divekar (adityadivekar03(a)gmail.com) via Mailman-Users") of all messages. A fourth is to treat the message as a literal forward by including the message as a message/rfc822 part. These transformations are done by Mailman Handlers. Each has disadvantages. From-munging basically prevents the recipient from filtering on From. Few MUAs know how to handle a message "wrapped" in a MIME part pleasantly, and some (especially AppleMail on iPhone) choke badly. Finally, the most sophisticated alternative is to parse the address out of From, and do the DMARC DNS dance to determine if the sending domain has a p=reject or p=quarantine policy. If so, use either the From-munging strategy or the MIME-wrapping strategy. These still have the disadvantages described above, but they only apply to posts From domains abusing DMARC. I don't think any of these would be that hard to port to Mailman 3, it just hasn't been done yet. Footnotes: [1] This concept is a little ambiguous, in the case of things like .forward files that point to another mail server. [2] If their mail service participates in DMARC (there's no way of knowing that unless you're a user there), and if they don't do their own mitigation (eg, GMail treats many messages from p=reject domains as p=quarantine).

5 years, 3 months

Regexp filtering

by Stephen J. Turnbull

On Mailman-Users, Mark Sapiro writes: > Further, in the ban_list (and many other places in Mailman) if an > address is intended to be a regular expression pattern, it must begin > with '^', so you really want > > ^.*(a)domain\.com$ > > to match any_address(a)domain.com. I hope we haven't propagated this rather user-unfriendly interface (the convention of accepting both regexps and literals, distinguishing by "^" in column 0) to Mailman 3. Even as a Python programmer, I find Mark's post somewhat confusing: I would design filters using re.search, so that the above would actually be equivalent as a Python regular expression to r"@domain\.com$". OTOH, if the implementation uses re.match, the "^" is redundant, so I have a "say what?!" event. If we have, I propose changing it to Ban these addresses, one entry per line: [ ] [ ] Entries are regular expressions. or something like that. We also ought to have a "Python features for Mailman administrators" section of the FAQ, starting with "what is a regular expression", and giving examples of how to accomplish common tasks like banning a whole domain with regular expressions. Typical regexp FAQs are hard for non-programmers (and even beginning programmers) to grasp. I don't have time to actually work on these now, but if there's uptake on the suggestion ("let's think about it" at +0 or above :-) I'll file issues.

5 years, 3 months

Mailman 2.1.21 Final Release

by Mark Sapiro

Please ignore the spurious, fumble fingered post of a few minutes ago. I am pleased to announce the release of Mailman 2.1.21. Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended. This release includes a few new features and several bug fixes. Most of the changes since the second release candidate are i18n updates, but there are a few more bug fixes. See the attached README for details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see our web site at one of: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ http://mirror.list.org/ Mailman 2.1.21 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 3 months

Introduction

by Jasvir Singh

Hello everyone. I am Jasvir Singh Grewal, a graduate student from CSU Long Beach. I am feeling very excited to introduce myself on this mailing list. I have been working on open source technologies since 3 years. Last 2 years I have spent primarily working on Django and Python and it'll be a pleasure for me if I can use my skills for Mailman. Thank You -- Jasvir Singh Grewal https://github.com/jasvir99

5 years, 3 months

Mailman 3 custom footer

by treal tv

I saw an older message where someone was asking how to customize the footer for mailman 3. https://mail.python.org/pipermail/mailman-users/2015-October/079965.html It didn't seem to ever be answered, and I couldn't find any follow up in this list's archives. This is a problem I'm struggling with now - I also found the footer-generic.txt from the source where the exact footer I'm seeing is coming from. https://gitlab.com/mailman/mailman/blob/master/src/mailman/templates/en/foo… I'm looking to modify the contents of this footer so it says something slightly different. However, I can't find anywhere with Mailman 3 to change anything about the footer. Any help is greatly appreciated! Thank you!

5 years, 3 months

GSOC 16

by Manish Bisht

Hello devs, Google is announcing the list of selected organisation for GSOC 16 in few hours. Hope you all will like to join. Mentor are welcome as they are needed to guide the students and students are also welcome who would like to contribute. Think about the project idea and post it to mailing list for suggestions. Or choose the projects from the list. Hope we will got selected (fingers crossed) :)

5 years, 3 months

Fwd: [Python-Dev] [ANNOUNCE] fuzzpy

by Terri Oda

I know I was talking to someone a while ago about maybe doing some fuzz testing on Mailman. If anyone's interested, this might be a tool worth trying out: -------- Forwarded Message -------- Subject: [Python-Dev] [ANNOUNCE] fuzzpy Date: Sun, 28 Feb 2016 21:44:39 -0600 From: Brian Cain <brian.cain(a)gmail.com> To: python-dev(a)python.org ################################################################## Â Â *---------------------------------------------------* Â Â * Â Â fuzzpy: CPython fuzz tester is now available Â * Â Â * Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â * Â Â * Â Â Â Â Â Â Â Â Â Version 0.8 Â Â Â Â Â Â Â Â Â Â * Â Â * Â Â Â Â https://bitbucket.org/ebadf/fuzzpy/ Â Â Â Â * Â Â *---------------------------------------------------* I am pleased to announce the creation of a coverage-guided fuzz tester for CPython.Â It's a pretty small wrapper around LLVM's libFuzzer that enables some powerful testing logic.Â AFL (American Fuzzy Lop) is another popular fuzzer lately -- libFuzzer is very similar in concept to AFL.Â From what I've read on list archives, Victor Stinner had previously done some good fuzz testing on CPython using fusil.Â This project should expand on that concept. I'd love to get feedback, suggestions, patches and anything else the list can offer. Q: What is fuzzpy for? A: It's primarily for testing CPython itself, but could also be used for individual python projects too.Â Pure-python projects will be the simplest to integrate at this point.Â Also, interesting test cases output by fuzzpy may end up being useful in testing others such as pypy, pyston, etc. Q: What is a fuzz tester? A: It modifies inputs to a test case in order to find unique/rare failures. Q: What does "coverage-guided" mean? A: It means that libFuzzer is able to witness the specific code executed as a result of a given test case.Â It feeds this information back into an engine to modify the test cases to optimize for coverage. Q: How can I help? A1: donate cycles: build the project and crank away on one of the existing tests.Â Relative to other common fuzzing, it's awfully slow, so consider throwing as many cycles as you can afford to. A2: contribute tests: write a ~10-line python script that exercises a feature that you think could benefit from fuzz testing. A3: if there's interest, I can accept cryptocoin donations to purchase cycles on a cloud server. ################################################################## -- -Brian

5 years, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers February 2016