Mailman 3 March 2002 - Mailman-Developers

Re: [Mailman-Developers] Mailman password and administrative reminders
by Dan Mick 14 Aug '03

14 Aug '03

? This very message came to me with the following header: Errors-To: mailman-developers-admin(a)python.org All my bounces come to the list admin address, set in the admin webpage, in the second field of General Options. Do you have that set to something, and bounces still come to root? > 2. Bounces are sent to the poor postmaster instead of a -admin address. > I'm not entirely certain, but I think an Errors-To: header or something > like that in all Mailman messages might allow one to distribute that load > somewhat.

8 11

External subscriber lists in 2.1
by J C Lawrence 23 Aug '02

23 Aug '02

Barry, In 2.1 when used with external subscriber storage (eg SQL), will the new equivalent of qrunner request and load the entire subscriber DB onto the heap prior to broadcast? <<Yeah, I'm cheating and being lazy on not checking the source myself>> Reason: This poses scaling problems for lists with very large numbers of subscribers. I'd suggest paging thru the set in blocks. ObExcuse: Chap on -users asking about millions of subscribers. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

3 4

suggestion for configure
by Ron Jarrell 11 Jul '02

11 Jul '02

Add a --with-fqdn and --with-url or equivalent. The current cvs snapshot can't guess my fqdn on my production box, and it's used now to build a web of interconnected addresses, as well as populate the VIRTUAL_HOSTS table, so I had to do a bunch of deleting and repairing in mm_cfg. I can, if I *remember*, which I've already forgotten once, fix it when I build by setting FQDN and URL environment variables, so that configure picks those up by default, but I have a habit of just looking at config.status to see how I ran configure the last time. Having an explicit configure switch would be nice.

2 1

Interesting study -- spam on posted addresses...
by Chuq Von Rospach 05 Jun '02

05 Jun '02

Interesting article on slashdot: <http://slashdot.org/article.pl?sid=02/02/17/2031249> Basically, DSLreports did a test, and found that e-mail addresses posted on a web site could start seeing spam in as little as 8 hours. I mention it for two reasons. One, since mail lists manage e-mail addresses (and archives of e-mail addresses), it is yet antother indication of just why we have to be careful about presenting and disclosing that stuff. And second, since one of the addresses presented and disclosed is that of the admin, we really need to come up with ways that allow newbies to contact an admin without easily disclosing addresses to spammers. And, unfortunately, the security problems with formmail.pl have shown THAT isn't really the answer... Chuq -- Chuq Von Rospach (chuqui(a)plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. Very funny, Scotty. Now beam my clothes down here, will you?

20 125

Updated dupe removal patch
by Marc MERLIN 12 May '02

12 May '02

It took all of my sunday, but I just finished porting Ben Gertzfield's excellent dupe removal patch to mailman cvs (I also had to learn some python in the process. I'm starting to believe that Mailman is a conspiracy to get people to learn python :-p) In a nutshell, the patch does two things: 1) it does not send you your list copy if - your subscribed Email address is already in the headers - you already received the message through another list (Cc accross two lists or more on the same site) 2) The new "nodupes" setting is really something you probably want as a default on all lists. I also had lists were people wanted notmetoo as a default too. Ben's fix for that is to have a bitfield per list that you can set and that states which options newly added users get. As Ben said, this breaks the one patch one functionality rule, but when I ported his work to mailman-cvs, I realized that it didn't make sense to take them apart. However, Barry, if that would stop you from merging #1 in CVS, I could remove it, but I'm not sure why one would want to. I've done reasonable tests to make sure I didn't break all of mailman in the process, and the core logic hasn't changed, so the basic functionality is the same that Ben had written and that has been used for 6-9mo? on the debian lists now. In other words, it should work (it does for me, and I'm already running it on my production mailman-cvs list server), but there is always the chance that there might be a corner case buglet left somewhere. Considering this was a pain to port, and how this puts to rest many of the reply-to munging discussions (the only real argument for reply-to munging is that it "solves" the duplicate mails you other receive when people use reply to all), I'm hoping that this could make it in (wink, wink :-D) Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key

3 8

2.1b1 Moderation and From: vs. Sender:
by Harald Koch 07 May '02

07 May '02

I have a small problem with a moderated list as part of my upgrades from 2.0.8 to 2.1b1. This is a "joke of the day" style list. I'm supposed to be the only one who can submit messages to the list; all of the members are moderated (except me). Outgoing messages are stored in a queue, and one is sent automatically by cron once per day. With 2.0.8, I was processing a message by adding a Sender: tag with my address; my address was listed in the 'posters' variable. With "USE_ENVELOPE_SENDER = 1" in my mm_cfg.py, this worked. The list upgrade process handled the 'posters' variable correctly; my list address was marked *unmoderated*, and the other addresses were copied into the new 'accept_these_nonmembers' field. (Good attention to detail, there, btw; kudos!) However, my 'trick' of adding a Sender: field doesn't work anymore, and I get a confusing log/hold message that says "humour post from chk(a)cfrq.net held: Post by a moderated member". 'chk(a)cfrq.net' is not moderated. It turns out that, in order to find the moderation flag of the user that send a message, Handlers/Moderate.py calls msg.get_senders, which returns a *list* of senders with the Sender: last; Moderate.py only looks at the first return value, which is the From: header. The address in the From: field *is* moderated, and so the message is rejected. Later, however, Handlers/Hold.py routine hold_for_approval calls the old msg.get_sender (singular vs. plural), which returns the Sender: field if "USE_ENVELOPE_SENDER = 1" is set, which is why I get the confusing log message. So, two things: 1) The message rejection is confusing. 2) What's the right way to do this under 2.1? Thanks, -- Harald Koch <chk(a)pobox.com> "It takes a child to raze a village." -Michael T. Fry

2 2

Ok, this is weird...
by Ron Jarrell 11 Apr '02

11 Apr '02

Mar 26 21:56:41 2002 (558) Uncaught runner exception: Continuation line seen before first header Mar 26 21:56:41 2002 (558) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Tagger.py", line 47, in process matchlines.extend(scanbody(msg, mlist.topics_bodylines_limit)) File "/home/mailman/Mailman/Handlers/Tagger.py", line 101, in scanbody msg = email.message_from_string(EMPTYSTRING.join(lines)) File "/home/mailman/pythonlib/email/__init__.py", line 36, in message_from_string return _Parser(_class).parsestr(s) File "/home/mailman/pythonlib/email/Parser.py", line 45, in parsestr return self.parse(StringIO(text)) File "/home/mailman/pythonlib/email/Parser.py", line 40, in parse self._parseheaders(root, fp) File "/home/mailman/pythonlib/email/Parser.py", line 69, in _parseheaders raise Errors.HeaderParseError( HeaderParseError: Continuation line seen before first header Now, I'd believe there was something wrong with the header (although mm ought to catch this more elegantly), except the user had just sent it to list1@myserver,list2@myserver, and it made it to *list2*, it just won't go through to list1. I unshunted it, and it failed again the same way. So how in heck did it get to list2? Barry, I saved the copy I got (I'm on both lists), and the shunt files, if you want them; there's nothing private in the message.

2 14

mm-handler redux
by Ron Jarrell 05 Apr '02

05 Apr '02

Ok. Diff against cvs again. Handles the VERP tokens just fine. If I wasn't *still* here fiddling at 7am it'd probably be a tad more elegant, but it work. Index: mm-handler =================================================================== RCS file: /cvsroot/mailman/mailman/contrib/mm-handler,v retrieving revision 1.1 diff -r1.1 mm-handler 1c1 < #!/opt/bin/perl --- > #!/usr/local/bin/perl 5d4 < 7,11c6,17 < ## testlist: "|/opt/pkgs/mailman/mail/wrapper post testlist" < ## testlist-admin: "|/opt/pkgs/mailman/mail/wrapper mailowner testlist" < ## testlist-request: "|/opt/pkgs/mailman/mail/wrapper mailcmd testlist" < ## owner-testlist: testlist-admin < ## testlist-owner: testlist-admin --- > ## > ##testlist: "|/home/mailman/mail/mailman post testlist" > ##testlist-admin: "|/home/mailman/mail/mailman admin testlist" > ##testlist-bounces: "|/home/mailman/mail/mailman bounces testlist" > ##testlist-confirm: "|/home/mailman/mail/mailman confirm testlist" > ##testlist-join: "|/home/mailman/mail/mailman join testlist" > ##testlist-leave: "|/home/mailman/mail/mailman leave testlist" > ##testlist-owner: "|/home/mailman/mail/mailman owner testlist" > ##testlist-request: "|/home/mailman/mail/mailman request testlist" > ##testlist-subscribe: "|/home/mailman/mail/mailman subscribe testlist" > ##testlist-unsubscribe: "|/home/mailman/mail/mailman unsubscribe testlist" > ##owner-testlist: testlist-owner 14,15c20,21 < $MMWRAPPER = "/opt/pkgs/mailman/mail/wrapper"; < $MMLISTDIR = "/var/mailman/lists"; --- > $MMWRAPPER = "/home/mailman/mail/mailman"; > $MMLISTDIR = "/home/mailman/lists"; 122a129,130 > my @validfields = qw(admin bounces confirm join leave owner request > subscribe unsubscribe); 124,126c132 < if ($addr =~ /(.*)-admin$/ < || $addr =~ /(.*)-owner$/ < || $addr =~ /^owner-(.*)$/) { --- > if ($addr =~ /(.*)-(.*)\+.*$/) { 128,129c134,136 < $cmd = "mailowner"; < } elsif ($addr =~ /(.*)-request$/) { --- > $cmd = "$2"; > } else { > $addr =~ /(.*)-(.*)$/; 131c138,144 < $cmd = "mailcmd"; --- > $cmd = $2; > } > if (grep /^$cmd$/, @validfields) { > if ($list eq "owner") { > $list = $cmd; > $cmd = "owner"; > } 190c203 < if (! -f "$MMLISTDIR/$list/config.db") { --- > if (! -f "$MMLISTDIR/$list/config.pck") { 192c205 < if (! -f "$MMLISTDIR/$list/config.db") { --- > if (! -f "$MMLISTDIR/$list/config.pck") {

2 1

mailman filter for SpamAssassin support
by James Henstridge 05 Apr '02

05 Apr '02

I uploaded a patch to the SF bug tracker today that adds support for doing SpamAssassin (http://spamassassin.taint.org/) checks to the mailman message pipeline: http://sourceforge.net/tracker/?func=detail&aid=534577&group_id=103&atid=30… This will contact the spamd daemon to score the message. If the message gets scored above one threshold, it gets discarded (this defaults to 10, but can be customised in the mm_cfg.py file). If the message scores above another lower threshold, it gets held for moderation (this defaults to 5). I wrote this to try and reduce the number of messages held for moderation. I wrote it for mailman 2.0.x (as that is what I am using at the moment), but it should be fairly easy to update for 2.1. It might be worth using on the python.org mailing lists ... James. (I am not on the mailing list, so please don't remove me from the CC list on replies). -- Email: james(a)daa.com.au WWW: http://www.daa.com.au/~james/

4 4

admindb
by Ron Jarrell 01 Apr '02

01 Apr '02

When selecting the "forward to" option (and leaving it otherwise deferred) I get this: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 82, in run_main main() File "/home/mailman/Mailman/Cgi/admindb.py", line 159, in main process_form(mlist, doc, cgidata) File "/home/mailman/Mailman/Cgi/admindb.py", line 644, in process_form forward, forwardaddr) File "/home/mailman/Mailman/ListAdmin.py", line 175, in HandleRequest forward, addr) File "/home/mailman/Mailman/ListAdmin.py", line 311, in __handlepost copy, lang) File "/home/mailman/Mailman/Message.py", line 158, in __init__ self.set_payload(text, charset) File "/home/mailman/pythonlib/email/Message.py", line 160, in set_payload self.set_charset(charset) File "/home/mailman/pythonlib/email/Message.py", line 198, in set_charset cte(self) File "/home/mailman/pythonlib/email/Encoders.py", line 75, in encode_7or8bit orig.encode('ascii') AttributeError: Message instance has no attribute 'encode' This was a fairly large note with a mime attachment.

2 2