[Mailman-Users] No subscription is made despite confirmation

Henrik Rasmussen her at adm.ku.dk
Thu Feb 14 13:15:03 CET 2008


Mark Sapiro wrote:

>>One of my list administrators have celled me regarding some users not being subscribed to a list. Mailman have sent the users in question a confirmation ticket, and the subscribe log shows that the users have been put in pending mode.
>> 
>>Jan 31 13:09:33 2008 (2223) listname: pending me at privacy.net <mailto:me at privacy.net>   me at privacy.net <mailto:me at privacy.net> 
>> 
>>When the users returned the mail, Mailman issued a New command
>> 
>>Jan 31 13:11:29 2008 (2223) listname: new "me at privacy.net <mailto:me at privacy.net> " <>, via email confirmation
>
>
>And this user is successfully subscribed. The only things left to do
>after the "new" log entry is written are
>
> - Send the welcome to the user if the list's send_welcome_msg is Yes.
>
> - Send the notice to the admin if the list's admin_notify_mchanges is
>   Yes.
>
>Were these messages received?

Both send_welcome_msg and admin_notify_mchanges has been set to No. The subscriber currently have vacation so whether she received a "Result of your commands" mail is unknown. I've tried subscribing to the list from my external mail account and (as the subscriber) received the "Result of your commands" reply. Though I am actually subscribed to the list.

>>but still the users wasn't subscribed (list_members listname still did not show the user as member of the list).
>
>
>I don't know why this would be the case. Does subscribe and confirm by
>email work for other lists?

Yes this works (for me anyway), I haven't consultet the user about this yet.

>For other users on this list?

For me, by subscribing an external address (a spamcop.net address) to the particular list works too.

>What if the user confirms by web?

In general, the users have no knowledge about the web-interface nor the use of it. Only the list administrators have.


>>A few days later one of the users retried subscribing, and the same happened. The log does not show any signs that the user have tried unsubscribing (deleted).
>> 
>>According to the error log at the particular time, Mailman seems to have failed subscribing the user.

>These errors have nothing to do with the problem.
>Jan 31 11:36:09 2008 (2223) SHUNTING: 1201775768.8376081+629ed6771846a9304e6eca2178f2047980aa8630
>
>This is from a shunted message at 11:36:09. The error that caused the
>shunting is the traceback with the same timestamp that precedes the
>above message in the log.
>
>
>>Jan 31 13:10:06 2008 (2223) Uncaught runner exception: 'ascii' codec can't decode byte 0xf8 in position 5: ordinal not in range(128)
>>Jan 31 13:10:06 2008 (2223) Traceback (most recent call last):
>>  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop
>>    self._onefile(msg, msgdata)
>>  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 167, in _onefile
>>    keepqueued = self._dispose(mlist, msg, msgdata)
>>  File "/usr/lib/mailman/Mailman/Queue/CommandRunner.py", line 237, in _dispose
>>    res.process()
>>  File "/usr/lib/mailman/Mailman/Queue/CommandRunner.py", line 110, in process
>>    stop = self.do_command(cmd, args)
>>  File "/usr/lib/mailman/Mailman/Queue/CommandRunner.py", line 135, in do_command
>>    return self.do_command(cmd, args)
>>  File "/usr/lib/mailman/Mailman/Queue/CommandRunner.py", line 137, in do_command
>>    return handler.process(self, args)
>>  File "/usr/lib/mailman/Mailman/Commands/cmd_confirm.py", line 86, in process
>>    if line.lstrip() == match:
>>UnicodeDecodeError: 'ascii' codec can't decode byte 0xf8 in position 5: ordinal not in range(128)
>
>
>And this traceback is probably followed by another 'shunting' entry for
>the message that caused it.

That's correct.

>
>These error log entries are from messages (most likely spam) with
>unencoded non-ascii characters in headers such as Subject: or From:.
>
>You can see these messages in the shunt queue and determine what they
>are.
>
>  bin/show_qfiles qfiles/shunt/*
>
>It is possible that the traceback at 13:10:06 is from this user's
>confirm attempt, but even if this is the case, the confirm was
>successfully retried by the user, because if it hadn't been, there
>would be no 'new' entry in the subscribe log.

The thunted message is the particular confirmation reply from the user. The reply contains HTML, however, as you point out, this wasn't a problem since a 'new' command was in fact issued.

Thanks for a good description. 
 
Best Regards Henrik Rasmussen
 

 
Henrik Rasmussen
Systems Administrator
 
University of Copenhagen
Corporate IT
Noerregade 10
P.O.B 2177
DK-1017 Copenhagen K
DENMARK
it.ku.dk
 


More information about the Mailman-Users mailing list