[Mailman-Users] No subscription is made despite confirmation

[Mark Sapiro]

Henrik Rasmussen 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?


>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? For other users on this list? What if the
user confirms by web?


>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.

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.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan