Every so often I get a report of a posting sent to one of my lists that dissappears. I got two yesterday. Thanks to some detective work, I found one -- it got shunted because of a traceback:
Feb 19 23:44:31 2003 (24496) Uncaught runner exception: sequence expected, NoneT ype found Feb 19 23:44:31 2003 (24496) 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 _dispos e self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 139, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 277, in verpdel iver d = {'bounces': bmailbox, TypeError: sequence expected, NoneType found
This is someone that's able to post normally, so it's not a messed up mailer or anything. Anyone else seeing this?
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.plaidworks.com/chuqui/blog/
No! No! Dead girl, OFF the table! -- Shrek
"CVR" == Chuq Von Rospach chuqui@plaidworks.com writes:
CVR> This is someone that's able to post normally, so it's not a
CVR> messed up mailer or anything. Anyone else seeing this?
This is caused by a VERP delivery to an unqualified address, e.g. if a -request message comes in with a "From: aperson" header, the response can't be usefully VERPified. This should be fixed in 2.1.1 by discarding the outgoing message and logging an entry to logs/smtp.
-Barry
On Thursday, February 20, 2003, at 09:36 AM, Barry A. Warsaw wrote:
"CVR" == Chuq Von Rospach chuqui@plaidworks.com writes:
CVR> This is someone that's able to post normally, so it's not a CVR> messed up mailer or anything. Anyone else seeing this?
This is caused by a VERP delivery to an unqualified address, e.g. if a -request message comes in with a "From: aperson" header, the response can't be usefully VERPified. This should be fixed in 2.1.1 by discarding the outgoing message and logging an entry to logs/smtp.
ah, okay. Except in this case, I believe the address was qualified.
hang on, I'll go look.
Here's the header of the message that died. Note this guy normally can post to the list...
From bep@pinskyfamily.org Wed Feb 19 23:34:58 2003 Return-Path: bep@pinskyfamily.org Received: from spike-internal.pinskyfamily.org (spike.pinskyfamily.org [216.27.185.46]) by plaidworks.com (8.12.6/8.12.2) with ESMTP id h1K7YuSE028110; Wed, 19 Feb 2003 23:34:56 -0800 (PST) Received: from pinskyfamily.org (dhcp-172-16-77-97.pinskyfamily.org [172.16.77.97]) (authenticated bits=0) by spike-internal.pinskyfamily.org (8.12.7/8.12.7) with ESMTP id h1K7VlRs015996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Feb 2003 23:31:57 -0800 (PST) Message-ID: 3E548463.8000008@pinskyfamily.org Date: Wed, 19 Feb 2003 23:31:47 -0800 From: Bruce Pinsky bep@pinskyfamily.org Reply-To: bep@pinskyfamily.org Organization: Pinsky Family User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuq Von Rospach chuqui@plaidworks.com CC: Sharks@plaidworks.com Subject: Re: Talk Radio: Talk to the Chuqster! References: 16CDE8D8-44A3-11D7-AD38-0003934516A8@plaidworks.com In-Reply-To: 16CDE8D8-44A3-11D7-AD38-0003934516A8@plaidworks.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: R
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.plaidworks.com/chuqui/blog/
But when that last guitar's been packed away You know that I still want to play So just make sure you got it all set to go Before you come for my piano
"CVR" == Chuq Von Rospach chuqui@plaidworks.com writes:
>> header, the response can't be usefully VERPified. This should
>> be fixed in 2.1.1 by discarding the outgoing message and
>> logging an entry to logs/smtp.
CVR> ah, okay. Except in this case, I believe the address was
CVR> qualified.
CVR> hang on, I'll go look.
Next time this happens, check the .db file (use bin/dumpdb). Specifically look at the "recips" key to see if there's an unqualified address (maybe it's coming from somewhere else).
-Barry
participants (2)
-
barry@python.org
-
Chuq Von Rospach