From twilleyj at oregonstate.edu Tue Aug 2 16:47:16 2016 From: twilleyj at oregonstate.edu (Twilley, Jack) Date: Tue, 2 Aug 2016 13:47:16 -0700 Subject: [Mailman-Developers] DMARC and Mailman 3 Message-ID: Hello! Several years ago, some folks were interested in adding DMARC to Mailman 3 according to a thread on this mailing list. The resulting discussion made for some interesting reading, but didn't result in a particular call to action. A little over a year ago, the DMARC wiki page was last updated, with a rough proposal for how DMARC would look in Mailman 3. Last September, Barry mentioned that the DMARC code in Mailman 2.1 had yet to be ported to Mailman 3, and that contributions were welcome. I checked the codebase and didn't see any DMARC code, so that hasn't happened yet. I have been sponsored by an organization to port the existing DMARC code from Mailman 2.1 to Mailman 3. While my primary responsibility is to satisfy the organization's requirements, it is very important to me that the resulting product be a viable candidate for upstream. I would appreciate any constructive guidance on how to best achieve my goals. Thank you! Jack. From turnbull.stephen.fw at u.tsukuba.ac.jp Thu Aug 4 23:07:01 2016 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Fri, 5 Aug 2016 12:07:01 +0900 Subject: [Mailman-Developers] DMARC and Mailman 3 In-Reply-To: References: Message-ID: <22436.725.861005.297408@turnbull.sk.tsukuba.ac.jp> Twilley, Jack writes: > I have been sponsored by an organization to port the existing DMARC > code from Mailman 2.1 to Mailman 3. While my primary > responsibility is to satisfy the organization's requirements, it is > very important to me that the resulting product be a viable > candidate for upstream. > > I would appreciate any constructive guidance on how to best achieve > my goals. I think the main issue will be any changes from Mailman 2's "Handler" API to Mailman 3's "Handler" (message-altering) and "Rule" (non-mutating) APIs, and how to communicate between them if both rules and handlers are used. Of course you're also welcome to do algorithmic and style cleanups (the original from_is_list implementation was submitted by a third party and we were in a hurry to do something so the style is suspect -- I admit haven't looked at it, but somebody[tm] should :-). From harshitbansal2015 at gmail.com Wed Aug 10 14:17:57 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Wed, 10 Aug 2016 23:47:57 +0530 Subject: [Mailman-Developers] Screenshots(Postorius) In-Reply-To: References: Message-ID: Hi developers, Here are some screenshots of how the new style system looks. Any comments/suggestions are most welcomed. Thanks, Harshit Bansal -------------- next part -------------- A non-text attachment was scrubbed... Name: Stylet New.png Type: image/png Size: 87911 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Stylet Index.png Type: image/png Size: 146277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Stylet View.png Type: image/png Size: 147400 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Stylet Edit.png Type: image/png Size: 117251 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Stylet Edit(Another Section).png Type: image/png Size: 136542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: New Style.png Type: image/png Size: 108329 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Style Index.png Type: image/png Size: 166940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: View Style.png Type: image/png Size: 200016 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: View Style(Complete).png Type: image/png Size: 202935 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Style Edit(Identity).png Type: image/png Size: 119108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Style Edit(Stylets Arrangement).png Type: image/png Size: 128160 bytes Desc: not available URL: From aurelien at bompard.org Tue Aug 16 05:52:39 2016 From: aurelien at bompard.org (Aurelien Bompard) Date: Tue, 16 Aug 2016 11:52:39 +0200 Subject: [Mailman-Developers] Django-allauth branch Message-ID: Hi folks! As you probably know, Mozilla Persona is going away very soon, and we had plans to migrate our web authentication to the django-allauth library so we could support local accounts properly. These last weeks I've been working on that and my work is almost complete. I've done some preliminary tests in situ and I'd like to add more unit tests, but I think the branch can be merged now so you guys can take it into account when you write merge requests. It's quite a big change: it introduces a new python package, django-mailman3, in order to share code between HyperKitty and Postorius. The Allauth library handles all the login and signup workflow, including the verification of emails, it handles the login using social account providers but it can also add those accounts to existing Django users, etc. It's pretty neat. I've also used its email verification system to replace Postorius' internal verification workflow. Django-allauth supports multiple email addresses per user with a verified flag, so I've setup some signal handlers to sync them with Mailman's users and addresses. It will make things much easier for us. A big part of the job was also to adapt the templates to our design. The creation of django_mailman3 was also the opportunity to share more code between HyperKitty and Postorius (there was already some duplicated code) and work on the integration. I'm pretty happy with the result. It's a pretty big change but we need to move away from Persona before it's taken down and obviously before 3.1, so I think it's neccessary, and better to have it sooner rather than later. If there's no strong opposition I'll merge the branches later today or tomorrow. Cheers! Aur?lien From aurelien at bompard.org Tue Aug 16 13:11:09 2016 From: aurelien at bompard.org (Aurelien Bompard) Date: Tue, 16 Aug 2016 19:11:09 +0200 Subject: [Mailman-Developers] Django-allauth branch In-Reply-To: References: Message-ID: Here are the branches, so you don't have to go hunt for them: - django-mailman3: https://gitlab.com/mailman/django-mailman3/tree/allauth - hyperkitty: https://gitlab.com/mailman/hyperkitty/tree/allauth - postorius: https://gitlab.com/abompard/postorius/tree/allauth A. From jwt at onjapan.net Wed Aug 17 05:25:49 2016 From: jwt at onjapan.net (Jim Tittsler) Date: Wed, 17 Aug 2016 18:25:49 +0900 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> Message-ID: I have moved the old wiki theme from Launchpad[1] to GitLab[2] (which turned out to be harder than it should have been[3] :-). The theme now copies much of the list.org theme, but I am not yet happy with some of the sizing and colors. The theme also is no more "responsive" than list.org on small screens. If there are no objections, I will install the new theme on wiki.list.org under a new name so that users can configure their preferences and provide feedback. (Or I can move my playground out somewhere publicly accessible.) Jim [1] https://code.launchpad.net/~jwt/+junk/wikilistorg [2] https://gitlab.com/jimt/wikilistorg [3] https://bugs.launchpad.net/bugs/1605956 -- Jim Tittsler http://OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/crew/jwt/ Mailman IRC irc://irc.freenode.net/#mailman From barry at list.org Wed Aug 17 09:58:22 2016 From: barry at list.org (Barry Warsaw) Date: Wed, 17 Aug 2016 09:58:22 -0400 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> Message-ID: <20160817095822.2703b5c6@subdivisions.wooz.org> On Aug 17, 2016, at 06:25 PM, Jim Tittsler wrote: >I have moved the old wiki theme from Launchpad[1] to GitLab[2] (which >turned out to be harder than it should have been[3] :-). Yeah, I've hit that one myself. ;) >The theme now copies much of the list.org theme, but I am not yet happy >with some of the sizing and colors. The theme also is no more >"responsive" than list.org on small screens. > >If there are no objections, I will install the new theme on >wiki.list.org under a new name so that users can configure their >preferences and provide feedback. (Or I can move my playground out >somewhere publicly accessible.) I really appreciate you working on this Jim. Is there a way to preview the new theme? When I go to wiki.list.org and look at my preferences, I'm using the 'mailman' theme. There are other choices, but it's not clear to me if any of those are your new theme. I'm assuming you don't need another machine or domain to demo the theme. If you do, I can easily set something up on the mailman3.org domain (which I own), but it's a little harder to add to the list.org domain (which JV owns). In any case, I trust you to JDFI when you feel the time is right! Cheers, -Barry From jwt at onjapan.net Thu Aug 18 00:22:41 2016 From: jwt at onjapan.net (Jim Tittsler) Date: Thu, 18 Aug 2016 13:22:41 +0900 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: <20160817095822.2703b5c6@subdivisions.wooz.org> References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> <20160817095822.2703b5c6@subdivisions.wooz.org> Message-ID: <9dd41553-4541-8f4f-7817-f2ed507152af@onjapan.net> On 08/17/2016 10:58 PM, Barry Warsaw wrote: > [...] Is there a way to preview the > new theme? When I go to wiki.list.org and look at my preferences, I'm using > the 'mailman' theme. There are other choices, but it's not clear to me if any > of those are your new theme. Sorry for the confusion. I've just put a copy of the WIP theme on https://wiki.list.org/ under the name "listorg" in the preferences. I think it already looks better than the current "mailman" theme, but does still need work. Feedback is welcome. Perhaps https://gitlab.com/jimt/wikilistorg/issues would be a good venue for discussion. Or ping jimt on IRC (Japanese hours). Jim -- Jim Tittsler http://OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/crew/jwt/ Mailman IRC irc://irc.freenode.net/#mailman From mark at msapiro.net Thu Aug 18 03:52:13 2016 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 18 Aug 2016 00:52:13 -0700 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: <20160817095822.2703b5c6@subdivisions.wooz.org> References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> <20160817095822.2703b5c6@subdivisions.wooz.org> Message-ID: <3041e515-b53a-7282-8da4-7158f212cd50@msapiro.net> On 08/17/2016 06:58 AM, Barry Warsaw wrote: > On Aug 17, 2016, at 06:25 PM, Jim Tittsler wrote: >> >> If there are no objections, I will install the new theme on >> wiki.list.org under a new name so that users can configure their >> preferences and provide feedback. (Or I can move my playground out >> somewhere publicly accessible.) > > I really appreciate you working on this Jim. Is there a way to preview the > new theme? When I go to wiki.list.org and look at my preferences, I'm using > the 'mailman' theme. There are other choices, but it's not clear to me if any > of those are your new theme. Yes, Thanks Jim. I see the new theme is called listorg. I have set that as my Preferred theme and will comment after I have some experience with it. Any wiki user can set listorg as her Preferred theme, and whenever we're ready we can make it the default theme for the wiki. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Thu Aug 18 09:41:27 2016 From: barry at list.org (Barry Warsaw) Date: Thu, 18 Aug 2016 09:41:27 -0400 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: <9dd41553-4541-8f4f-7817-f2ed507152af@onjapan.net> References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> <20160817095822.2703b5c6@subdivisions.wooz.org> <9dd41553-4541-8f4f-7817-f2ed507152af@onjapan.net> Message-ID: <20160818094127.04caa4d3.barry@wooz.org> On Aug 18, 2016, at 01:22 PM, Jim Tittsler wrote: >Sorry for the confusion. I've just put a copy of the WIP theme on >https://wiki.list.org/ under the name "listorg" in the preferences. > >I think it already looks better than the current "mailman" theme, but does >still need work. Feedback is welcome. Perhaps >https://gitlab.com/jimt/wikilistorg/issues would be a good venue for >discussion. Or ping jimt on IRC (Japanese hours). Agreed, it looks great at first glance! I've set it as my default theme too and I'll file bugs as needed. Cheers, -Barry From mark at msapiro.net Fri Aug 19 03:09:53 2016 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 19 Aug 2016 00:09:53 -0700 Subject: [Mailman-Developers] Imminent release of a Mailman security fix. Message-ID: <5aaec549-ad73-5192-8a7a-40eeaf2f4bbe@msapiro.net> There is a CSRF vulnerability associated with the user options page. This could conceivably allow an attacker to obtain a user's password. This is reported at . I have developed a fix which is a small patch to two modules. I plan to release Mailman 2.1.23 with this and other fixes on Saturday, Aug 27 and also to post at the same time the patch which can be applied stand-alone. Neither the bug report nor the fix reveals much detail about the attack, but to allay any concern, I'm delaying the release for a week to allow people to plan for installation of at least the patch at the time of release. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From sca at andreasschulze.de Mon Aug 22 05:31:43 2016 From: sca at andreasschulze.de (A. Schulze) Date: Mon, 22 Aug 2016 11:31:43 +0200 Subject: [Mailman-Developers] Imminent release of a Mailman security fix. In-Reply-To: <5aaec549-ad73-5192-8a7a-40eeaf2f4bbe@msapiro.net> Message-ID: <20160822113143.Horde.-2P6Qu7VDZtAg1z5cXpUl6r@andreasschulze.de> Mark Sapiro: > There is a CSRF vulnerability ... > I have developed a fix... > I'm delaying the release ... Hello, don't understand why you wait? Yes some people may need time to plan a update. But there are also people not needing such plan. They could use the patch just now. But maybe you have your reason to do it in that way. Anyway: thanks for mailman :-) Andreas From Richard at Damon-Family.org Mon Aug 22 06:44:17 2016 From: Richard at Damon-Family.org (Richard Damon) Date: Mon, 22 Aug 2016 06:44:17 -0400 Subject: [Mailman-Developers] Imminent release of a Mailman security fix. In-Reply-To: <20160822113143.Horde.-2P6Qu7VDZtAg1z5cXpUl6r@andreasschulze.de> References: <20160822113143.Horde.-2P6Qu7VDZtAg1z5cXpUl6r@andreasschulze.de> Message-ID: <2ccea80f-e7e3-18cb-4e59-78e20e85d9be@Damon-Family.org> On 8/22/16 5:31 AM, A. Schulze wrote: > > Mark Sapiro: > >> There is a CSRF vulnerability ... >> I have developed a fix... >> I'm delaying the release ... > > > > Hello, > > don't understand why you wait? Yes some people may need time to plan a > update. > But there are also people not needing such plan. They could use the > patch just now. > > But maybe you have your reason to do it in that way. > Anyway: thanks for mailman :-) > > Andreas > > The normal procedure for security updates in the software industry is an advanced announcement so people can plan, and then a release at a specified time point, so people can plan to update right then if possible. The issue is that the security flaw is normally not generally not know, and releasing the patch sometimes gives enough information to allow someone to figure out the security flaw and to exploit it in a short while, so you want people to be able to rapidly apply the update before that happens. -- Richard Damon From franck at peachymango.org Mon Aug 22 14:03:03 2016 From: franck at peachymango.org (Franck Martin) Date: Mon, 22 Aug 2016 13:03:03 -0500 (CDT) Subject: [Mailman-Developers] Remediation for fake member creation Message-ID: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> I'm not sure if you have seen the following blog posts: https://wordtothewise.com/2016/08/subscription-bombing-esps-spamhaus/ https://wordtothewise.com/2016/08/spamhaus-comments-on-subscription-attack/ https://wordtothewise.com/2016/08/ongoing-subscription-attack/ While mailman does double opt-in, one can still fill a mailbox with account confirmations, what are the methods to stop a bot submitting email addresses for registration across several lists? From barry at list.org Mon Aug 22 17:43:06 2016 From: barry at list.org (Barry Warsaw) Date: Mon, 22 Aug 2016 17:43:06 -0400 Subject: [Mailman-Developers] Remediation for fake member creation In-Reply-To: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> References: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> Message-ID: <20160822174306.48817f0e.barry@wooz.org> On Aug 22, 2016, at 01:03 PM, Franck Martin wrote: >While mailman does double opt-in, one can still fill a mailbox with account >confirmations, what are the methods to stop a bot submitting email addresses >for registration across several lists? Mailman 3 will not pend a registration request more than once for an email/mailing list combination. It's possible to spam every list at least once though, and I'm not sure what you could do about that. Cheers, -Barry From franck at peachymango.org Mon Aug 22 20:29:45 2016 From: franck at peachymango.org (Franck Martin) Date: Mon, 22 Aug 2016 19:29:45 -0500 (CDT) Subject: [Mailman-Developers] Remediation for fake member creation In-Reply-To: References: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> <20160822174306.48817f0e.barry@wooz.org> Message-ID: <874006216.16654315.1471912185191.JavaMail.zimbra@peachymango.org> ----- Original Message ----- > From: "Barry Warsaw" > To: "mailman-developers" > Sent: Monday, August 22, 2016 2:43:06 PM > Subject: Re: [Mailman-Developers] Remediation for fake member creation > On Aug 22, 2016, at 01:03 PM, Franck Martin wrote: > >>While mailman does double opt-in, one can still fill a mailbox with account >>confirmations, what are the methods to stop a bot submitting email addresses >>for registration across several lists? > > Mailman 3 will not pend a registration request more than once for an > email/mailing list combination. It's possible to spam every list at least > once though, and I'm not sure what you could do about that. May be a captcha? Or some more modern techniques... From turnbull.stephen.fw at u.tsukuba.ac.jp Tue Aug 23 00:06:31 2016 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Tue, 23 Aug 2016 13:06:31 +0900 Subject: [Mailman-Developers] Remediation for fake member creation In-Reply-To: <874006216.16654315.1471912185191.JavaMail.zimbra@peachymango.org> References: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> <20160822174306.48817f0e.barry@wooz.org> <874006216.16654315.1471912185191.JavaMail.zimbra@peachymango.org> Message-ID: <22459.52167.398850.559585@turnbull.sk.tsukuba.ac.jp> Franck Martin writes: > May be a captcha? Or some more modern techniques... Captchas aren't applicable to email requests. It will be harder than that. We could turn off subscription by email after user creation so that users would get only one email per email at most. From Mailman's point of view: <== subscribe email to list1 === create user for email ==> OTK to email, says "please visit URL, email operation admits abuse" <== subscribe email to list2 === recognize email, queue this request for user <== visitor arrives ==> You have (2) pending subscription requests: [x] confirm all subscriptions [x] subscribe email to list1 [x] subscribe email to list2 [submit confirmation and login to options] [just submit confirmation] The confirmation page would recommend adding other emails to the user for security and posting convenience. Of course a bot that knows all of a person's email addresses can do <== subscribe email1 to list1 <== subscribe email2 to list2 <== subscribe email3 to list3 resulting in three messages in the inbox, but that's probably orders of magnitude improvement over requesting subscription of one email to all the lists on a large server. For users who can't use/hate the web, I suppose you could allow email reply confirmation, in which case email operations would remain effective until the user explicitly turns them off. Finally, we could keep the users with no subscriptions in the database (at the person's option), preventing the felon from waiting until the subscription requests expire then bombing the person again. WDOT? Steve From franck at peachymango.org Wed Aug 24 02:33:24 2016 From: franck at peachymango.org (Franck Martin) Date: Wed, 24 Aug 2016 01:33:24 -0500 (CDT) Subject: [Mailman-Developers] Remediation for fake member creation In-Reply-To: References: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> <20160822174306.48817f0e.barry@wooz.org> <874006216.16654315.1471912185191.JavaMail.zimbra@peachymango.org> <22459.52167.398850.559585@turnbull.sk.tsukuba.ac.jp> Message-ID: <229411072.17751347.1472020404167.JavaMail.zimbra@peachymango.org> ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Franck Martin" > Cc: "Barry Warsaw" , "mailman-developers" > Sent: Monday, August 22, 2016 9:06:31 PM > Subject: Re: [Mailman-Developers] Remediation for fake member creation > Franck Martin writes: > > > May be a captcha? Or some more modern techniques... > > Captchas aren't applicable to email requests. It will be harder than > that. yes but protecting the web form from non-human subscription is a good step to take > > WDOT? Can't you send the email subscription request to moderation before the email confirmation is sent? Not ideal, but it is kind of like emergency moderation. From turnbull.stephen.fw at u.tsukuba.ac.jp Wed Aug 24 05:34:01 2016 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Wed, 24 Aug 2016 18:34:01 +0900 Subject: [Mailman-Developers] Remediation for fake member creation In-Reply-To: <229411072.17751347.1472020404167.JavaMail.zimbra@peachymango.org> References: <1919651091.16325181.1471888983399.JavaMail.zimbra@peachymango.org> <20160822174306.48817f0e.barry@wooz.org> <874006216.16654315.1471912185191.JavaMail.zimbra@peachymango.org> <22459.52167.398850.559585@turnbull.sk.tsukuba.ac.jp> <229411072.17751347.1472020404167.JavaMail.zimbra@peachymango.org> Message-ID: <22461.27145.426689.769032@turnbull.sk.tsukuba.ac.jp> Franck Martin writes: > Can't you send the email subscription request to moderation before > the email confirmation is sent? The option "subscription needs approval" is available, and I use it for my student lists, etc.?They're closed lists initially populated with "mass subscribe", but students often want to use cellphone or webmail addresses in addition to or in preference to their university addresses. In general, if the moderator knows the users well, there's often no point in confirmation. Eg, in my case I've almost always received personal mail from the address (it's preferred, or at least frequently used) in question if the student is on my list, so I know it's theirs. There is also an option "confirm and approve". I believe it means "confirm, *then* approve", and I think that's the right order. First, it prevents an attack on the moderator using faked addresses, and makes it a lot more expensive to attack the moderator with real addresses. I have seen such attacks on occasion for going on 25 years now; it's not a nightmare, it's a real problem. Second, moderators are a scarce resource. In many cases the moderator will need to follow up out of band (for example, I recently subscribed to a closed list, and the moderator texted me on Telegram to make sure it was me). In that case, either way the "victim" has to deal with an additional contact -- we can't save them the effort, we can only reduce load for the moderator by asking the user to confirm first. Then if the user drops it on the floor, the moderator has no work to do. Of course there would be cases where the moderator would refuse the request before confirmation, but I think that would depend on the moderator knowing that there were attacks via her list. On balance, I strongly favor protecting the moderator here. Finally, for open lists, which currently are configured confirm-only, I don't see how the moderators would have any idea whether it was a legitimate request or an attack, unless it was repeated to the same list -- and even then it would have to be a memorable address. Bottom line: I see no reason to default "needs approval" on for Mailman as we distribute it, unless we discover that "moderator knows subscribers" is by far the most common case. cPanel might think otherwise for their user base, I don't know. But not the typical open source project or discussion list, which I believe is by far the majority of non-cPanel (etc) Mailman lists. And the option is always available to turn on if you realize your list is being abused that way. Steve From mark at msapiro.net Fri Aug 26 14:11:38 2016 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 26 Aug 2016 11:11:38 -0700 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: <3041e515-b53a-7282-8da4-7158f212cd50@msapiro.net> References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> <20160817095822.2703b5c6@subdivisions.wooz.org> <3041e515-b53a-7282-8da4-7158f212cd50@msapiro.net> Message-ID: <79ab02cb-f61d-6068-4048-93093d9aa2a4@msapiro.net> On 08/18/2016 12:52 AM, Mark Sapiro wrote: > > I see the new theme is called listorg. I have set that as my Preferred > theme and will comment after I have some experience with it. I haven't really done any deliberate testing, but I've been using it for over a week with no issues that I have noticed. > Any wiki user can set listorg as her Preferred theme, and whenever we're > ready we can make it the default theme for the wiki. I have now set the wiki's default theme to listorg. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Fri Aug 26 17:31:48 2016 From: barry at list.org (Barry Warsaw) Date: Fri, 26 Aug 2016 17:31:48 -0400 Subject: [Mailman-Developers] wiki.list.org theme In-Reply-To: <79ab02cb-f61d-6068-4048-93093d9aa2a4@msapiro.net> References: <90756ccd-18cb-4171-0494-1bfbb416bc61@onjapan.net> <3ece1abf-25e8-db48-d957-2f1c513f03a6@msapiro.net> <20160817095822.2703b5c6@subdivisions.wooz.org> <3041e515-b53a-7282-8da4-7158f212cd50@msapiro.net> <79ab02cb-f61d-6068-4048-93093d9aa2a4@msapiro.net> Message-ID: <20160826173148.3d8f8aa1@subdivisions.wooz.org> On Aug 26, 2016, at 11:11 AM, Mark Sapiro wrote: >I haven't really done any deliberate testing, but I've been using it for >over a week with no issues that I have noticed. Me too, looks great. >I have now set the wiki's default theme to listorg. \o/ Thanks Jim, Mark. -Barry From mark at msapiro.net Sat Aug 27 09:47:35 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 27 Aug 2016 06:47:35 -0700 Subject: [Mailman-Developers] Mailman 2.1.23 release and fix for CVE-2016-6893 Message-ID: <53fe80e4-ec41-5c51-8f1b-587c6dafda3e@msapiro.net> I am pleased to announce the release of Mailman 2.1.23. Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended. This release contains a fix for CVE-2016-6893 which is also attached here as a patch. It also has new features, a few i18n updates and some 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.23 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README URL: -------------- next part -------------- Patch for CVE-2016-6893 This will apply with possible minor line number diffs to any Mailman >= 2.1.15 For Mailman < 2.1.15, the required Mailman/CSRFcheck.py module doesn't exist and other CSRF vulnerabilities exist in the admin UI, so upgrade is recommended. === modified file 'Mailman/Cgi/admindb.py' --- Mailman/Cgi/admindb.py 2016-07-14 21:27:49 +0000 +++ Mailman/Cgi/admindb.py 2016-08-23 23:12:05 +0000 @@ -39,6 +39,7 @@ from Mailman.Cgi import Auth from Mailman.htmlformat import * from Mailman.Logging.Syslog import syslog +from Mailman.CSRFcheck import csrf_check EMPTYSTRING = '' NL = '\n' @@ -58,6 +59,9 @@ else: ssort = SSENDER +AUTH_CONTEXTS = (mm_cfg.AuthListAdmin, mm_cfg.AuthSiteAdmin, + mm_cfg.AuthListModerator) + def helds_by_skey(mlist, ssort=SSENDER): @@ -135,6 +139,18 @@ print doc.Format() return + # CSRF check + safe_params = ['adminpw', 'admlogin', 'msgid', 'sender', 'details'] + params = cgidata.keys() + if set(params) - set(safe_params): + csrf_checked = csrf_check(mlist, cgidata.getvalue('csrf_token')) + else: + csrf_checked = True + # if password is present, void cookie to force password authentication. + if cgidata.getvalue('adminpw'): + os.environ['HTTP_COOKIE'] = '' + csrf_checked = True + if not mlist.WebAuthenticate((mm_cfg.AuthListAdmin, mm_cfg.AuthListModerator, mm_cfg.AuthSiteAdmin), @@ -212,7 +228,11 @@ elif not details: # This is a form submission doc.SetTitle(_('%(realname)s Administrative Database Results')) - process_form(mlist, doc, cgidata) + if csrf_checked: + process_form(mlist, doc, cgidata) + else: + doc.addError( + _('The form lifetime has expired. (request forgery check)')) # Now print the results and we're done. Short circuit for when there # are no pending requests, but be sure to save the results! admindburl = mlist.GetScriptURL('admindb', absolute=1) @@ -234,7 +254,7 @@ mlist.Save() return - form = Form(admindburl) + form = Form(admindburl, mlist=mlist, contexts=AUTH_CONTEXTS) # Add the instructions template if details == 'instructions': doc.AddItem(Header( === modified file 'Mailman/Cgi/edithtml.py' --- Mailman/Cgi/edithtml.py 2016-07-14 21:27:49 +0000 +++ Mailman/Cgi/edithtml.py 2016-08-23 23:12:05 +0000 @@ -30,9 +30,12 @@ from Mailman.Cgi import Auth from Mailman.Logging.Syslog import syslog from Mailman import i18n +from Mailman.CSRFcheck import csrf_check _ = i18n._ +AUTH_CONTEXTS = (mm_cfg.AuthListAdmin, mm_cfg.AuthSiteAdmin) + def main(): @@ -104,6 +107,18 @@ print doc.Format() return + # CSRF check + safe_params = ['VARHELP', 'adminpw', 'admlogin'] + params = cgidata.keys() + if set(params) - set(safe_params): + csrf_checked = csrf_check(mlist, cgidata.getvalue('csrf_token')) + else: + csrf_checked = True + # if password is present, void cookie to force password authentication. + if cgidata.getvalue('adminpw'): + os.environ['HTTP_COOKIE'] = '' + csrf_checked = True + # Editing the html for a list is limited to the list admin and site admin. if not mlist.WebAuthenticate((mm_cfg.AuthListAdmin, mm_cfg.AuthSiteAdmin), @@ -148,7 +163,11 @@ try: if cgidata.keys(): - ChangeHTML(mlist, cgidata, template_name, doc) + if csrf_checked: + ChangeHTML(mlist, cgidata, template_name, doc) + else: + doc.addError( + _('The form lifetime has expired. (request forgery check)')) FormatHTML(mlist, doc, template_name, template_info) finally: doc.AddItem(mlist.GetMailmanFooter()) @@ -167,7 +186,8 @@ doc.AddItem(FontSize("+1", link)) doc.AddItem('

') doc.AddItem('

') - form = Form(mlist.GetScriptURL('edithtml') + '/' + template_name) + form = Form(mlist.GetScriptURL('edithtml') + '/' + template_name, + mlist=mlist, contexts=AUTH_CONTEXTS) text = Utils.maketext(template_name, raw=1, mlist=mlist) # MAS: Don't websafe twice. TextArea does it. form.AddItem(TextArea('html_code', text, rows=40, cols=75)) === modified file 'Mailman/Cgi/options.py' --- Mailman/Cgi/options.py 2016-07-14 21:27:49 +0000 +++ Mailman/Cgi/options.py 2016-08-23 23:12:05 +0000 @@ -33,6 +33,7 @@ from Mailman import i18n from Mailman.htmlformat import * from Mailman.Logging.Syslog import syslog +from Mailman.CSRFcheck import csrf_check OR = '|' SLASH = '/' @@ -51,6 +52,8 @@ True = 1 False = 0 +AUTH_CONTEXTS = (mm_cfg.AuthListAdmin, mm_cfg.AuthSiteAdmin, + mm_cfg.AuthListModerator, mm_cfg.AuthUser) def main(): @@ -104,6 +107,19 @@ # The total contents of the user's response cgidata = cgi.FieldStorage(keep_blank_values=1) + # CSRF check + safe_params = ['displang-button', 'language', 'email', 'password', 'login', + 'login-unsub', 'login-remind', 'VARHELP', 'UserOptions'] + params = cgidata.keys() + if set(params) - set(safe_params): + csrf_checked = csrf_check(mlist, cgidata.getvalue('csrf_token')) + else: + csrf_checked = True + # if password is present, void cookie to force password authentication. + if cgidata.getvalue('password'): + os.environ['HTTP_COOKIE'] = '' + csrf_checked = True + # Set the language for the page. If we're coming from the listinfo cgi, # we might have a 'language' key in the cgi data. That was an explicit # preference to view the page in, so we should honor that here. If that's @@ -315,6 +331,15 @@ print doc.Format() return + # Before going further, get the result of CSRF check and do nothing + # if it has failed. + if csrf_checked == False: + doc.addError( + _('The form lifetime has expired. (request forgery check)')) + options_page(mlist, doc, user, cpuser, userlang) + print doc.Format() + return + if cgidata.has_key('logout'): print mlist.ZapCookie(mm_cfg.AuthUser, user) loginpage(mlist, doc, user, language) @@ -832,7 +857,8 @@ mlist.FormatButton('othersubs', _('List my other subscriptions'))) replacements[''] = ( - mlist.FormatFormStart('options', user)) + mlist.FormatFormStart('options', user, mlist=mlist, + contexts=AUTH_CONTEXTS, user=user)) replacements[''] = user replacements[''] = presentable_user replacements[''] = mlist.FormatButton( === modified file 'Mailman/HTMLFormatter.py' --- Mailman/HTMLFormatter.py 2015-02-13 18:41:28 +0000 +++ Mailman/HTMLFormatter.py 2016-08-23 23:04:58 +0000 @@ -28,6 +28,8 @@ from Mailman.i18n import _ +from Mailman.CSRFcheck import csrf_token + EMPTYSTRING = '' BR = '
' @@ -317,12 +319,17 @@ container.AddItem("") return container - def FormatFormStart(self, name, extra=''): + def FormatFormStart(self, name, extra='', + mlist=None, contexts=None, user=None): base_url = self.GetScriptURL(name) if extra: full_url = "%s/%s" % (base_url, extra) else: full_url = base_url + if mlist: + return ("""
+""" + % (full_url, csrf_token(mlist, contexts, user))) return ('' % full_url) def FormatArchiveAnchor(self): === modified file 'Mailman/htmlformat.py' --- Mailman/htmlformat.py 2016-07-15 02:10:24 +0000 +++ Mailman/htmlformat.py 2016-08-23 23:20:30 +0000 @@ -407,13 +407,14 @@ class Form(Container): def __init__(self, action='', method='POST', encoding=None, - mlist=None, contexts=None, *items): + mlist=None, contexts=None, user=None, *items): apply(Container.__init__, (self,) + items) self.action = action self.method = method self.encoding = encoding self.mlist = mlist self.contexts = contexts + self.user = user def set_action(self, action): self.action = action @@ -428,7 +429,7 @@ if self.mlist: output = output + \ '\n' \ - % csrf_token(self.mlist, self.contexts) + % csrf_token(self.mlist, self.contexts, self.user) output = output + Container.Format(self, indent+2) output = '%s\n%s
\n' % (output, spaces) return output -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From mark at msapiro.net Sat Aug 27 10:21:36 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 27 Aug 2016 07:21:36 -0700 Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.23 release and fix for CVE-2016-6893 In-Reply-To: References: <53fe80e4-ec41-5c51-8f1b-587c6dafda3e@msapiro.net> Message-ID: On 08/27/2016 07:03 AM, Jim Popovitch wrote: > I'm not seeing the CVE-2016-6893 fix in bazzar at > https://code.launchpad.net/~mailman-coders/mailman/2.1, shouldn't it > be there now too? It's there now. Thanks for the reminder. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From rmharvey at snet.net Mon Aug 29 12:00:45 2016 From: rmharvey at snet.net (Roy Harvey) Date: Mon, 29 Aug 2016 16:00:45 +0000 (UTC) Subject: [Mailman-Developers] Sequence of steps? References: <1567455177.1443669.1472486445171.ref@mail.yahoo.com> Message-ID: <1567455177.1443669.1472486445171@mail.yahoo.com> I manage a Mailman list.? I believe the situation I describe is not one that can be corrected by changing the configuration, but would require coding changes.? (I would love to be wrong!)? As such I don't expect anything to be changed, but perhaps it can end up on someone's list of requested features for eventual consideration. So here is the situation. 1) The list is text-only, so messages with fancy formatting are converted to simple text.? Attachments such as photos are discarded. 2) The maximum message size is set to 10KB.* 3) Messages with elaborate formatting, but little text are often larger than 10KB, so they are held for review.? That means the test for size comes BEFORE the message is "cleaned up" and reduced to simple text. My suggestion is to change the sequence of steps, so that the size filter is applied AFTER the message has been converted to plain text. I hope that is clear enough. Yes, I understand changing the order of things is No Small Thing.? I figure it can't hurt to put it out there. Thanks for listening! Roy Harvey Beacon Falls, CT * (Because subscribers replying to Digest messages regularly fail to remove the text of the Digest message they are replying to, the maximum message size is set to 10KB.? This also blocks messages with attached photos, which will be removed anyway because the list is text-only.? I review messages held because of size.? The ones with a full Digest are rejected with an explanation about removing the Digest being replied to.? The ones with photos attached are rejected with an explanation about putting them on the web and posting a link.? The ones that are blocked because they are long messages, or short messages with too much formatting, are approved.) From mark at msapiro.net Mon Aug 29 20:46:03 2016 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 29 Aug 2016 17:46:03 -0700 Subject: [Mailman-Developers] Sequence of steps? In-Reply-To: <1567455177.1443669.1472486445171@mail.yahoo.com> References: <1567455177.1443669.1472486445171.ref@mail.yahoo.com> <1567455177.1443669.1472486445171@mail.yahoo.com> Message-ID: On 08/29/2016 09:00 AM, Roy Harvey wrote: > 3) Messages with elaborate formatting, but little text are often larger than 10KB, so they are held for review. That means the test for size comes BEFORE the message is "cleaned up" and reduced to simple text. > My suggestion is to change the sequence of steps, so that the size filter is applied AFTER the message has been converted to plain text. Yes, I agree that this is a problem, but it is easily configurable. Here's what I've had in mm_cfg.py to do this on my production site for a long time # # Put MimeDel ahead of Hold so "too big" is based on content filtered # message. # GLOBAL_PIPELINE.remove('MimeDel') GLOBAL_PIPELINE.insert(GLOBAL_PIPELINE.index('Hold'), 'MimeDel') # -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From rmharvey at snet.net Mon Aug 29 20:58:27 2016 From: rmharvey at snet.net (Roy Harvey) Date: Tue, 30 Aug 2016 00:58:27 +0000 (UTC) Subject: [Mailman-Developers] Sequence of steps? In-Reply-To: References: <1567455177.1443669.1472486445171.ref@mail.yahoo.com> <1567455177.1443669.1472486445171@mail.yahoo.com> Message-ID: <443359534.1705926.1472518707358@mail.yahoo.com> Mark, Thanks for your quick response.? It sounds like you have this one under control. I am far removed from anything like mm_cfg.py as I use a hosting service.? I will have to see what they think about making such a configuration change, and how much they want to make it. In any case, I really appreciate the help.? Thanks again! Roy From: Mark Sapiro To: mailman-developers at python.org Sent: Monday, August 29, 2016 8:46 PM Subject: Re: [Mailman-Developers] Sequence of steps? On 08/29/2016 09:00 AM, Roy Harvey wrote: > 3) Messages with elaborate formatting, but little text are often larger than 10KB, so they are held for review.? That means the test for size comes BEFORE the message is "cleaned up" and reduced to simple text. > My suggestion is to change the sequence of steps, so that the size filter is applied AFTER the message has been converted to plain text. Yes, I agree that this is a problem, but it is easily configurable. Here's what I've had in mm_cfg.py to do this on my production site for a long time # # Put MimeDel ahead of Hold so "too big" is based on content filtered # message. # GLOBAL_PIPELINE.remove('MimeDel') GLOBAL_PIPELINE.insert(GLOBAL_PIPELINE.index('Hold'), 'MimeDel') # -- Mark Sapiro ? ? ? ? The highway is for gamblers, San Francisco Bay Area, California? ? better use your sense - B. Dylan From barry at list.org Tue Aug 30 11:53:16 2016 From: barry at list.org (Barry Warsaw) Date: Tue, 30 Aug 2016 11:53:16 -0400 Subject: [Mailman-Developers] Sequence of steps? In-Reply-To: References: <1567455177.1443669.1472486445171.ref@mail.yahoo.com> <1567455177.1443669.1472486445171@mail.yahoo.com> Message-ID: <20160830115316.61b7c486.barry@wooz.org> On Aug 29, 2016, at 05:46 PM, Mark Sapiro wrote: >Here's what I've had in mm_cfg.py to do this on my production site for a >long time > ># ># Put MimeDel ahead of Hold so "too big" is based on content filtered ># message. ># >GLOBAL_PIPELINE.remove('MimeDel') >GLOBAL_PIPELINE.insert(GLOBAL_PIPELINE.index('Hold'), 'MimeDel') Anybody looking for something fun to do in MM3 might consider how to surface the creation and shuffling of rule chains (moderation) and pipeline handlers (munging) through REST so Postorius could present an easy configuration screen for list managers. Cheers, -Barry