Mailman-Developers November 2014

mailman-developers@python.org

12 participants
15 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

Adding CSS to mailman archives
by Andrew Daviel 12 Feb '15

12 Feb '15

A little while ago (November 2012 probably) I changed a mailing list from Hypermail to Mailman and wanted to keep some of the look-and-feel of the archives, e.g. background colour and fonts. So I patched mailman 2.1.9 in CentOS 5 to include a CSS stylesheet link in each generated HTML page, replacing e.g. <BODY BGCOLOR="#ffffff"> with just <body> and adding e.g. body {background-color: #ffffff ; color: black; } in /pipermail/mailman.css, so that HTML style such as FONT and SIZE is removed from the Python code. (I only have one list on that server and didn't implement per-list style) I also changed a few things e.g. content-type to get zero warnings and errors from the W3C online validator. Now if I want to get DMARC functionality I'll have to jump past the RedHat/CentOS release and build 2.1.18, and re-patch for CSS. I was wondering if there was any interest in incorporating CSS into the official releases. -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time)

7 17

Re: [Mailman-Developers] Python3 port of Mailman3
by Barry Warsaw 29 Nov '14

29 Nov '14

On Nov 26, 2014, at 02:30 PM, Abhilash Raj wrote: >I am working on porting mailman3 to python3. There are few doubts I have >which may sound stupid, but I have a little knowledge about encoding and >charsets which I think is important for the port. Also this is my first time >working on python3 so forgive me for asking anything obvious( I did try >googling first) The code is in very preliminary stages with tons of >errors. Its up on launchpad. > > lp:~raj-abhilash1/mailman/py3 Yay! Note that I also have been playing around with it a bit. I wouldn't say it's a functional branch, but you might compare notes: lp:~barry/mailman/py3 >1. `pkg_resources.resource_string` used to read the configuration files while >initialization and testing now returns bytes instead of string(like in >python2). Right. "resource_string" is really a misnomer. In another Python 3 project I work on, I use: from pkg_resource import resource_string as resource_bytes just so that the call sites are accurate. >So instead I use `pkg_resources.resource_stream` and deocode to the steam to >a `utf-8` encoding(why? to avoid errors for the time being). I wanted to ask >what would be the best for this case? You can of course also decode the bytestring that "resource_bytes" returns. That's generally what I do in that other project. >2. To create a hash everywhere unicode strings must be encoded. So again the >same question what should I encode it to? UTF-8 or US-ASCII? Or someway to >determine which encoding should be used? I think utf-8 is generally the right encoding to use, except in contexts where you are given a better hint. E.g. if you're decoding say the payload of a message with a Content-Type header, and that header has a `charset` attribute, it will name the encoding that you're supposed to use. There may be cases where us-ascii or latin-1 would be better, but I think those should be determined on a case-by-case basis. >Also if anybody has suggestions on porting please let me know. I am online >sporadically on irc as `maxking` on #mailman (I see all of the messages sent >while I am away). The trunk should now be `python2.7 -3` clean, so it's ready to be ported. I'd probably not try to run the full test suite yet, but start at the lowest level, e.g. database/model and work your way up. If there are changes that make sense even in Python 2 (i.e. for bilingual support for now) try to put those in separate branches and merge proposals, so they can be merged into trunk even before a full port. This page will be indispensable: https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef Cheers, -Barry

1 0

Changing the default_moderation_action has no effect on existing members
by Stephen J. Turnbull 26 Nov '14

26 Nov '14

Aurelien Bompard writes: > I suggest we leave the member's moderation_action on None when it's > created, and modify the moderation rules to go look for the list's default > setting if the member's value is None. I think this is a bad idea. From the subscriber's perspective, it changes the list's behavior with no action from her, for no good reason that she knows. The semantics of these variables is, and I think should be, initialization, not fallback.

2 1

Re: [Mailman-Developers] Changing the default_moderation_action has no effect on existing members
by Barry Warsaw 26 Nov '14

26 Nov '14

On Nov 25, 2014, at 11:46 AM, Aurelien Bompard wrote: >As a result, unless I'm missing something changing, the list's >default_moderation_action has no effect on existing members. Do I >understand correctly? That is correct. As Steve points out, the intent is that this setting is initialization not fallback. I think this does work differently in MM2.1, but that version's schema isn't really sophisticated enough to do anything different. There, members have a moderation flag which gets initialized from default_member_moderation. Then, if the member's flag is set, member_moderation_action (a list setting) is taken. So I guess in the case of moderated members, there is a fallback action, and while there is no member-specific action, there is a member-specific state. MM3 collapses that so that rather than having a flag with a fallback action, each member just has an action. This allows you more flexibility in controlling an individual member's posting privileges, at the cost of having to change all members individually if a list's default changes. Can you elaborate on the use case for having a fallback action? Note that in MM3, nonmembers are technically members too, but with a 'nonmember' role, so the same moderation action flag controls their posting privileges too. This replaces MM2.1's generic_nonmember_action and the crufty lists of {accept,hold,reject,discard}_these_nonmembers. Cheers, -Barry

3 5

Python3 port of Mailman3
by Abhilash Raj 26 Nov '14

26 Nov '14

Hi All, I am working on porting mailman3 to python3. There are few doubts I have which may sound stupid, but I have a little knowledge about encoding and charsets which I think is important for the port. Also this is my first time working on python3 so forgive me for asking anything obvious( I did try googling first) The code is in very preliminary stages with tons of errors. Its up on launchpad. lp:~raj-abhilash1/mailman/py3 So my doubts: 1. `pkg_resources.resource_string` used to read the configuration files while initialization and testing now returns bytes instead of string(like in python2). So instead I use `pkg_resources.resource_stream` and deocode to the steam to a `utf-8` encoding(why? to avoid errors for the time being). I wanted to ask what would be the best for this case? 2. To create a hash everywhere unicode strings must be encoded. So again the same question what should I encode it to? UTF-8 or US-ASCII? Or someway to determine which encoding should be used? Also if anybody has suggestions on porting please let me know. I am online sporadically on irc as `maxking` on #mailman (I see all of the messages sent while I am away). thanks, Abhilash Raj

1 0

Re: [Mailman-Developers] Changing the default_moderation_action has no effect on existing members
by Richard Damon 25 Nov '14

25 Nov '14

On 11/25/14, 5:46 AM, Aurelien Bompard wrote: > Hi *, > > I'd like to discuss the algorithm we use to enforce a list's default > moderation action. Here's what I understand: > - the list's default_moderation_action setting is stored in the database > and can be changed via the REST interface > - when a new member is created, its moderation_action is imported from the > list's default_moderation_action depending on its role (see > model/member.py:84) > - this member's moderation_action is stored in the database > - it's the member's moderation_action that is used in the moderation rule > (rules/moderation.py:52) > > As a result, unless I'm missing something changing, the list's > default_moderation_action has no effect on existing members. Do I > understand correctly? > > I suggest we leave the member's moderation_action on None when it's > created, and modify the moderation rules to go look for the list's default > setting if the member's value is None. > How about that ? Other suggestions? > > Aurélien > The only way I could see that would be to make the flag 3 valued: They are moderated They are not moderated They are in the default state of moderation, see the lists default value. -- Richard Damon

1 0

Changing the default_moderation_action has no effect on existing members
by Aurelien Bompard 25 Nov '14

25 Nov '14

Hi *, I'd like to discuss the algorithm we use to enforce a list's default moderation action. Here's what I understand: - the list's default_moderation_action setting is stored in the database and can be changed via the REST interface - when a new member is created, its moderation_action is imported from the list's default_moderation_action depending on its role (see model/member.py:84) - this member's moderation_action is stored in the database - it's the member's moderation_action that is used in the moderation rule (rules/moderation.py:52) As a result, unless I'm missing something changing, the list's default_moderation_action has no effect on existing members. Do I understand correctly? I suggest we leave the member's moderation_action on None when it's created, and modify the moderation rules to go look for the list's default setting if the member's value is None. How about that ? Other suggestions? Aurélien

1 0

falcon branch is merged
by Barry Warsaw 15 Nov '14

15 Nov '14

I'm happy to say that with Kurt Griffiths' release of Falcon 2.0b1 to PyPI, I have merged the MM3 falcon branch to trunk. This means the Mailman internal dependency transitions are complete. Along with the SQLAlchemy transition, our trunk should now only depend on Python 3 compatible libraries. Porting MM3 to Python 3 is not on the critical path for the final release, but at least work on that can now begin. Happy hacking. -Barry

1 0

Want Mailman 3 suite to release faster? Here's some bugs you can help with!
by Terri Oda 12 Nov '14

12 Nov '14

Some weeks back, Florian went through the Postorius bug queue to find a list of bugs that he thinks are blocking us from being able to have a final Mailman Suite release. I just wanted to advertise that list to you all in case anyone here is looking for some valuable work to do: https://bugs.launchpad.net/postorius/+bugs?field.tag=mailman3-suite-blocker There's only 13 of them at the moment, so that's nice. They're in a variety of different states. Some are somewhat old and we could really use someone to just try to reproduce them on the most recent version of postorius and post an update in the bug saying it's still a problem (or not!). Some have notes from me suggesting a smaller piece that could be done first by a beginner wanting a new bug to try or someone more experienced wanting a quicker task. (don't worry about saving beginner bugs at this stage; I'm more interested in seeing a release!) Some are more complex. If anyone's got time to push these forwards in any way, it would be very much appreciated! I'm even happy to send you some mailman stickers if you want a physical token of appreciation. Terri

4 3

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 November 2014