Mailman 3 April 2000 - Mailman-Developers

Re: [Mailman-Developers] Speaking of pathological behavior...
by Dan Mick 11 Apr '00

11 Apr '00

> [Dan Mick] > > > 1) the archive links are remade, even though they exist (probably not a big deal) > > 2) config.db.tmp is written, and then .db becomes .last and .tmp becomes .db. > > Thanks for reporting, I think the change I just checked into CVS > should fix this (admin.py was calling MailList.SetUserOption() without > the keyword argument "save_list=0", causing the list to be Save()d at > least > > admin_user_chunksize * len(("hide", "nomail", "ack", "notmetoo", "plain")) > > times(!) every time the list's Membership Management page was > visited). Yup... > > Probably batching up all the "changes" into one config.db write is a > > big big win. > > The bigger a admin_user_chunksize you're using, the bigger this win > will be :) The only other thought I had was that comparing the options and only saving on a change might be *slightly* safer (crashes inbetween users would save more info) but I don't know that it's worth the extra code complexity. Thanks for the checkin, Harald. It's a big help for me, and now I can stop bugging Barry about it. :)

1 0

Change to acceptable_aliases
by bwarsaw＠python.org 11 Apr '00

11 Apr '00

Hi folks, I want to make a change to the semantics for the privacy option `acceptable_aliases' for beta 3. Harald recently (and rightfully) backed out a change I'd made between 1.1 and 2.0b1, which caused me to re-examine how this option is used. The purpose of acceptable_aliases is to be able to specify a list of aliases for your mailing list that are acceptable as recipients if require_explicit_destination is set to true (which it is by default). The example I like to use is if I have a mailing list foo(a)python.org I might want to allow `foofriends(a)alterpost.com' to be a valid forwarder to the mailing list. The trouble comes in that the regexps in acceptable_aliases are only matched against the localpart of the recipient address. This means that if I were to put `foofriends(a)alterpost.com' in this field, it would actually fail to match a To: header with this address in it. I'd instead have to put `foofriends' in this field, but then this would allow `foofriends(a)evil.com' to post to the list too without trigger the spam detector. My proposal is to change the semantics of acceptable_aliases, so that matching is done against the entire recipient address, not just the localpart. To support backwards compatibility, I'm willing to use the following rules for 2.0: 1) if the regexp does not contain an `@', then match only against the localpart as before. 2) if the regexp contains an `@', match against the entire recip address. 3) deprecate #1 so that a future release will only match against the entire address. Thoughts? Is anybody using acceptable_aliases? -Barry

1 0

Re: [Mailman-Developers] New MTA interface in mailman 2.0b
by Nigel Metheringham 11 Apr '00

11 Apr '00

NM> 2. I'm concerned the patch above might do bad things when it NM> comes to sending out list reminders :-) BW> Password reminders are sent through DeliverToUser. You can actually BW> force a mass password reminder mailing by running Let me explain further.... The sendmail command is given by cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + mlist.GetAdminEmail() + ' ' So the sender is set to be the list admin address. However when sending passwords out presumably there isn't a single list thats being dealt with - so will that mlist.GetAdminEmail() work correctly? [Unfortunately I still find reading python a significant chore and its taking time to get up to speed on being able to answer this stuff myself :-( ] > I definitely recommend people use SMTPDirect.py instead, especially > after the qrunner additions in 2.0beta2. I had missed the implications of that change - I definitely agree that SMTP injection looks like a win here, so I'll reconfigure my box back. > One module that all messages pass through is CookHeaders This looks like a change... the admin messages have had more header processing done on them. As I said before, its not actually a problem, just a change that caught me out slightly (some admin mail was being misrecognised by my procmail as list mail so ended up in the wrong bucket - I will take a cluebat to my procmailrc :-) ). The other advantage to moving to SMTPDirect as a delivery scheme is that my exim HOWTO works unchanged :-) Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

Re: [Mailman-Developers] observations from new user
by Harald Meland 10 Apr '00

10 Apr '00

[Brian Grossman] > One general observation: Why does DEFAULT_PRIVATE_ROSTER default to > 0? I would think that 2 would be a better choice. Well, obviously someone had to choose some sort of default back in the murky beginnings of time. Why that someone preferred 0 over 2? Dunno, but as long as people have become used to this, or even are comfortable with it[1], I think you'd have to make a stronger argument for why you think it should be changed than the quick note above :) > I'm using this with qmail. 2.0beta2 seems to work well with qmail > 1.03. Great! > Where should I send a script that eliminates the need for five > .qmail files per list? As Ricardo said: Here would be a good place. [1] I can't recall having seen mention of this default setting from others, but then again I haven't been reading mailman-users for quite some time... :( -- Harald

2 1

New MTA interface in mailman 2.0b
by Nigel Metheringham 10 Apr '00

10 Apr '00

I've got a couple of queries about how the MTA interfaces in mailman hang together now - I'm also putting some of the initial stuff in more detail so others can find out what to hack to select things. There are 2 MTA modules - Mailman/Handlers/SMTPDirect.py Mailman/Handlers/Sendmail.py I would say from what I have seen of the Sendmail.py one that most developers have been using SMTPDirect :-) - thats the default in Defaults.py To use the sendmail i/f add this to mm_cfg.py DELIVERY_MODULE = 'Sendmail' SENDMAIL_CMD = '/usr/sbin/sendmail' [I actually use exim, but MTAs on linux with a sendmail like interface normally have a presence - either a symlink or a sendmail CLI emulator - at /usr/sbin/sendmail ] You also need to add the appropriate magic for your MTA to accept the lies that mailman tells it as an appropriate sender address (ie the -f parameter to sendmail). In my config with exim this means adding trusted_groups=mailman to my config file. I also needed to patch Sendmail.py to get the envelope from addresses right:- --- Sendmail.py.orig Tue Mar 21 06:25:51 2000 +++ Sendmail.py Sun Apr 9 22:17:37 2000 @@ -56,7 +56,7 @@ # nothing to do! return # Use -f to set the envelope sender - cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + msg.GetSender() + ' ' + cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + mlist.GetAdminEmail() + ' ' # make sure the command line is of a manageable size recipchunks = [] currentchunk = [] So, now to the questions:- 1. Everything now looks like a list mail - looks like some items which used to look distinct from list mails have the same headers as the list mails [ie admin/info mails have now acquired extra headers] Is this intentional/good?? [I'm agnostics really - its just a change] 2. I'm concerned the patch above might do bad things when it comes to sending out list reminders :-) 3. What happens in either MTA interface if the MTA cannot accept the message [for SMTP either connection refused, or a negative reply code? For Sendmail a negative reply code] - is the message dropped?? How does the bit of queue handling thats left tie into this? Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

2 1

Bouncers/Exim.py
by Jim Tittsler 10 Apr '00

10 Apr '00

Exim adds a header to bounce messages that might be used to catch the bounced addresses, rather than trying to parse the message text. I've been using this trivial bouncer for a while with my 1.2CVS installation and it seems to be doing the right thing. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/

2 1

2 quickies..
by Matt Davis 10 Apr '00

10 Apr '00

1. Just making sure with staying up with the CVS tree, will I overwrite any info (list config/membership/etc.) if I update my /home/mailman/mailman (CVS source dir) and then do 'make install' (which now does 'make update'). 2. I think I found a little bug. When a message is kicked to the admin for the message having too many users. After the admin approves the message to be sent, it does not show up in the archive page. -- Matt Davis - ICQ# 934680 http://dogpound.vnet.net/ NoWonder UNIX Tech - http://www.nowonder.com Is the glass half empty, half full, or twice as large as it needs to be?

2 3

Re: [Mailman-Developers] [ANNOUNCE] Mailman 2.0 beta 2
by Nigel Metheringham 09 Apr '00

09 Apr '00

Looks to me like the Sendmail interface is pathologically broken :-( The envelope sender address is wrong (set to original message sender rather than list so subscribers get the bounces back). My quick hack fix is attached, but I wonder what happens for (say) monthly reminder mail - whats set for that? Nigel. --- Sendmail.py.orig Tue Mar 21 06:25:51 2000 +++ Sendmail.py Sun Apr 9 22:17:37 2000 @@ -56,7 +56,7 @@ # nothing to do! return # Use -f to set the envelope sender - cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + msg.GetSender() + ' ' + cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + mlist.GetAdminEmail() + ' ' # make sure the command line is of a manageable size recipchunks = [] currentchunk = [] -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

Re: [Mailman-Developers] Post to every list, just in case...
by Harald Meland 09 Apr '00

09 Apr '00

[Nigel Metheringham] > Additionally do we need to consider:- > > 1. Hierarchical lists - ie moderated announce lists that post into > other lists, with decent support for building a union of > subscribers - maybe rather than subscribing x-users & x-developers > to ax-nnounce, a way of telling the list to pull in these lists' > subscribers too. I've got something like this running here, implemented as a generic "metamember" mechanism. I think I posted some kind of description of metamembers here earlier, have a look in the archives. Anyway, I won't consider (backporting and) committing that part of my tree until after 2.0 is out. > 2. Filtering on lists to detect cross posting and do something... What do you mean when you say "filtering"? Do you have any ideas as to what the configuration interface[1] for this should look like? > 3. An idea of what "something" should be :-) Why, one should delete the lists crossposted to, of course, to teach those lusers to stop crossposting :-P [1] I assume we'd want to have such a thing :) -- Harald

1 0

Re: [Mailman-Developers] membership managent web interface
by Harald Meland 09 Apr '00

09 Apr '00

[Ricardo Kustner] > Hi, > > On Sun, Apr 09, 2000 at 08:19:49PM +0200, Harald Meland wrote: > > > But most of the times you know the exact address you want to unsubscribe > > > or view/edit, so why not add a search box on top? > > Can't this already be done by using the list member's "options" page > > (using the user's address in combination with your list admin > > password)? > you mean something like > http://server/mailman/options/mailinglist/ricardo--at--rixhq.nu ? Yup -- the URL with the unobfuscated email address at the end works just as well, or you can get to the page by using the "Edit Options" box typically found on a list's "listinfo" page. > besides not being very convenient to do, i don't think it works w/o > knowing the users' password... Have you tried? > as far as i can see there's no way telling you're the admin If you are able to supply the list admin password, then that should suffice :) > and I doubt that admin password can override it. The list admin password can always be used in place of any member's password. And, the site admin password can always be used in place of any list admin password (and therefore also in place of any list member's password). > > I disagree. The list admin interface is cryptic enough as it is, IMO. > > Further obscuring the overview of list members wouldn't be nice. > > actually I suggested this because I think that would make the member > options much more simple. Having a partial list of the members > immediately is what makes it cryptic IMHO. I agree that the chunk-stuff can be cryptic, but I don't think that requiring the admin to follow additional links (or whatever) to even get to that chunk-sized interface would make the admin interface as a whole less cryptic. What do others think? > My list has about 1700 members and navigating with the way it is not > is not very convenient (even if you get used to it) and I can't > imagine how it would be like for people with 10k lists :) Me neither :) -- Harald

1 0