Mailman 3 January 2011 - Mailman-Developers

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 a message id to the vette log
by C Nulk 28 Jan '11

28 Jan '11

Hello all, I am using Mailman v2.1.9 with some minor local mods on CentOS 5.5. In looking through the vette log, I noticed some of the log entries for refused postings and discarded postings do not indicate what message (via the message id) was acted upon. I would like to the message id to those entries. I found where the entries are written to in ListAdmin.py. I made a few changes to the file. Since I am barely literate with python, I thought I would post my changes to the list and ask you fine people if I did will work, or am I doomed. There changes are (in diff -u format): --- /usr/lib/mailman/Mailman/ListAdmin.py 2008-05-24 13:44:12.000000000 -0700 +++ ListAdmin.py.SCU 2011-01-28 13:26:12.000000000 -0800 @@ -340,13 +340,21 @@ fmsg.send(self) # Log the rejection if rejection: + try: + msg = readMessage(path) + except IOError, e: + if e.errno <> errno.ENOENT: raise + return LOST + msg = readMessage(path) note = '''%(listname)s: %(rejection)s posting: \tFrom: %(sender)s -\tSubject: %(subject)s''' % { +\tSubject: %(subject)s +\tMessage-id: %(messageid)''' % { 'listname' : self.internal_name(), 'rejection': rejection, 'sender' : str(sender).replace('%', '%%'), 'subject' : str(subject).replace('%', '%%'), + 'messageid': msg.get('message-id', 'n/a').replace('%', '%%'), } if comment: note += '\n\tReason: ' + comment.replace('%', '%%') Also, are there any other files I may need to change? Thanks, Chris

2 1

Mailman Admin section!
by narayan neupane 26 Jan '11

26 Jan '11

Hello Developer Team, I am a web developer in php. Currently i have migrated the site but the admin section was in mailman software at this moment how can i migrate the admin section on new hosting please suggest me with procedure to installed with no data lost at all. Narayan Neupane (Web Developer)

3 2

Wiki downtime
by Barry Warsaw 19 Jan '11

19 Jan '11

Our hosting provider is going to upgrade our wiki instance. There may be a short amount of downtime. Apologies for any inconvenience. -Barry

1 0

Bounce processing in MM3
by Barry Warsaw 09 Jan '11

09 Jan '11

One of the last major subsystems that I need to get working in Mailman 3 is bounce processing. This is different than bounce detection, which has been successfully ported from Mailman 2, but doesn't differ in any significant way. The question I am thinking about now is what to do with a bounce once we detect one. There are a couple of interesting things in MM3 that makes it different from MM2. In MM3, users and addresses are global to the system, while membership is specific to a mailing list. This means if we register a bounce on an address, we can have that score affect the address's subscription to all relevant mailing list. We can also do things like automatically roll over to another registered and validated email address for that user, if there is one, or at least send notifications to the other address. There's also the question about how all the bounce scores are managed, and the knobs you as a list administrator can tweak to control how and when things happen based on the score. Reporting and logging are also part of the plan. Because MM3 uses a relational database underneath the hood, my plan is to have a single table that only appends new bounce events. That way, Mailman will have a permanent record of every bounce that occurred. Exactly what information we can or should put in that table is up for discussion. I do plan also to keep all bounce messages in MM3's "message store" so that postmortem debugging is easier. Because I'm just starting to think about all this, I wanted to throw this out to the list to get your feedback on things you'd like to see. What is it about MM2's bounce processing that you like? What don't you like? What MM2 bounce features can you do without? What would you like to see added? Any and all feedback is welcome. -Barry

4 3

Suggestions about Mailman bounce processing
by Superticker2 (Mark) 07 Jan '11

07 Jan '11

I'm not a subscriber to this list, so please include me superticker2{at}iastate.edu on your cc: line. I have two suggestions I would like to make concerning Mailman bounce processing: 1) All bounces from either a Mass Subscribe or Mass Invite operation should be unconditionally and immediately sent to the list owner. There can be many typos in these Mass Subscribe/Invite lists, and the list owner needs to correct these typos _immediately_. In addition, some of these mass subscription lists come from paper sign-up lists by foreign students where the English alphabet is new to them. Trying to decipher their email addresses can result in 10% typos and bounces, which need immediate corrections. 2) All bounces should be immediately directed to the list owner if bounce processing is switched off. For small lists, it makes the most sense for the list owner to handle bounces manually. Often he'll know the recipients personally and their new email addresses, which he can fix himself when they bounce. As it stand today, there could be 100s of bad addresses on an email list without anyone's knowledge if bounce processing is off; this is bad design.

5 11