Mailman 3 November 2008 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

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

"Orignal" MySQL Member Adaptor - 1.71
by Kyrian (list) Jan. 8, 2009

Jan. 8, 2009

All, I finally managed to find some vestige of free time after midnight (hardly the best time to be coding...) recently, and accordingly put out a new version of my MySQL MemberAdaptor. I have no time, and little motivation (no customers wanting to use it at the present time) to test it, so I haven't, but you're welcome to try it out. It should according to the docs I found, provided I've applied them correctly, fix the non-ASCII character encoding problems (I've relied on the assertions about list members to cover that angle, and just checked encoding on the 'user supplied' parameters to various function calls). Now would be a good time for someone to send me a Python language reference book ;-) However since I've changed development environment since the last version, it's possible that various things have gone wrong (certainly the version numbering has gone mad between RCS and CVS/Eclipse), so don't do it in a production environment. I've put it here, as version 1.71, whatever that might actually mean: http://www.orenet.co.uk/opensource/MailmanMysql/ Incidentally, since Fil seems to be taking all the credit for what I started I think he should actually put a proper credit in there for me, linking to my business website at http://www.orenet.co.uk/ rather than the vague passing mentions that are in the docs/code of his version of the system at the present time. With luck I will be able to coax one of my customers into 'sponsoring' further development of the MySQL Adaptor with proper integration into Mailman in a sane way that is agreed by everyone instead of (as seems to be the case from what little of this list I have had time to read) just going off on its own sweet way and reducing the likelyhood of acceptance into the main code base of Mailman, but I am not sure how that will go. If anyone else wants to sponsor my time to code this thing better and further, then just email me. Best of luck with it, whatever happens. More updates in whichever year I manage to find spare/free time. Yours Sincerely, Kev Green.

7 19

Duplicate Prevention
by Dan Mahoney, System Admin Dec. 6, 2008

Dec. 6, 2008

Hello all, We've recently taken on mailman to handle many large, popular lists at my day job, and one strangely-missing feature is the inability to avoid duplicates when someone cc's a list's old alias and new alias (we also moved the lists to a subdomain, out from under our primary). It's suggested in the FAQs that this could be done using procmail -- but I'd think it (could/should) be done in mailman itself. The list-id header is ideal for this, and it SEEMS to be not more than a dozen lines of code to do the same sort of per-list "lockfile" that the procmail recipe does (plus add a variable to make it tunable in either the config file, or the web-ui). Presumably lockfiles could expire after 7 days. Locks could also be an entry in a .pck database. The question is (and the reason I ask this on a developer list rather than -users) -- is there anyone here who could provide a patch to add this functionality, or who is interested in taking on such a task for some sort of compensation/donation? Please contact me off (or on) list if anyone's available. Another great feature would be to have mailman "strip" multiple cc recipients. I.e. if a message is sent: to: list cc: list-alias(*), another-list-alias(*) -or- to: person cc: list, list-alias(*) To have these (*) stripped (and prevent the need for this). But that's more work, and right now the duplicates are a major regression from what we had before. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

2 1

Python 2.6 compatibility
by Barry Warsaw Nov. 29, 2008

Nov. 29, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, My branch to fix Python 2.6 compatibility for Mailman 2.1 is ready to be reviewed. You should have gotten a "merge proposal" message in your inbox about it. For reference the proposal is here: https://code.launchpad.net/~barry/mailman/py26/+merge/1998 Basically, this is asking you to review the code changes, which you should be able to do by email or web. Let me know if you have any questions about how to interact with this part of Launchpad. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkkx1tAACgkQ2YZpQepbvXEnYwCcDArq9XcU1Q/rj/DIeTZkMxfG KpEAniKrwP6tSzVLejBXBxH2sLN+2edo =WQBU -----END PGP SIGNATURE-----

1 0

SpamBayes for gate_news - who can test?
by skip＠pobox.com Nov. 29, 2008

Nov. 29, 2008

I pushed a Mailman branch to Launchpad which hooks the gate_news cron job into SpamBayes. On python.org we do a fair amount of early reject/filter stuff at the SMTP step. One of those things is to run incoming mail through SpamBayes (if it doesn't get rejected by an earlier step). Unfortunately, messages coming from the comp.lang.python newsgroup destined for python-list(a)python.org just waltz right in as pretty as you please without so much as a sniff from our spam-trapping tools. It seemed to me that the correct place to sniff is in gate_news, so I implemented the necessary bits there to run incoming mail through SpamBayes and hold any messages which look like they are or might be spam. I am, however, neither a Mailman developer nor a Usenet user. Setting up the necessary scaffolding (Mailman instance, Usenet news connection, etc) would be much harder for me than the work I've done so far stitching SpamBayes into gate_news. I thought about adding a --dry-run flag to gate_news then testing my version out in parallel with the active version already running on mail.python.org but it seems that would be difficult to do as well since it's pretty hard to completely disconnect it from the list data. So I come, hat in hand, looking for some brave Mailman developer who is willing to test out my modified version of gate_news. You can grab the latest version from Launchpad: bzr pull lp:~smontanaro/mailman/SpamBayes There is an associated doc repo with a few instructions for setting up the SpamBayes stuff: bzr pull lp:~smontanaro/mailman-administrivia/SpamBayes A sample spambayes.ini file lives in the cron directory alongside gate_news. It's basically what I would use on mail.python.org if I had the necessary savvy to do this myself. If you have any questions I'd be happy to answer them. I can help you get SpamBayes installed if you've never done that before. (It's quite straightforward if you're familiar with the normal Python setup.py thing or use setuptools.) I can also provide ham and spam training sets from mail.python.org so you can construct a useful database for SpamBayes to score messages against. (You could run with an empty training database but that would just cause all messages to score as "unsure" and be held as possible spam.) -- Skip Montanaro - skip(a)pobox.com - http://smontanaro.dyndns.org/

2 1

Unicode member addresses
by Mark Sapiro Nov. 24, 2008

Nov. 24, 2008

Last month a user encountered a problem with Decorate throwing a TypeError because the interpolated footer was a unicode where it was expected to be a string. See the thread at <http://mail.python.org/pipermail/mailman-users/2008-October/063786.html>. It turns out that he was interpolating user_address in the footer and some of his member addresses are unicode causing the interpolated footer to be unicode. I note that since 2.1.3 (before my time) bin/list_members has had a --unicode option to list unicode members. I can't see in current Mailman how a member address can be unicode. Are unicode addresses expected? Under what circumstances? Was this a bug at one time? My main concern is I worked up a patch <http://mail.python.org/pipermail/mailman-users/attachments/20081028/76521ff…> to fix the TypeError for the user with the problem, and I wonder if it should be committed in the current code. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Feature question: mailAlternateAddress
by Simon Fraser Nov. 11, 2008

Nov. 11, 2008

Hi folks, Asking here because I saw the note to keep 3.0 discussion off -users. One of the features that would be nice for my site, and I'm sure others, would be support for alternate addresses for users. For example, users here have the mailAlternateAddress field in LDAP populated with all their firstname.lastname, initial.lastname and nickname email aliases, and sometimes set their mail clients to identify as these, causing their posts to be held or rejected. It would be nice if mailman could either query a specified location for alternate identities, or accept a generated list of them for the current membership list. It seems problematic to wedge a list of alternate addresses into accept_these_nonmembers, as we would never be entirely sure if someone had unsubscribed from the list but been administratively allowed to post to it, and I'm sure it will confuse the list administrators who have to keep both alternate addresses and non-members in the same text box. I see 3.0 has support for LDAP and other forms of back-end database, so I was wondering if support for mailAlternateAddress would be part of that new feature-set? If not, may I request it? Thanks, Simon. -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

2 1

MM command prefix and-or single mm-admin CLI frontend
by Andy Buckley Nov. 8, 2008

Nov. 8, 2008

Hi, I've been meaning to send this mail for a long time, but for one reason or another (mostly fear of making UI suggestions for a project whose internals I don't really know) have repeatedly managed to put it off! It sounds trivial, but one thing that I've always regarded as a usability problem in MM2 is the proliferation of admin command names. As a terminal junky, a common way to learn the functionality of a multi-purpose set of command line tools is to type their common prefix and press tab to see what commands are available. In MM, there is no common prefix, so this option isn't available and memory is needed to remember the right command name... commands like 'newlist' and 'config_list' are spread higgledy-piggledy through name-space rather than being neatly stacked in one corner. It would be great for usability if MM3 could use admin commands with e.g. a "mm-" prefix (with installation of backwards compatible versions maybe as an option) An alternative approach, used most prominently by Trac, is to have a single admin command which can either behave like a non-interactive process or a subcommand interpreter, depending on how it is called. I would be happy to spend some time on a mm-admin command, using the same Python "cmd" module as trac-admin if there is the interest. This might also involve moving some of the intelligence out of the admin scripts and into the API, which is also good news for people like me who have a need/desire to hook MM into a wider system management framework. Anyway, that's the idea --- what do you think? And apologies for being presumptuous ;) Best wishes, Andy PS. I'm also interested in taking a look at MM3 templating... is this being actively worked on or did it stall after the GSoC effort?

4 3