Mailman 3 July 2000 - Mailman-Developers

latest CVS error!
by Mentor Cana 22 Jul '00

22 Jul '00

Here is an error from my apache error file, generated while trying to access a list from the list of list in the main mailman page. The web browser (Netscape) gives: "The server made a boo boo." ---- [Fri Jul 21 23:13:19 2000] [error] [client 12.78.108.101] malformed header from script. Bad header=<HTML>: /opt/home/mailman/cgi-bin/listinfo ---- later, Mentor

2 1

Re: [Mailman-Developers] logging patch for SMTPDirect.py
by Dan Mick 22 Jul '00

22 Jul '00

> Since SMTPDirect.py already writes to logs/smtp, I didn't think it was > necessary to also write to logs/post. I gather from your patch and > Dan's bug report that you think it should do both? Or should it write > only to logs/post? The one in 'post' was the one I was interested in; the "from who, size who" form allows me to more-easily track messages through various queues, assess delivery delays, etc. It just looked different from the other delivery methods, and it was a new change to me when I started using SMTPDirect (2.0, probably). > > As for the success/failure bit, you're right, the failure code doesn't > make much sense here. What probably does make sense is for on > failure, to print the number of failed recipients. > > So along those lines, here's what I intend to check in. > > -Barry > > -------------------- snip snip -------------------- > Index: SMTPDirect.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/SMTPDirect.py,v > retrieving revision 1.11 > diff -u -r1.11 SMTPDirect.py > --- SMTPDirect.py 2000/06/03 04:59:45 1.11 > +++ SMTPDirect.py 2000/07/22 02:36:53 > @@ -75,9 +75,19 @@ > finally: > t1 = time.time() > mlist.Lock() > - # Process any failed deliveries. > + # Log the successful post > syslog('smtp', 'smtp for %d recips, completed in %.3f seconds' % > (len(recips), (t1-t0))) > + > + if refused: > + syslog('post', 'post to %s from %s, size=%d, %d failures' % > + (mlist.internal_name(), msg.GetSender(), len(msg.body), > + len(refused))) > + else: > + syslog('post', 'post to %s from %s, size=%d, success' % > + (mlist.internal_name(), msg.GetSender(), len(msg.body))) > + > + # Process any failed deliveries. > tempfailures = [] > for recip, (code, smtpmsg) in refused.items(): > # DRUMS is an internet draft, but it says: > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://www.python.org/mailman/listinfo/mailman-developers

1 0

logging patch for SMTPDirect.py
by Ron Jarrell 22 Jul '00

22 Jul '00

I posted patch 100861 to sourceforge; this addresses bug 108167, which was the complaint that SMTPDirect.py didn't log posts to the post log like Sendmail.py did. Since the environment is a bit different (SMTPDirect can tell which user had what error, Sendmail just kind of worked or went Blooie) the "failure code" didn't seem to make sense; so I just had it log a successful attempt at doing smtp dialog, and ignore things that would just get the message thrown back into the queue; they'll likely show up in other logs anyway.

2 1

Cookie stuff done
by bwarsaw＠beopen.com 22 Jul '00

22 Jul '00

Okay, I've gone ahead and checked in all the cookie changes. Please check out the current CVS tree and let me know how it goes. If I don't hear any major negatives I'll spin beta5 tomorrow. Cheers, -Barry

3 5

Re: [Mailman-Developers] config_list bug with subscribe_policy
by Hrvoje Niksic 21 Jul '00

21 Jul '00

Has anyone looked at this? It doesn't matter to me personally that much since I've located and worked around the problem, but it might be confusing for others. Hrvoje Niksic <hniksic(a)iskon.hr> writes: > The subscribe_policy parameter is a bit specific in that it can be 0, > 1, 2, or 3, except that 0 can be turned off on a per-site basis (which > is done by default, at least under Debian). > > The web GUI makes sure that the RadioButtonArray gets set up with the > current setting of subscribe_policy correctly laid out, which depends > on whether the site-wide option is turned on or off. > > However, the config_list utility does not seem to understand the > convention, and prints the following: > > # legal values are: > # 0 = "confirm" > # 1 = "require approval" > # 2 = "confirm+approval" > subscribe_policy = 1 > > The number is correct, but the comment is not; the list in question > does not require approval -- it merely asks for confirmation. > > config_list should probably have a special-case for subscribe_policy, > as the graphical tools do. Otherwise the comment is very misleading > for people who hope to use config_list to import lists to Mailman. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://www.python.org/mailman/listinfo/mailman-developers

1 0

Re: [Mailman-Developers] Serious mailman locking bug
by Hrvoje Niksic 21 Jul '00

21 Jul '00

bwarsaw(a)beopen.com (Barry A. Warsaw) writes: > Here's a moderately tested patch that should fix the problem. Thanks. For now I've worked around the bug in my application by simply not locking the list. This is OK for my purposes because I'm not making any changes to the list -- merely presenting a summary of lists, their descriptions and subscriber counts, and stuff like that.

1 0

Re: [Mailman-Users] Duplicate Messages
by John MacKenzie 21 Jul '00

21 Jul '00

I never experienced this issue with 1.1 , However I am currently experiencing it with 2.0beta4. I have confirmed that duplicate messages were sent (4), and only one was authorised. Anyone got any ideas ? - John On Fri, 21 Jul 2000, jbfisher wrote: > I'm still running Mailman 1.1 and run two read-only lists (1,000 and > 2,500). Users are complaining (and I confirmed) that they are receiving > duplicate messages. The only thing I can think of is that a few months ago > we had to reinstall our entire server (redhat 6.1), but before we did so, > we tarred up everything, which should have retained permissions, etc. We've > looked and can't find anything that might cause this to happen. Everything > else seems to work OK. Any ideas of where to look? (I'd rather wait till > 2.0 is released than go to betas). > > Thanks > JFisher > > > ------------------------------------------------------ > Mailman-Users maillist - Mailman-Users(a)python.org > http://www.python.org/mailman/listinfo/mailman-users -- John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie ___________________________________________________________________ Stay in touch your local area through Local Ireland http://chat.local.ie/chat/index.html ___________________________________________________________________ local ireland | dublin | new york | http://www.local.ie t: +353 1 676 8996 f: +353 1 283 9988

2 2

Serious mailman locking bug
by Hrvoje Niksic 21 Jul '00

21 Jul '00

This seems to be new in beta4 (as opposed to beta2, which I used previously). When a mailing list object fails to be created, its lock persists. So the code that attempts to do something like this fails: try: listobj = MailList.MailList(name) try: # do some stuff involving listobj finally: # Unlock listobj, whatever happens listobj.Unlock() except Errors.MMListError: # MailList constructor failed because there is no list with # specified name. There should be no lock at this point. pass Now, if the MailList constructor fails, no lock should be created. But apparently a lock does get created and since there's no way to unlock it from Python (I can't call Unlock() because I didn't get a MailList object in the first place), the lock persists and blocks the next invocation of the same code. You can try the same interactively: >>> x=MailList.MailList('no-such-list') Traceback (innermost last): File "<stdin>", line 1, in ? File "/usr/lib/mailman/Mailman/MailList.py", line 75, in __init__ self.Lock() File "/usr/lib/mailman/Mailman/MailList.py", line 1343, in Lock self.Load() File "/usr/lib/mailman/Mailman/MailList.py", line 892, in Load raise Errors.MMUnknownListError Mailman.Errors.MMUnknownListError OK, the creation of the list object failed, and we don't have an object to call Unlock() on. However, /var/lib/mailman/locks/no-such-list* locks do exist, and because of that: >>> y=MailList.MailList('no-such-list') ... constructor hangs, waiting for the lock to be obtained ... This breaks my application that tries to check things about lists that may or may not exist. I think this worked OK in 2.0beta2. I'd very much appreciate any help.

2 1

Cookies and Authentication redux
by bwarsaw＠beopen.com 20 Jul '00

20 Jul '00

After private discussions with several people, I am being convinced that Mailman should change the way it does cookies. Currently, the cookie has an `expires' header which is supposed to tell your browser to persist the cookie for some amount of time, possibly across browser sessions. This has several problems: 1) It's a security risk. If you're using a shared browser, your authenticated cookie can be hijacked by the next user. 2) It's prone to clock and timezone problems. This is the cause of at least one user's recent problems; maybe more people are suffering the same problem but don't know it. The solution is two-fold I believe. First, Mailman should not set the `expires' header on the cookie at all. RFC 2109 says that browsers should then expire the cookie at the end of the session. Second, we should provide a `Logout' button on the admin pages which will set `max-age=0' to tell the browsers (according to RFC 2109) to end the session. This comes at a slight cost in convenience, but I think it's worth it. I could conceivably keep ADMIN_COOKIE_LIFE, default it to zero to mean session-cookies-only, and let the site admin set it to a non-zero value to indicate persistent cookie should be used. On a related note, I think there may also be problems with some of the generated pages getting cached improperly, so I further propose to include the header 'Cache-control: no-cache' on all CGI pages. Comments? -Barry

2 2

Re: [Mailman-Developers] cookies
by Hrvoje Niksic 20 Jul '00

20 Jul '00

bwarsaw(a)beopen.com (Barry A. Warsaw) writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > Hrvoje> Oh, I see. Is there maybe a patch that fixes the "Error > Hrvoje> decoding ..." problem for us who run the released beta? > > Not at the moment, because I'm not sure it's been fixed. Thanks. I guess I'll stay tuned.

1 0