Mailman-Developers May 2013

mailman-developers@python.org

18 participants
35 discussions

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Re: [Mailman-Developers] GSOC Project Discussion
by Barry Warsaw 18 Jun '13

18 Jun '13

On May 13, 2013, at 10:52 PM, varun sharma wrote: >1. Suspend emails in vacation and post from multiple email ids: >IMember interface present in interfaces/member.py is already providing the >delivery_status enum in _client module via rest api but the user.save() is >currently not functional, so the member preferences are not getting saved >right now. Similarly, IUser interface in interfaces/user.py is providing >the user.addresses attribute from IAddress interface to _client module but >due to the problem of user object not getting saved, this functionality is >also not working. For these two features, i don't think there is any >requirement from mailman core interfaces. I think to do vacations right, you will need some additional support in the core. One question to answer first is: what's the scope of a vacation stop? Does it apply to an address, user, member, or all of the above? For example: when I go on vacation, do I want all deliveries to stop to all mailing lists I'm subscribed to on a particular site, or just to some subscriptions? My thinking is that two use cases would be good to support: - Stop all deliveries from this site for a user. This would mean setting vacation stops for all of the user's subscriptions to all of their mailing lists on a domain (it probably should not be cross-domain). - Stop all deliveries for a specific subscription or list of subscriptions. For example, when I go on vacation, I might want to only receive mailman-developers traffic but nothing else from python.org. These two use cases imply to me that a vacation stop is tied to a subscription (i.e. an IMember) and a global stop is just a trivial case of a set of specific stops. A few other core-touching changes: - The expiration date for a vacation stop should be set when the stop is created. A user should not have to do anything to start getting their email again. When the expiration date passes, the traffic starts up again. - You should be able to set a vacation stop to start sometime in the future. E.g. I know I am going on vacation from next Tuesday to Friday, so let me set that up now while I'm thinking about it. Don't make me wait until Tuesday morning when I'm freaking out about catching my flight. :) - You should be able to query the system to see what vacation stops you have coming up, or are in progress. Maybe even view the history of your vacation stops (but that implies more record keeping, so maybe not). - You should be able to adjust the start and end dates of the vacation stop, if they haven't already passed. You could use this to extend a vacation, or change the start date to Monday if you have to leave early. A special case of this would also be to cancel a vacation stop right now. - Remember that vacations shouldn't be used as a way to more permanently disable delivery to a mailing list. All of this implies to me a new table/record which records future and non-expired vacation stops. The table would have a start and end datetime and a link to an IMember. Then likely the member_recipients.py handler would take these stops into account when calculating who to deliver this message to. Question: Should you be able to add a vacation stop to moderator or owner emails? >2. Merge identities : >Not exactly sure about additional core requirements, but i think it can be >achieved by expanding IAddress interface. Mostly this will be able sending out and coordinating the various confirmations messages that will be necessary. E.g. you're logged in as anne(a)example.com and you make a claim to merge aperson(a)example.com. You need to prove that you own the latter address too in some way. Once you've confirmed ownership of both addresses, you need to IUser.link() them both to the same IUser. This may involve unlinking and deleting an obsolete IUser record from an IAddress. Cheers, -Barry

4 11

true virtual hosting patch for 2.1 on RHEL6
by Graham Leggett 07 Jun '13

07 Jun '13

Hi all, Has anyone managed to get the mailman true virtual hosting patch for 2.1 working on Redhat Enterprise 6 as described at https://wiki.koumbit.net/VirtualMailman? I have to apply the patch manually as it the patch fails in a few places, however once applied the patch doesn't seem to work as it did on RHEL5. Mails are sent, but the list ends up being called list-example.com(a)example.com, which will break the list for end users. Unfortunately mailman3 is out of the question as it depends on python 2.7, which is too new for RHEL6. I can tolerate a custom mailman package, I can't support parallel custom versions of entire language stacks on the same box. Regards, Graham --

2 7

Re: [Mailman-Developers] GSOC Project Discussion
by Richard Wackerbarth 30 May '13

30 May '13

Varun, It is easy to say "He will receive an email about the tasks done in his absence". However, how do you propose to compose that email? Where and how is the information used to construct the email stored while the moderator is on vacation. If on a queue, which queue? ... etc. You seem to imply that each individual has a ToDo list of tasks. If that is the case, in the normal course of business, how will you handle the situation when there are two or more moderators and one of them processes a request. Richard On May 20, 2013, at 1:01 AM, varun sharma <varunsharmalive(a)gmail.com> wrote: > Hi Steve, > I think it will be a good idea to provide an option of digests, as the case you have mentioned may occur in a real situation. > > Hi Richard, > Lets take an example of a moderator of some mailing list: > > ==Before going on vacaton== > 1. If someone sends a "new user" request, the moderator will receive an email in real time about request. > 2. The task will be added to his and other moderators' ToDo list. > > ==During Vacation== > 1. If someone sends a "new user" request, the moderator "on vacation" will NOT receive any email about pending "add user" request. > 2. The task will be added to his and other moderators' ToDo list. > > ==After Vacation== > 1. He will receive all the emails as he was receiving before going on vacation. > 2. The pending tasks will show up in his ToDo queue > 3. He will receive an email about the tasks done in his absence > 4. He will receive email about pending tasks that were added to his ToDo list and are still pending.

3 2

Re: [Mailman-Developers] GSOC Project Discussion
by Barry Warsaw 30 May '13

30 May '13

On May 20, 2013, at 11:31 AM, varun sharma wrote: >So, I think the overlapping vacation may be handled in two ways: >1. Follow up the procedure as written above , i.e: If there are multiple >moderators going on vacation for same span of time, then the tasks will >remain pending in their ToDo list .During vacations, they can login to the >postorius and see their pending tasks, but there won't be any email >notifications about the pending tasks during the vacation period. But there >will be no mailing list delivery. That's okay. The requests will just pile up until some moderator comes back from vacation and chooses to process them. Really, this isn't much different from today's state of affairs :). >2. Second option as it came to my mind after you mentioned this case is >that, the last moderator(assuming all other moderators have already set >thier "on vacation" mode without digests) going on vacation will not be >allowed to completely opt-out of emails. As steve suggested, we can provide >a digest mode for notifications also. So the last moderator going on >vacation will have to choose "digest" mode for notifications as well as >mailing list mail delivery if he want to go on vacation :) I don't think we'd need to do that. It's worse if say all the moderators "unsubscribe" from their moderation roles. Then there really is no one to take care of things. But if everyone goes on vacation, the list should carry on just fine in their absence except that when their vacation stop expires, the daily notifications will start up again, and hopefully they'll take care of whatever is still pending. There's one caveat: pending requests can expire and be auto-discarded. We may want to rethink that in light of vacation stops for moderators. -Barry

1 0

Re: [Mailman-Developers] GSOC Project Discussion
by Barry Warsaw 30 May '13

30 May '13

On May 19, 2013, at 10:08 PM, varun sharma wrote: >2. The second thing is some moderators might be interested in knowing >the administrative changes done in their absence. So they should >receive a summary of the tasks done(eg. users added) in their absence >once they come back from vacation.This was what i was talking about in >that paragraph. This is why we would log those dispositions in the database (as well as other places probably). Then this information would be available through the REST API for Postorius to format nicely for a list's moderators. -Barry

1 0

Re: [Mailman-Developers] GSOC Project Discussion
by Barry Warsaw 30 May '13

30 May '13

On May 19, 2013, at 11:26 AM, varun sharma wrote: >I think the owner or moderators also should be allowed to use the in vacation >suspension of mails from the mailing lists they moderate or own, given all >the administrative tasks that need their attention must be added to their >ToDo queue. One thing to keep in mind is what MM2 does today. We really don't keep any kind of to-do list for a specific moderator. All we do is essentially keep a list of all the moderation actions that are pending on a mailing list, and we send this out to all the moderators every once in a while (e.g. once per day). (Note too that we can send out immediate notification about new pending requests. These don't replace the daily notifications.) In this view, if a moderator were to go on vacation, they would simply stop getting the daily reminders. Other moderators would still get them though. Once the moderator's vacation stop expires, whatever pending tasks are still outstanding will just get sent in the next daily notification. (As an aside, MM3 should do a better job of recording which of the moderators dispatches a particular pending task. We can't do that in MM2 because we don't really know - all the moderators essentially share a login. But in MM3, we can and will know, so we should record that fact in the log file, database, and original message.) -Barry

1 0

Concgrats and Welcome GSoC Students
by Florian Fuchs 30 May '13

30 May '13

Dear fellow Mailmaners, dear GSoC 2013 students, let's congratulate Abhilash Raj and Manish Gill for their successful Google Summer of Code 2013 applications! Abhilash's project will be the integration of OpenPGP into the mailman core. Manish will be working on a public facing, authenticated REST API. Also, thank's so much to the other students who applied for a GSoC slot this year! We really appreciate all the work you put into crafting your applications. We got a number of very good proposals, so the decision really wasn't easy. We'd be very happy to see you around contributing to the Mailman project, even if it's not as a GSoC student. So what's next for our students? Coding will officially start on June 17, so this week and the two weeks after that should be used to get to know the people you'll be working with (mentors, other Mailman coders working on parts that are relevant to your project, other students,...). The time before the coding start date should also be spent reading documentation and/or asking any still unanswered questions you might have about the existing code. It's also a good time to make yourself familiar with the tools and processes we use (version control, code reviewing etc.). Please note that we expect you to write weekly blog posts containing progress updates after June 17. So you might also want to set up a blog before that date (or - if you already have one - a separate GSoC category that can be aggregated via RSS). So, once more, congratulations -- and happy coding! Florian

1 0

Re: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]
by Daniel Kahn Gillmor 29 May '13

29 May '13

On 05/11/2013 03:17 AM, Abhilash Raj wrote: > After the Barry's comment on my proposal I decided to cut down the > proposal to implement use of OpenPGP signatures for posting > privileges instead of both signed and encrypted list. > Most of the infrastructure for encrypted list will be created along > with this project so that later on it can also be implemented easily. I think this is the right decision. Some of the discussion below is only relevant for the larger-scope project. but some of it is relevant to your revised-scope project as well. I've tried to indicate the latter concerns by flagging them with ***SIGNED_POSTS*** > Sender encrypts the message to list's pub key. List's pub-private > keypair is uploaded by the list's owner when he creates the list. > Subscribers gets to download the list's pub-key when he subscribes to > it. You're saying here that the list has a secret key (i'll call that LK_sec) and the corresponding public key is well-known (i'll call that LK_pub). in OpenPGP terms, keys have "usage flags" or "key capabilities": https://tools.ietf.org/html/rfc4880#section-5.2.3.21 It sounds like you're saying that we should mark this key as "encryption capable", which is usually indicated with two bits set: 0xc ***SIGNED_POSTS*** Might there be a reason for the list to have a keypair associated with it even for cleartext messages? e.g. might the list send out signed messages that users might want to verify? >> what if the decryption succeeds but there is no message signature inside it? > > In that case a notification is sent to the sender with only the > headers of the decrypted message that the signature of the message > does not match. If it is not sent by him he is asked to ignore the > notification. you say "with only the headers" -- is there ever a time when a bounce message might contain the message content? >> what if the signature appears to be valid, but was made 3 years ago (or >> in the future)? > > Is that a problem if he has not revoked his signature yet? ***SIGNED_POSTS*** Well, it could be a replay of an old message from 5 years ago from another list member. Should it be sent to the list again? >> what if the signature appears to be valid, and recent, but is the same >> signature that was used on a previous e-mail to the list? > > Can there be same signatures for different messages? I think the > digital signature is created by encrypting the message-hash, so if the > contents of the message are changed then signature cannot be valid. ***SIGNED_POSTS*** it could be a replay of a recent message, which would naturally use the same signature. But the headers could be modified. For example, the Message-ID isn't contained in the signature. >> what if the signature is cryptographically valid, but the list member's >> key has expired? > > Well a expired key cannot be used to sign messages. If this situation > happens this means it was signed in past some time ago. We can bounce > the message and notify the user about this. ***SIGNED_POSTS*** What if the message signature has a date that precedes the key expiry? >> what if only part of the message is signed? > My guess is that you are referring to inline-pgp. I read this article > which talks about the inline-pgp as a bad messaging format. I think we > should not support this. So if the message is partially signed it > should probably bounce back. ***SIGNED_POSTS*** Both inline PGP and PGP/MIME can have partial message signatures. I happen to agree that supporting inline PGP is problematic, so i'm willing to ignore it for now if that's the consensus of the project. be aware that you will find some pushback here, though, because there remain some broken MUAs that not only can't generate PGP/MIME, but can't display a clearsigned PGP/MIME e-mail to their users. When you think of PGP/MIME, you probably think of messages like message A below: A└┬╴multipart/signed 3099 bytes B ├─╴text/plain 1527 bytes C └─╴application/pgp-signature attachment [signature.asc] 1027 bytes But consider a MIME message D of the following form D└┬╴multipart/mixed 7346 bytes E ├┬╴multipart/signed 3099 bytes F │├─╴text/plain 1527 bytes G │└─╴application/pgp-signature attachment [signature.asc] 1027 bytes H └─╴text/plain inline 424 bytes the text in part F is signed by the signature in part G. So you could argue that the subtree rooted at E is "a signed message in some sense. What kind of messages look like D? where do they come from? (hint: examine the MIME structure of this message itself) >>> * The messaged is moved in between queues in the encrypted form >>> encrypted by a symmetric key algorithm which uses list's secret key to >>> encrypt the message. >> >> this doesn't make sense to me. when i hear "list's secret key" i tend >> to think people are talking about asymmetric encryption, but it seems >> here that you're talking about symmetric encryption. Maybe it would >> help to enumerate exactly what secrets each entity holds (and maybe what >> public data is associated with those secrets, in the case of the >> public/private keypairs used by asymmetric crypto). If you give those >> secrets names, you can refer to them more concisely and precisely. > > Sorry to sound so confusing. What I actually meant was that we use > public-private key encryption via OpenPGP so send and receive signed > and encrypted messages. Now each list has a public-private keypair > which the list owner uploads when he creates the list. I'm with you so far... > During processing of the message inside mailman it is decrypted and > sometimes stored on disk as python pickles in various queues which is > bad for security reasons. I propose that when it is being stored on > disk it can be encrypted using a symmetric key encryption algorithm so > that only one who has access to list's secret key can decrypt it. And here you've lst me again. the lists's secret key (LK_sec) is by definition for use in asymmetric cryptographic schemes. why are you saying "using a symmetric key encryption algorithm" here? > When the message is being sent to the subscribers it is encrypted with > the user's pub-key so that only he can decrypt it. This hand-waves around the difficult question: how do we know what the user's pub-key is? >> what happens to the original sender's signature? is it stripped? or >> does it remain, nested within the list's signature? How are list >> members expected to verify these signatures? > > The original sender's signature is stripped. I guess the list > subscribers just have to trust that the list owner. We cannot expect > each member of the list to have every other member's pub-key to > separately verify himself that the message is indeed from the sender. there are other options. for example, the list could *add* its signature to the message without stripping the signature of the original author, so that recipients could verify one or the other or both. ***SIGNED_POSTS*** This is also relevant in the reduced-scope project; is it possible that the mailing list might want to re-sign existing signed messages so that people who receive mails from the mailing list can verify that they really came from the mailing list? >> What happens if a user's public key is found to be expired or revoked? >> How does mailman become aware of revocations, of extensions of the >> expiration date, or of new keys or certificates for any given user? > > If the user has his key uploaded to a public key server and wants( he > will be given option of whether ot not to) mailman to check , mailman > can periodically check for revocation and expiration of the key. > Though i don't know how will that be done. ***SIGNED_POSTS*** Why would mailman *not* check the public keyservers? why should this be an option? If you're going to be using the OpenPGP public keyservers as a regular/possibly-heavy-duty client, i recommend asking any questions you have about the interaction with the keyservers over in the development list for SKS (which is currently the dominant keyserver implementation): SKS development list <sks-devel(a)nongnu.org> The protocol used is HKP, and there is a major global pool of gossiping keyservers that you can talk to. for more details about the pool, see: https://sks-keyservers.net/ > New keys will be added by user only from postorius after a > confirmation link is sent to him on the address the key verifies. ***SIGNED_POSTS*** Will that confirmation link be sent in the clear, or will it be encrypted to the user's public key? if the answer is "encrypted", what if the user's key is not encryption-capable? If the user is trying to change keys, will the confirmation message be encrypted to the user's old key or to their new one? Mailman has traditionally been accessible to people who do not browse the web by making use of its e-mail interface. will there be a way to add or adjust keys via e-mail as well? ----------- What about the monthly "you're subscribed to this list" e-mails mailman sends out? What about "reset your password" e-mails? Regards, --dkg

4 10

Python remote urllib.request -> mailman subscription
by Kip Warner 27 May '13

27 May '13

Hey list, I'd just like to preface my post with the acknowledgement that I had already posted the same query on Mailman-Users last week, but no one seemed to have an answer at the time. I figured it might be better to ask the developers. My Python 3 / PyGI / Gtk+ application, among other things, prompts a user for their name, email, and password, and then submits an http POST request to a hard coded remote GNU Mailman server. So far, the code appears to work and I'll request a peer review by anyone kind enough: <http://rod.gs/Cbq> One potential concern I've found is that it is difficult to machine parse the server response to reliably distinguish a successful subscription from a failure. A successful subscription returns an http code 200, but so do many failed ones (e.g. bad formatted email address is still code 200). The most reliable brute force method I could come up with was to check the message body of the returned HTML document for the substring "Your subscription request has been received". Great, except since Mailman is i18n capable, its gettext could return something semantically equivalent, but obviously worded different if the locale is changed. However, since the server I am submitting the request to will probably always use the English user interface, this probably won't be an issue, but is still inelegant and I'd like to solve it. Moreover, even if it remains in English, but perhaps the string changes anyways when Mailman is upgraded, then it is a problem again. Does anyone have any suggestions or other feedback they'd like to share or propose a better solution? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

2 2

2022

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 May 2013