Mailman 3 March 1999 - Mailman-Developers

fork() problem and popen2.py test
by Christian Tismer 10 Mar '99

10 Mar '99

Hi, again I had lots of trouble with Mailman on starship.skyport.net . Mailman was unable to deliver messages, but didn't tell it. The reason turned out to be dependent wether Python 1.5 (the early version, of course) was made with threads or not. The threaded version had a bad effect on sys.stdin after an os.fork(). sys.stdin was a "bad file number" in the child process. Maybe these are known things, but there are some issues: To Guido: the popen2.py program does a very good job in its self test procedure. Why is this not included in the standard test suite? Also, after "make clean" and a new "configure", the problem did not vanish. I did after a "make distclean". To the Mailmen: It was quite hard to track this error down through the mailman scripts. Finally, I ended up if I made the deliver fork temporarily into a do-nothing. The "deliver" script does a number of forks. I does no proper checking if the forks work (under Linux, btw., fork never returns ENOMEM, so the check isn't safe yet). Deliverer.py also trusts the os.popen very much. In my situation, the error logging was quite random, in three of about 200 tests I got a "broken pipe" message in the log, in the other cases, there was just nothing. It seems to be a race condition which forked process dies first, - I'm not sure. Anyway, sys.stdin is read without error checking in the deliver script. I think, some more checks are necessary to guarantee that failing deliveries get noticed. The combination of a) threaded Python1.5 behavior and b) too much trust from Mailman caused me a desperate error search. Took me 8 hours to nail it down. I thought I should tell this, to avoid similar effects for others. cheers - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home

1 0

Re: [Mailman-Users] posting restrictions still confusing to me (or not
by Barry A. Warsaw 10 Mar '99

10 Mar '99

About posting that are held for approval even thought they seem to be coming from a list member when member_posting_only is set to true... Here's what I'm seeing. I put the following in Mailman/MailList.py inside the Post() method: sys.stderr.write('envsend: %s, sender: %s\n' % (msg.GetEnvelopeSender(), msg.GetSender())) This will write the envelope sender and `header' sender to logs/error, which you can tail as you send messages to the list. For me, envelope sender is always None, so the test falls through to msg.GetSender(), which is taken from my spoofable From: header. Back in November, Scott added the use of GetEnvelopeSender() before GetSender() because he'd been hit by a spam getting through that should have been held for approval, but IIRC, Scott's also been backing away from using the envelope sender in some situations. Maybe Scott is able to elaborate. rfc822.py gets the envelope sender as the unixfrom attribute on the message object. This it gets from the "From " line in the message. I don't understand why you're getting something different from me (I'm using sendmail 8.9.something). Anyway, here's what I propose. I'll add a variable to Defaults.py/mm_cfg.py called, say APPROVE_WITH_ENVELOPE_SENDER which will be set to true by default. You set it to false and Mailman will only use the sender. I'll add info to the FAQ and such explaining that this is easier to spoof, but may work around problems where the envelope sender isn't getting set correctly. If anybody can debug this further, I'd appreciate it. -Barry

2 4

Proposal for funded custom work on MailMan
by J C Lawrence 09 Mar '99

09 Mar '99

VA Research is potentially interested in using MailMan for a number of internal and external activities, but would need a couple extensions to the current beta: 1) We need to be able to distinguish between "internal" and "external" lists. An internal list would refuse all subscriptions and posts from addresses which didn't match a given pattern (eg only messages originating from *(a)*varesearch.com can subscribe/post). External lists would be without such controls. 2) As discussed here previously, an ultra-simplified list-creation and administration interface suitable for giving to a computer illiterate HR person to create mailing lists on demand. We are potentially willing to fund one or more of the MailMan developers making these changes for us as long as the resultant changes are folded into the MailMan base release at some future date, and the changes are released under the GPL. I understand the concerns about folding such changes into the production version so close to 1.0 release, holding off on the patches till post-1.0 would be utterly acceptable. If one of the mailman developers is interested in discussing this with me, please email me at claw(a)varesearch.com and we'll see what we can work out. -- J C Lawrence Internet: claw(a)kanga.nu ----------(*) Internet: coder(a)kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

1 0

change request: admin password changing
by Greg Stein 09 Mar '99

09 Mar '99

small change request: remove that dang password-change dialog from every screen I don't see a need to have it on *every* screen. It seems awfully redundant, and just ends up cluttering the other screens. -g -- Greg Stein, http://www.lyra.org/

3 3

Re: [Mailman-Users] Possible Fix for password lookup bug
by Barry A. Warsaw 09 Mar '99

09 Mar '99

>>>>> "BR" == Brian Ryner <bryner(a)uiuc.edu> writes: BR> There's a bug that can come up when you mass subscribe users. BR> The script does not lowercase the email addresses when they BR> are mass-subscribed. This causes problems for just about BR> everything, including password lookup, because when you type BR> the email address to go to the options page, it uses a BR> lowercased version of it. Then, since the password is stored BR> with an uppercased version of the address, it can't find it. BR> If users subscribe themselves, their email address gets BR> lowercased and spaces get removed. Therefore, I'd suggest BR> applying this same behavior to the mass subscribe feature. What version of Mailman are you using? The policy is this: the user name part of the email address is case-preserving because RFC 822 says it must be. However for the Web side of the world, email addresses are lower cased. This means if I subscribe BWARSAW(a)python.org, email will always be delivered to BWARSAW(a)python.org, but my options will be at .../bwarsaw__at__python.org This has all been verified to work in Mailman 1.0b9. -Barry

5 15

bounce processing question and idea for future enhancements...
by Jeff Hahn 09 Mar '99

09 Mar '99

Bounce processing question... Since some of the big email domains (hotmail, aol, etc.) are known to "burp" and deny existence of perfectly valid users, I'd like to handle all returns as bounces and not remove people automatically on the first "user unknown" message. I assume the way to handle it is to change "REMOVE" to "BOUNCE" in the lines like the following in bouncer.py (regex.compile('.*%s: User unknown.*' % email_regexp), REMOVE), Any comments? Any better way to do it? Idea for future enhancements... This is the big one. Does anyone besides me have a desire to see Mailman support Listserv style "topics"? Where topics are extracted from the message subject and list messages are sent to a subset of the list that "subscribes" to that particular topic? I have a very pressing need for this feature. I'm leaving procmail/smartlist because of this and was intending to "roll my own" MLM when I came across MailMan. MailMan supplies a huge portion of the framework with all the nice bells and whistles, so I've decided to start with it. If there is additional interest, I'll try to get rolling on this within the "official" channels. If anyone is interested in collaborating on this that would be great. I certainly haven't been involved with MailMan long at all and don't have any background about the various design choices that were made along the way. Feedback on this would be GREATLY appreciated. -Jeff

2 1

Re: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9
by Harald Meland 09 Mar '99

09 Mar '99

[Per Starback] > Wish list: > > * Add Mail-Followup-To header. (I've done that for myself, but > I would appreciate not having to do it again, as well as I'd like > to see more use of this useful although nonstandard header.) As this (currently) is a non-standard header, I wouldn't feel good about putting explicit support for it into Mailman. However, a more general "Add this header (standard or not) (if it doesn't exist already) to all messages to this list" might be good. But not for 1.0, methinks. > * Possibility for individual list members to say if they want > a Subject line [tag] or not. That would mean that there would have > to be two versions of each message, but I think that would be worth > it as the [tag]/no tag preference is more about the preferences > (and mail situation) of individual list members that about the > preferences of the list itself or its maintainer. I would never > add a tag like that on my lists per default, but if users who want > it could get it explicitly that would be nice. For users it is always good to make _all_ the bells and whistles configurable. However, Mailman has to find a balance between user configurability and how efficient list delivery should be. This means we have to make sure that making something user configurable won't make list delivery unbearably inefficient for any Mailman installation. Once we start going down the road of deciding which options should be made user configurable and which aren't really worth it, it is *very* easy to get lost. There are lots of other good candidates for user configurable options concerning outgoing list messages: Adding a Reply-To: header, including the list footer, including the list header, and of course VERP. The added complexity of Mailman code this would need is also an issue. So, what I'm trying to say, is: Yes, this would be nice to have for some installations -- but don't hold your breath :) > * A line at the Membership Management page where you set default > attributes for new users in the same way that you can change > attributes for the existing users. This more general feature > would be instead of the > > Which delivery mode is the default for new users? > and > When receiving digests, which format is default? > > questions on the Digest-member options page. Yes, this would be nice. I'll try looking into it. > I think I would like to set "hide" by default, If you're talking of changing the Mailman default setting, that would be an incompatible change -- and those suck. Thanks a lot for your suggestions on how can be Mailman improved -- and do keep 'em coming! -- Harald

5 6

to edit de alias file
by Roger Peña Escobio 06 Mar '99

06 Mar '99

Hi I was looking the alias_wrapper file in src/ subdir , trying to fix it , because the creation of a new list is, I think, incomplete if we can't edit an aliases file automatically, I found only one thing, the line 87 > execlp(SENDMAIL_CMD, SENDMAIL_CMD,"-bi"); need another argument, NULL, that is , the line should be > execlp(SENDMAIL_CMD, SENDMAIL_CMD,"-bi", NULL); and that's all, you can edit your aliases files if you have the right permission for write in it, my choice is /etc/mailman/aliases (/etc/mailman/) with write permission for group mailman , and woks fine. also I include a rmaliases for delete one list from de alias file, if anybody like it e-mail me please . I think that this feature should be in the release that's why I submit this msg. to this list, may be the developers are interested in things like this one. Roger

1 0

Re: [Mailman-Developers] Does anyone else see these?
by Ken Manheimer 06 Mar '99

06 Mar '99

On Fri, 5 Mar 1999 01:17:53 -0600 (CST), Christoper Lindsey wrote: > Previously, paz(a)apriori.net wrote: > > I've gotten two admin messages to mailman-owner from a mailman list I run > > on apriori.net (Hummers - a humor list). > > This isn't a Mailman issue, it's an issue with the recipients email > configuration. He's forwarding the message on from t-eaton(a)mindspring.com > to redscares(a)spamcom.net while preserving the original envelope > address. This is A Bad Thing because mail is being bounced back > to mailman-owner(a)apriori.net instead of to the person who set up the > forwarding. This is one example why one usually shouldn't preserve the > envelope sender when forwarding mail. Good call. > > [...] > Perhaps Mailman could add (yet another) header indicating the > targetted recepient to help with this type of situation? Maybe > X-Mailman-Recepient? Or it could be wrapped it into another header > like X-BeenThere... Unfortunately, this conflicts with the way mailman delivers stuff. It batches up posts to groups of people - typically five bunches. This means that deliveries aren't to any one individual recipient. Using these batches is bound to be quicker than making an individual send for each person (particularly when the MTA implements smart batching to sites, which mailman tries to support by grouping messages bound for the same domain), so it's unlikely we'd want to defeat this feature for the traceability - though there _are_ significant places where traceability would be helpful... Ken klm(a)digicool.com

1 0

Re: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url)
by Harald Meland 06 Mar '99

06 Mar '99

[Christian Tismer] > Harald Meland wrote: > > > > [Christian Tismer] > > > > > Hi Barry et al, > > > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > > > Which was fixed _days_ ago in CVS :-) > > That's great. > An average user will step into this trap, since 1.0b9 is the > current version. If one always has to check CVS, it makes > no sense to publish the zip file at all. On the contrary. Releasing betas are _part of_ testing new software. Please understand that I'm not saying that I don't appreciate you tracking down bugs in Mailman betas -- because I do, really -- but I thought it appropriate to respond and say that you could get a better fix for your problem from CVS. > I have to say: 10.b9 was published without proper testing. That depends on what you mean by "proper testing". If "proper testing" means compiling with all available of the hordes of different compilers available on lots and lots of OSes with all combinations of "configure" options, and then doing test runs of all parts of Mailman with all combinations of web servers, MTAs, Python releases, and whatnot, there is _no way_ we will get 1.0 out before the end of the century. The core developers _do_ typically check that changes they make appear to work right before they check them in -- but occasionally a bug slips through. > Anyway, the "/mailman/anything" strings are a little spread > around in the sources. In my opinion, it would be safer to > keep them in a central place (Defaults.py maybe) and just > use references. If you have a closer look at the places where /mailman/foobar are "spread around", I think you will see that they are usually fallbacks that are only used when the appropriate ways of getting at stuff doesn't work -- in particular, see the mm_cfg.py variables `DEFAULT_URL' and `PRIVATE_ARCHIVE_URL'. In the cases where /mailman/foobar are used as hardcoded values without any defaults, that is very likely a bug which should be fixed. Cheers, -- Harald

2 1