Mailman 3 April 2003 - Mailman-coders

[ mailman-Bugs-728122 ] Unsub instructions difficult to find
by SourceForge.net 26 Apr '03

26 Apr '03

Bugs item #728122, was opened at 2003-04-26 18:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=728122&group_i… Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony E. Greene (tonygreene) Assigned to: Nobody/Anonymous (nobody) Summary: Unsub instructions difficult to find Initial Comment: The default Mailman info page for the list could stand some improvements. I've noticed it over and over and finally decided to contribute to a solution instead of griping about the problem. ;-) I recommend these two changes: 1. Move the administrative "$listname Subscribers" section to the bottom of the page. Admins will know where to look and subscribers should not have to read through admin info to get to the section that concerns them (changing subscription options). 2. Add a standard colored section header titled "Change Options or Unsubscribe". The original format for this section did not clearly indicate that this is the section for unsubscribing. Users have to read the fine print. Reading the fine print is fine for detailed instructions, but the users should have some idea that the unsub instructions are there just by looking at the section header. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=728122&group_i…

1 0

[ mailman-Bugs-717110 ] mail commands
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #717110, was opened at 2003-04-07 16:23 Message generated for change (Comment added) made by wyardley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i… Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: Invalid Priority: 5 Submitted By: Will Yardley (wyardley) Assigned to: Nobody/Anonymous (nobody) Summary: mail commands Initial Comment: when approving a message via email, if you type: Approved: passwrd in the headers of a response to the confirmation message, when the actual password is 'password', the message you're trying to approve is discarded; I think that no action (and an "incorrect password" error message in response) would be more appropriate. Also, as I've mentioned before, it would be very nice if the exact action being performed were listed, rather than the generic "confirmation succeeded" message. ---------------------------------------------------------------------- >Comment By: Will Yardley (wyardley) Date: 2003-04-24 11:22 Message: Logged In: YES user_id=751970 FWIW, in my experience, responding to the confirmation message itself with the proper Approved header works just fine. It's only when the password is incorrect that the message is deleted. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-24 11:16 Message: Logged In: YES user_id=12800 Ah, you're right. Re-opening. Either the message in the confirmation is broken, or the email cmd handler is broken. I won't decide that yet. :) ---------------------------------------------------------------------- Comment By: Will Yardley (wyardley) Date: 2003-04-24 11:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Will Yardley (wyardley) Date: 2003-04-24 11:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-19 12:27 Message: Logged In: YES user_id=12800 After re-reading this bug report, I believe Mailman is working as expected. If you read the body of the confirmation message, you'll see that replying to it keeping the subject intact always discards the original message. The way to approve it is to resend the first message in the digest, which is the original held message. Add Approved: password header to the resend, and then reply to the confirmation message to get rid of the old hold. I admit this isn't the most convenient way to do it, but for now that's it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i…

1 0

[ mailman-Bugs-717110 ] mail commands
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #717110, was opened at 2003-04-07 19:23 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i… Category: Web/CGI Group: 2.1 (stable) >Status: Open Resolution: Invalid Priority: 5 Submitted By: Will Yardley (wyardley) Assigned to: Nobody/Anonymous (nobody) Summary: mail commands Initial Comment: when approving a message via email, if you type: Approved: passwrd in the headers of a response to the confirmation message, when the actual password is 'password', the message you're trying to approve is discarded; I think that no action (and an "incorrect password" error message in response) would be more appropriate. Also, as I've mentioned before, it would be very nice if the exact action being performed were listed, rather than the generic "confirmation succeeded" message. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-24 14:16 Message: Logged In: YES user_id=12800 Ah, you're right. Re-opening. Either the message in the confirmation is broken, or the email cmd handler is broken. I won't decide that yet. :) ---------------------------------------------------------------------- Comment By: Will Yardley (wyardley) Date: 2003-04-24 14:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Will Yardley (wyardley) Date: 2003-04-24 14:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-19 15:27 Message: Logged In: YES user_id=12800 After re-reading this bug report, I believe Mailman is working as expected. If you read the body of the confirmation message, you'll see that replying to it keeping the subject intact always discards the original message. The way to approve it is to resend the first message in the digest, which is the original held message. Add Approved: password header to the resend, and then reply to the confirmation message to get rid of the old hold. I admit this isn't the most convenient way to do it, but for now that's it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i…

1 0

[ mailman-Bugs-717110 ] mail commands
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #717110, was opened at 2003-04-07 16:23 Message generated for change (Comment added) made by wyardley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i… Category: Web/CGI Group: 2.1 (stable) Status: Closed Resolution: Invalid Priority: 5 Submitted By: Will Yardley (wyardley) Assigned to: Nobody/Anonymous (nobody) Summary: mail commands Initial Comment: when approving a message via email, if you type: Approved: passwrd in the headers of a response to the confirmation message, when the actual password is 'password', the message you're trying to approve is discarded; I think that no action (and an "incorrect password" error message in response) would be more appropriate. Also, as I've mentioned before, it would be very nice if the exact action being performed were listed, rather than the generic "confirmation succeeded" message. ---------------------------------------------------------------------- >Comment By: Will Yardley (wyardley) Date: 2003-04-24 11:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Will Yardley (wyardley) Date: 2003-04-24 11:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-19 12:27 Message: Logged In: YES user_id=12800 After re-reading this bug report, I believe Mailman is working as expected. If you read the body of the confirmation message, you'll see that replying to it keeping the subject intact always discards the original message. The way to approve it is to resend the first message in the digest, which is the original held message. Add Approved: password header to the resend, and then reply to the confirmation message to get rid of the old hold. I admit this isn't the most convenient way to do it, but for now that's it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i…

1 0

[ mailman-Bugs-717110 ] mail commands
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #717110, was opened at 2003-04-07 16:23 Message generated for change (Comment added) made by wyardley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i… Category: Web/CGI Group: 2.1 (stable) Status: Closed Resolution: Invalid Priority: 5 Submitted By: Will Yardley (wyardley) Assigned to: Nobody/Anonymous (nobody) Summary: mail commands Initial Comment: when approving a message via email, if you type: Approved: passwrd in the headers of a response to the confirmation message, when the actual password is 'password', the message you're trying to approve is discarded; I think that no action (and an "incorrect password" error message in response) would be more appropriate. Also, as I've mentioned before, it would be very nice if the exact action being performed were listed, rather than the generic "confirmation succeeded" message. ---------------------------------------------------------------------- >Comment By: Will Yardley (wyardley) Date: 2003-04-24 11:03 Message: Logged In: YES user_id=751970 Perhaps I'm misreading the message? The message I see says: "If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply." This seems to say that the *confirmation* message, not the original message should have the 'Approved:' header. Am I reading something wrong here? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-19 12:27 Message: Logged In: YES user_id=12800 After re-reading this bug report, I believe Mailman is working as expected. If you read the body of the confirmation message, you'll see that replying to it keeping the subject intact always discards the original message. The way to approve it is to resend the first message in the digest, which is the original held message. Add Approved: password header to the resend, and then reply to the confirmation message to get rid of the old hold. I admit this isn't the most convenient way to do it, but for now that's it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=717110&group_i…

1 0

[ mailman-Bugs-723123 ] Runs out of memory on larger (5M) messages.
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #723123, was opened at 2003-04-17 06:20 Message generated for change (Comment added) made by xerouz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=723123&group_i… Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 9 Submitted By: Steve Mertz (xerouz) Assigned to: Nobody/Anonymous (nobody) Summary: Runs out of memory on larger (5M) messages. Initial Comment: When trying to send an email with a 5M attachment, Mailman seems to run out of memory. On the console I get: marcos:mailman {106} Traceback (most recent call last): File "/usr/local/mailman/bin/qrunner", line 270, in ? main() File "/usr/local/mailman/bin/qrunner", line 230, in main qrunner.run() File "/usr/local/mailman/Mailman/Queue/Runner.py", line 59, in run filecnt = self._oneloop() File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._shunt.enqueue(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 91, in enqueue msgsave = cPickle.dumps(_msg, 1) MemoryError: out of memory The system is: OpenBSD 3.1, with 512M ram. Mailman version 2.1.1 It would be nice to be able to have large attachments as I want to use this for my company's support email which quite often has larger than 10M files attached. Thanks, -- Steve ---------------------------------------------------------------------- >Comment By: Steve Mertz (xerouz) Date: 2003-04-24 08:08 Message: Logged In: YES user_id=61424 Now, I'm getting errors in of a different kind: Apr 24 10:03:18 2003 (22458) Uncaught runner exception: out of memory Apr 24 10:03:18 2003 (22458) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 71, in process g.flatten(msg, unixfrom=1) File "/usr/local/mailman/pythonlib/email/Generator.py", line 100, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 128, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 154, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 267, in _handle_multipart print >> self._fp, '\n--' + boundary + '--', MemoryError: out of memory Apr 24 10:03:18 2003 (22458) SHUNTING: 1051196594.0123+3c7e0d1a0cd1e29359dea6cc2bb51307e06ad0df ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=723123&group_i…

1 0

[ mailman-Bugs-726736 ] qrunner hung by spam
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #726736, was opened at 2003-04-24 08:01 Message generated for change (Settings changed) made by greglindahl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726736&group_i… Category: mail delivery Group: 2.0.x Status: Open Resolution: None >Priority: 8 Submitted By: Greg Lindahl (greglindahl) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner hung by spam Initial Comment: I realized no mail had gone out for 6 days, and saw that qrunner was barfing on SOMETHING. This is with Mailman 2.0.6. Even though I'm behind the times, I'd bet this bug could be in 2.1.X -- I just don't know enough Python to see what's going on. I blew away a bunch of files in my qfiles directory; I didn't save the bad message. Apr 24 00:39:01 2003 qrunner(2397): Traceback (innermost last): Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/cron/qrunner", line 282, in ? Apr 24 00:39:01 2003 qrunner(2397): kids = main(lock) Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/cron/qrunner", line 252, in main Apr 24 00:39:01 2003 qrunner(2397): keepqueued = dispose_message(mlist, msg, msgdata) Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/cron/qrunner", line 121, in dispose_message Apr 24 00:39:01 2003 qrunner(2397): if BouncerAPI.ScanMessages(mlist, mimemsg): Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 59, in ScanMessages Apr 24 00:39:01 2003 qrunner(2397): addrs = func(msg) Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/Mailman/Bouncers/Postfix.py", line 39, in process Apr 24 00:39:01 2003 qrunner(2397): more = mfile.next() Apr 24 00:39:01 2003 qrunner(2397): File "/usr/lib/python1.5/multifile.py", line 121, in next Apr 24 00:39:01 2003 qrunner(2397): while self.readline(): pass Apr 24 00:39:01 2003 qrunner(2397): File "/usr/lib/python1.5/multifile.py", line 93, in readline Apr 24 00:39:01 2003 qrunner(2397): if marker == self.section_divider(sep): Apr 24 00:39:01 2003 qrunner(2397): File "/usr/lib/python1.5/multifile.py", line 157, in section_divider Apr 24 00:39:01 2003 qrunner(2397): return "--" + str Apr 24 00:39:01 2003 qrunner(2397): TypeError : illegal argument type for built-in operation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726736&group_i…

1 0

[ mailman-Bugs-726736 ] qrunner hung by spam
by SourceForge.net 24 Apr '03

24 Apr '03

Bugs item #726736, was opened at 2003-04-24 08:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726736&group_i… Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Greg Lindahl (greglindahl) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner hung by spam Initial Comment: I realized no mail had gone out for 6 days, and saw that qrunner was barfing on SOMETHING. This is with Mailman 2.0.6. Even though I'm behind the times, I'd bet this bug could be in 2.1.X -- I just don't know enough Python to see what's going on. I blew away a bunch of files in my qfiles directory; I didn't save the bad message. Apr 24 00:39:01 2003 qrunner(2397): Traceback (innermost last): Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/cron/qrunner", line 282, in ? Apr 24 00:39:01 2003 qrunner(2397): kids = main(lock) Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/cron/qrunner", line 252, in main Apr 24 00:39:01 2003 qrunner(2397): keepqueued = dispose_message(mlist, msg, msgdata) Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/cron/qrunner", line 121, in dispose_message Apr 24 00:39:01 2003 qrunner(2397): if BouncerAPI.ScanMessages(mlist, mimemsg): Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 59, in ScanMessages Apr 24 00:39:01 2003 qrunner(2397): addrs = func(msg) Apr 24 00:39:01 2003 qrunner(2397): File "/home/mailman/Mailman/Bouncers/Postfix.py", line 39, in process Apr 24 00:39:01 2003 qrunner(2397): more = mfile.next() Apr 24 00:39:01 2003 qrunner(2397): File "/usr/lib/python1.5/multifile.py", line 121, in next Apr 24 00:39:01 2003 qrunner(2397): while self.readline(): pass Apr 24 00:39:01 2003 qrunner(2397): File "/usr/lib/python1.5/multifile.py", line 93, in readline Apr 24 00:39:01 2003 qrunner(2397): if marker == self.section_divider(sep): Apr 24 00:39:01 2003 qrunner(2397): File "/usr/lib/python1.5/multifile.py", line 157, in section_divider Apr 24 00:39:01 2003 qrunner(2397): return "--" + str Apr 24 00:39:01 2003 qrunner(2397): TypeError : illegal argument type for built-in operation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726736&group_i…

1 0

[ mailman-Bugs-726415 ] incorrect pidfile name in init.d script
by SourceForge.net 23 Apr '03

23 Apr '03

Bugs item #726415, was opened at 2003-04-23 14:14 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726415&group_i… Category: configuring/installing Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect pidfile name in init.d script Initial Comment: the init.d script (misc/mailmain.in) has the following as the pidfile # pidfile: @prefix@/data/qrunner.pid but Defaults.py defines it as: PIDFILE = os.path.join(DATA_DIR, 'master-qrunner.pid') the name in the init.d scripts should be changed to master-qrunner.pid ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726415&group_i…

1 0

[ mailman-Bugs-726554 ] Mailman and SMTPDirect stop talking, mailing totally fails
by SourceForge.net 23 Apr '03

23 Apr '03

Bugs item #726554, was opened at 2003-04-23 18:20 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726554&group_i… Category: mail delivery Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Cabel Sasser (cabelsa) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Mailman and SMTPDirect stop talking, mailing totally fails Initial Comment: I'm using Mailman 2.1 and Mac OS X 10.2.5. When I send my message (a personalized, announce-only list), after the first 150 or so deliveries (out of 19640), Mailman suddenly seems to stop communicating to the SMTP server, and all remaining recipients fail. There are no real good clues in /var/log/mail.log as to why SMTP is getting grumpy. These are the interesting parts of mail.log that appear around the time of failure -- everything else looks fine. -- /var/log/mail.log: Apr 23 15:06:39 newposh sendmail[5928]: h3NM4o0o005928: SYSERR(root): Cannot create ./dfh3NM4o0o005928: File exists [..] Apr 23 15:06:40 newposh sendmail[6251]: h3NM4o0j005928: to=<jamie2(a)sbcglobal.net>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=85368, relay=vm4-ext.prodigy.net. [207.115.63.115], dsn=5.3.0, stat=User unknown Apr 23 15:06:40 newposh sendmail[6251]: h3NM4o0j005928: h3NM6ewS006251: DSN: User unknown. -- logs/smtp: Apr 23 15:08:25 2003 (663) All recipients refused: please run connect() first Apr 23 15:08:25 2003 (663) All recipients refused: please run connect() first Apr 23 15:08:25 2003 (663) All recipients refused: please run connect() first Apr 23 15:08:25 2003 (663) All recipients refused: please run connect() first [..etc..] -- logs/error: Apr 23 15:08:25 2003 (663) Uncaught runner exception: please run connect() first Apr 23 15:08:25 2003 (663) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 150, in process conn.quit() File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 80, in quit self.__conn.quit() File "/BinaryCache/python/python-3.root~377/usr/lib/ python2.2/smtplib.py", line 671, in quit self.docmd("quit") File "/BinaryCache/python/python-3.root~377/usr/lib/ python2.2/smtplib.py", line 352, in docmd self.putcmd(cmd,args) File "/BinaryCache/python/python-3.root~377/usr/lib/ python2.2/smtplib.py", line 308, in putcmd self.send(str) File "/BinaryCache/python/python-3.root~377/usr/lib/ python2.2/smtplib.py", line 300, in send raise SMTPServerDisconnected('please run connect() first') SMTPServerDisconnected: please run connect() first Apr 23 15:08:25 2003 (663) SHUNTING: 1051135414.712172+5cc02db8df9b882e2bc690b9706a9f7bf56 f273a -- Please let me know if there's anything I can do to help you find the cause of this problem. Thanks! ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-23 23:27 Message: Logged In: YES user_id=12800 I believe I fixed this for Mailman 2.1.2. If after that's release (RSN, I promise!) if this bug recurs, please reopen this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=726554&group_i…

1 0