Hi.
I have just gone live with my email list, and this is the first time
anyone has reported a problem to me, so here it is for your comments.
(First let me remind you that I do *not* have access to the Mailman
installation, and I do *NOT* speak Python - apart from the "Monty"
version!)....
I tried to subscribe using the 3-c.coop address, but it wouldn't
let me say I didn't want to receive the emails, so I clicked
cancel. Then I got this:"Bug in Mailman version 2.1.5p1
We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a
copy of this page to the webmaster for this site with a description
of what happened. Thanks! Traceback:Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/scripts/driver", line
87, in run_main main() File "/usr/local/cpanel/3rdparty/mailman/Mailman/Cgi/confirm.py",
line 114, in main subscription_cancel(mlist, doc, cookie) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Cgi/confirm.py",
line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/usr/local/cpanel/3rdparty/mailman/Mailman/Pending.py",
line 141, in pend_confirm assert self.Locked() AssertionError"Python information:
Variable Value sys.version 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2
20030222 (Red Hat Linux 3.2.2-4)] sys.executable /usr/bin/python2 sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2Environment variables:
Variable Value PATH_INFO /mactalk_mactalk.org.uk HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/ html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 CONTENT_TYPE application/x-www-form-urlencoded HTTP_REFERER http://mail.mactalk.org.uk/mailman/confirm/ mactalk_mactalk.org.uk/569f32ae2206d89dc8eae730945a5241f2134ad6 SERVER_SOFTWARE Apache PYTHONPATH /usr/local/cpanel/3rdparty/mailman SCRIPT_FILENAME /usr/local/cpanel/3rdparty/mailman/cgi-bin/confirm SERVER_ADMIN webmaster@securesitex.com SCRIPT_NAME /mailman/confirm REQUEST_METHOD POST HTTP_HOST mail.mactalk.org.uk HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /mailman/confirm/mactalk_mactalk.org.uk CONTENT_LENGTH 128 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 HTTP_CONNECTION keep-alive SERVER_NAME www.securesitex.com REMOTE_PORT 50650 REMOTE_ADDR 213.55.30.31 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 PATH_TRANSLATED /home/securesi/public_html/mactalk_mactalk.org.uk SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip,deflate SERVER_ADDR 69.56.243.90 DOCUMENT_ROOT /home/securesi/public_html
What's all that about then?! TIA Pete
PeteBell wrote:
I have just gone live with my email list, and this is the first time
anyone has reported a problem to me, so here it is for your comments.
(First let me remind you that I do *not* have access to the Mailman
installation, and I do *NOT* speak Python - apart from the "Monty"
version!)....I tried to subscribe using the 3-c.coop address, but it wouldn't
let me say I didn't want to receive the emails, so I clicked
cancel. Then I got this:"Bug in Mailman version 2.1.5p1
We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a
copy of this page to the webmaster for this site with a description
of what happened. Thanks! Traceback:Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/scripts/driver", line
87, in run_main main() File "/usr/local/cpanel/3rdparty/mailman/Mailman/Cgi/confirm.py",
line 114, in main subscription_cancel(mlist, doc, cookie) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Cgi/confirm.py",
line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/usr/local/cpanel/3rdparty/mailman/Mailman/Pending.py",
line 141, in pend_confirm assert self.Locked() AssertionError"
First, see FAQ article 6.11
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
That said, this is not a cPanel problem per se. It has been fixed in Mailman 2.1.6.
As far as your user's not wanting to subscribe if she/he can't supress e-mail, the user needs to subscribe first and then disable mail delivery on his/her options page. See http://www.list.org/mailman-member/node20.html (or the whole manual at http://www.list.org/mailman-member/mailman-member.html)
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi
What exactly are the possible problems when a batch of around 5 or 6
list emails don't get sent out, but they DO appear in the archives?
And is there any reason why emails to a mailman list from Gmail
accounts should not get sent out?
Cheers Pete Bell, UK
On 6/4/05 4:51 AM, "PeteBell" <macbantam@ntlworld.com> wrote:
And is there any reason why emails to a mailman list from Gmail accounts should not get sent out?
Well, Gmail inserts the very very long--and with few whitespace interludes--domain keys header. When I read one of those headers in Eudora (Macintosh, of course), Eudora breaks it on screen in such a way that it *appears* to break the header sequence.
That isn't so, as I found by widening the Eudora window across a screen and a half...the header really is just one long line of--to be kind--stuff.
Mailman (probably the Python Email module) may be having trouble with that.
If the domain keys header is the problem, and it relates to the email module, poor Barry...he just tuned that up.
--John
PeteBell wrote:
What exactly are the possible problems when a batch of around 5 or 6
list emails don't get sent out, but they DO appear in the archives?
Hard to say. If a post gets to the archives, it should also have gotten to the digest if any, and very little happens after that. Look in the outgoing queue (qfiles/out/) and the shunt queue (qfiles/shunt/). Also look in Mailman's 'error' and 'smtp-failure' logs.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
John W. Baxter -
Mark Sapiro -
PeteBell