[Mailman-Users] Error generated by unsubscribe requests

[Mark Sapiro]

Kærast wrote:
> On Tue, 17 Feb 2009 10:11:52 -0800
> Mark Sapiro <mark at msapiro.net> wrote:
> 
> 
>> The offending statement that throws the exception is line 76 in
>> /usr/lib/mailman/Mailman/Pending.py
>>
>>      if data[0] == UNSUBSCRIPTION and data[1] == content[0].address:
>>
> 
> Indeed it is, though I was hoping for some explanation of what 'content'
> actually is in order to debug it properly.
> 
>> This is not in the source distribution. If this is a Debian patch,
>> contact Debian. If this is one of your "few modifications", fix it.
>>
> 
> It's part of the indymedia patch to stop subscription spam.  Since I've
> never had any subscription spam on other list servers, and I don't
> understand how the patch works, I've simply disabled it.


OK. Just because I'm curious and compulsive, I looked at the patch at
<http://lists.indymedia.org/patches/imc-37-stop-subscription-spam.patch>.

If this is an example of the quality of the indymedia patches, I
wouldn't touch any of them.

What this part of the patch is apparently trying to do is avoid pending
another SUBSCRIBE or UNSUBSCRIBE request when there is already one
pending for the address. There are many things wrong with this patch.
The statement

if data[0] in (SUBSCRIPTION, UNSUBSCRIPTION) and data[1].address ==
content[0].address:

assumes that both data[1] and content[0] are instances of the UserDesc
class. data[1] is the first or only data item for the already pending
request and content[0] is the first or only data item for the current
(to be pended) request. These are only UserDesc instances if the request
type is SUBSCRIPTION. What the data are depends on the request type.

In the above, if data[0] is UNSUBSCRIPTION, data[1] is a string (the
address) so data[1].address throws an exception, and the current request
could be any of SUBSCRIPTION, UNSUBSCRIPTION, CHANGE_OF_ADDRESS,
HELD_MESSAGE, RE_ENABLE or PROBE_BOUNCE and only if it is SUBSCRIPTION
will content[0].address not throw an exception.

Besides all the above technical flaws with horrible symptoms, i.e.,
trying to pend anything but a SUBSCRIPTION request if there are any
pending SUBSCRIPTION requests throws an uncaught exception; trying to
pend any request at all if there is a pending UNSUBSCRIPTION request
throws an uncaught exception, the patch has bad consequences for the user.

Even if the technical difficulties were overcome, the consequence of
this patch is if I try to subscribe or unsubscribe and somehow lose the
confirmation email, I can't successfully try again until the first
request expires (default 3 days).

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