Mailman 3 August 1998 - Mailman-Developers

run_queue bug
by Scott 09 Aug '98

09 Aug '98

run_queue quits with the following traceback whenever i run it with python1.5.1 on an old ret hat linux box :( scott Traceback (innermost last): File "/home/mailman/cron/run_queue", line 31, in ? OutgoingQueue.processQueue() File "/home/mailman/Mailman/OutgoingQueue.py", line 38, in processQueue Utils.TrySMTPDelivery(recip,sender,text,full_fname) File "/home/mailman/Mailman/Utils.py", line 199, in TrySMTPDelivery con = smtplib.SmtpConnection(mm_cfg.SMTPHOST) File "/home/mailman/Mailman/smtplib.py", line 49, in __init__ self.connect() File "/home/mailman/Mailman/smtplib.py", line 54, in connect self._file = self._sock.makefile('r') socket.error: (29, 'Illegal seek')

3 7

REQUEST_URI not so reliable
by root 07 Aug '98

07 Aug '98

I just helped a friend put mailman on a linux box that was running a slightly old version of redhat (4.X??) which in turn came with apache version 1.1.3. It appears that with that version of apache, the REQUEST_URI environmental variable is not set for transactions to the localhost. this was causing the admin cgi to always return to the AdminOverview page. because there was a line in admin.py that formated the admlogin.txt template with this dict: dict = { ... "path": os.environ.get("REQUEST_URI", "/mailman/admin") ... } I upgraded his server so other things wouldn't break, but if we want to make mailman work for that (granted ancient) version of apache, the fix for this script was to replace the above with dict = {... "path": os.environ.get("REQUEST_URI", "mailman/admin/" + list_name) .... } there may be other places that use that, like private, listinfo, etc. scott

2 1

password from a tty
by Scott 07 Aug '98

07 Aug '98

here's a patch that will get passwords from a tty with echo off for mmsitepass and newlist only if it's possible, otherwise it gets the password the normal, more portable, less secure way. scott diff -c Mailman/Utils.py /home/mm/Mailman/Utils.py *** Mailman/Utils.py Mon Jul 27 18:48:31 1998 --- /home/mm/Mailman/Utils.py Mon Aug 3 23:27:55 1998 *************** *** 429,431 **** --- 429,476 ---- if raw: return template % dict return wrap(template % dict) + + + def getapwtty(prmpt="Password: "): + wrote_prmpt = 0 + try: + import termios, TERMIOS + fd = sys.stdin.fileno() + org = termios.tcgetattr(fd) + new = termios.tcgetattr(fd) + new[3] = new[3] & ~TERMIOS.ECHO + termios.tcsetattr(fd, TERMIOS.TCSANOW, new) + sys.stdout.write(prmpt) + sys.stdout.flush() + wrote_prmpt = 1 + pw = string.strip(raw_input()) + sys.stdout.write("\n") + sys.stdout.flush() + termios.tcsetattr(fd, TERMIOS.TCSAFLUSH, org) + return pw + except: + if wrote_prmpt: + prmpt = "" + pw = string.strip(raw_input(prmtp)) + return pw + + def getpw(): + while 1: + pw1 = getapwtty() + pw2 = getapwtty("Verify: ") + if pw1 == pw2: + break + else: + print "passwords didn't match, try again" + return pw1 + + + + + + + + + + + diff -c bin/mmsitepass /home/mm/bin/mmsitepass *** bin/mmsitepass Mon Jul 27 18:48:31 1998 --- /home/mm/bin/mmsitepass Mon Aug 3 23:32:11 1998 *************** *** 22,38 **** administrator's password can be used, which in turn can be used in most places that a list users password can be used.""" - import sys import paths from Mailman import MailList ! def main(argv): ! if len(sys.argv) != 2: ! print "Usage: mmsitepass password" ! raise SystemExit, 1 l = MailList.MailList() ! l.SetSiteAdminPassword(sys.argv[1]) ! if l.CheckSiteAdminPassword(sys.argv[1]): print "Password changed." raise SystemExit, 0 else: --- 22,36 ---- administrator's password can be used, which in turn can be used in most places that a list users password can be used.""" import paths from Mailman import MailList + from Mailman.Utils import getpw ! def main(): ! print "enter a site password for mailman" ! pw = getpw() l = MailList.MailList() ! if l.CheckSiteAdminPassword(pw): print "Password changed." raise SystemExit, 0 else: *************** *** 40,43 **** raise SystemExit, 1 if __name__ == "__main__": ! main(sys.argv) --- 38,48 ---- raise SystemExit, 1 if __name__ == "__main__": ! main() ! ! ! ! ! ! ! diff -c bin/newlist /home/mm/bin/newlist *** bin/newlist Mon Jul 27 18:48:31 1998 --- /home/mm/bin/newlist Mon Aug 3 23:33:22 1998 *************** *** 71,77 **** if len(argv) > 3: list_pw = argv[3] else: ! list_pw = raw_input("Enter the initial list password: ") newlist = MailList.MailList() pw = crypt(list_pw , Utils.GetRandomSeed()) --- 71,78 ---- if len(argv) > 3: list_pw = argv[3] else: ! print "Please Enter the initial list password." ! list_pw = Utils.getpw() newlist = MailList.MailList() pw = crypt(list_pw , Utils.GetRandomSeed())

3 4

Double-sends
by Corbett J. Klempay 05 Aug '98

05 Aug '98

Heheh......now that Ken finished fixing the list, I forget...did anyone ever find out what was causing the multiple-send problem? I think I just experienced a double-send on my first 'welcome back to a working list server' message to one of my lists.... ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Money is the root of all good." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 -------------------------------------------------------------------------------

1 0

Odd b5 behavior
by Corbett J. Klempay 05 Aug '98

05 Aug '98

I've been having this problem for a few days, and I am just trying to find out if anyone else here is experiencing a similar phenomenon (so that maybe I'll get lucky and talk to you and figure out what the story is): - 1.0b5 + sendmail 8.9.1 - RH Linux 5.1 (if you need more info, it's also http://www2.acm.jhu.edu -- there's lots of stuff there) There was some weirdness with permissions being set wrong with Linux + b5, but Barry issued a patch in about 2 seconds flat that cleared that one up. The current problem is that I have several lists set up, but if you send mail to them (like test(a)acm.jhu.edu), your mail is swallowed into a bottomless pit...it never sees the light of day again. If you look at /var/log/maillog, it claims the mail has been sent. Users have that they did get their monthly password reminder from Mailman itself, however. I don't think this is really something misconfigured with sendmail on my end; this same setup was chugging right along with 1.0b4 until I tried to switch. ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Money is the root of all good." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 -------------------------------------------------------------------------------

2 3

Experimental remote CVS repository
by Barry A. Warsaw 05 Aug '98

05 Aug '98

Hi all, I think I finally have a publically accessible read-only remote CVS repository available to y'all. I say "experimental" because I'm not 100% sure it's working, so please try it out. Note that this will keep you on the absolute bleeding edge because syncs are done to the repository on every check-in. Also, by tomorrow or so I hope we'll have a Mailman mailing list you can join to get CVS checkin messages. That's not quite running yet. I may also try to get CVSweb access and remote rsync access if time allows and there is enough demand (and I can polish off my very dusty Perl manual :-). For now, here's what you need to do to check out a copy of the Mailman source code: % cvs -d :pserver:anoncvs@cvs.python.org:/projects/cvsroot login [password is `anoncvs'] % cvs -d :pserver:anoncvs@cvs.python.org:/projects/cvsroot co mailman After that, you don't need to specify a CVSROOT while inside the mailman directory. Please let me know how it goes. -Barry

1 0

Sendmail.cf wizard question - virtual-hosting
by Ken Manheimer 03 Aug '98

03 Aug '98

I have a question for any sendmail.cf wizards out there - a hack to a recent cf ruleset (mine is from 8.9.0) to circumvent what i consider a bug, or at least a misfeature, that interferes with using sendmail for "virtual hosting". The problem was that no matter what i did (building the cf with masquerading, virtual user, whatever it was), the "to:" header of messages posted to a maillist was always transformed to the primary address of the host where the maillist was situated, even when the original message was addressed to one of the "virtual" host addrs. I eventually poked and prodded in the rulesets (shudder), and discovered that commenting out one rule, which is supposed to use the name server to canonicalize an address, prevents that transformation from happening. (It's part of ruleset 96, which was apparently is "the bottom half of ruleset 3" - boy, i *do not like* touching cf ruleset code!) I've been running this change for a few weeks on my workstation and on python.org, and it doesn't seem to be causing any problems. Even better (:-), it does seem to prevent the unwanted transformation of the original "to:" addresses. However, i don't _really_ know that my change won't disrupt something that isn't exercised on my machines. So i'm hoping that informed sendmail folk out there might be able to do a sanity check on this change. I'm including, below, an artifical diff of the cf file before and after, to show the specific difference, for a sendmail 8.9.0 cf file. Please let me know what you think, if you have some clear knowledge of this stuff! Ken Manheimer klm(a)python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # <http://www.python.org/psa/>. # *** sendmail.cf 1998/08/03 21:27:06 1.6 --- sendmail.cf 1998/08/03 21:27:17 *************** *** 516,522 **** R$* < @ $+ . . UUCP . > $* $@ $1 < @ $2 . > $3 # pass to name server to make hostname canonical ! R$* < @ $* $~P > $* $: $1 < @ $[ $2 $3 $] > $4 # local host aliases and pseudo-domains are always canonical R$* < @ $=w > $* $: $1 < @ $2 . > $3 --- 516,524 ---- R$* < @ $+ . . UUCP . > $* $@ $1 < @ $2 . > $3 # pass to name server to make hostname canonical ! # klm - looks like this converts to primary canonical, which transforms ! # e.g. a virtual-hosted "to:" address when we don't want it to be... ! #R$* < @ $* $~P > $* $: $1 < @ $[ $2 $3 $] > $4 # local host aliases and pseudo-domains are always canonical R$* < @ $=w > $* $: $1 < @ $2 . > $3

2 1

confirmation duplicates and stuff
by root 03 Aug '98

03 Aug '98

there's a quick and easy fix to the confirmation duplicates bug. in the file MailCommandHandler.py, at the end of the definition of the ProcessConfirmCommand method, add "self.__NoMailCmdResponse = 1". This will cause the confirmation handler to either send out only the welcome to the list message, or only the error message if there is one. I also noticed that listed under Bugs at www.list.org was the fact that confirmations where always called, even when the subscribing address has to be approved administratively. I'd like to point out that the confirmatin step does not take place when a memeber is subscribed via the admin/membership management cgi. However, I believe it does when someone subscribes to a closed list via mail. I thought that we had all pretty much stated that we always wanted confirmations to happen, but i guess not, seeing how this is listed as a bug. i can see how it could be inconvenient. The question is: what do we do about this? do we: 1) drop the confirmation step completely when a list has closed subscriptions? or 2) make the confirmation step an option only for closed subscriptions? #1 is FAR simpler to implement because it doesn't involve any changes to the cgi admin interface. #2 would require a good bit of changes to the interface: either only presenting the confirmation as an option when the list is closed, or allowing it as an option and presenting an error if anyone chooses not have confirmations for an open list. thoughts? scott

1 0

Re: [Mailman-Users] Re: [Mailman-Developers] Odd b5 behavior
by Janne Sinkkonen 03 Aug '98

03 Aug '98

"Corbett J. Klempay" <cklempay(a)acm.jhu.edu> writes: > How do I check? Is this what I see when I do mailq? If that's it, it's > empty. Ok. > > When I had a broken sendmail, most of the messages still went through. > > I don't know that my sendmail is really broken..it works with b4, and all > of our non-mailman mail is running smoothly. At least the MIME bug is not your problem, since it doesn't exist in 8.9.1. (BTW, practically all of our non-mailman mail ran smoothly as well, so that's not an indicator of anything.) To see whether the mail really goes to the MTA, change the logging level of sendmail high enough (if it isn't). That's just the 'O' thing in sendmail.cf - it is easy to edit manually. -- Janne

1 0

Re: [Mailman-Developers] Odd b5 behavior
by Janne Sinkkonen 03 Aug '98

03 Aug '98

Ken Manheimer <klm(a)cnri.reston.va.us> writes: > There is a known bug in some recent versions of sendmail (8.8.x for some > x, and 8.9.0) such that the sendmail will core dump when attempting to > deliver mailman's (or any 8-bit encoded) Mime-format digests in certain > (somewhat uncommon) circumstances. The question then is, were the > messages that never appeared in the users mailbox Mime digests? And if > not, could you construct a repeatable test that at least reduces the > likelihood that the problem is on the receiving ends? For that matter, > might you happen to be running sendmail 8.8.x or 8.9.0? Your sendmail > may be getting so far as negotiating the delivery and then failing > partway through... He should check his mail spool. If sendmail dies, it leaves the undelivered message to the spool, which then starts to gradually grow. When I had a broken sendmail, most of the messages still went through. -- Janne

1 0