Message held when unsubscribing to a conversation without leaving subject line blank

[Kathy Gee]

When a user tries to unsubscribe to a conversation (syntax: [listname]+[conversation]+<email address hidden>) and enters "unsubscribe" in the subject line, the message is "held" for approval because the system sees that it "may contain administrivia". Subject should be left blank. Ideally, it should not matter, but is this worth fixing without much hassle?

[Robin J (robin-jeffries)]

closely related bug: 386133

[beachbrake (wordsofagirl)]

I have been trying to tackle this bug for sometime now. And after a lot of exploration I got a decent understanding of the handlers in Mailman. Initially I had thought that this would be a complex patch. But my grepping lead me to hints about the Global Pipeline. I realized that the actions happening in Bug #324406 and #386133 are happening in handlers called "Hold" and "MimeDel". So the easiest solution I could come up with was moving "Dlists" module up in the queue with:

GLOBAL_PIPELINE.insert(GLOBAL_PIPELINE.index("Hold"), "Dlists")

Now I am not completely sure as to what this might break. A lot of assumptions here! I tried the above and tested and it seems to work with whatever scenarios I could think of. But I might be completely wrong about this. Can I have some thoughts on this? In case this solution is viable, I have attached a patch that will update mm_cfg.py.

[Erica Wolfe (erica-wolfe)]

Here's my test case.

Precondition: 2 users are part of a conversation

Steps to reproduce bug 324406:

1. Unsubscribe from a conversation by sending an email to [listname]+[conversation]+<email address hidden> with a subject of "unsubscribe".

2. Receive message from [listname]-<email address hidden> that the message is being held for approval as the message may contain administrivia.

Steps to fix bug and verify the fix:

1. Apply patch.

2. Unsubscribe from a conversation by sending an email to [listname]+[conversation]+<email address hidden> with a subject of "unsubscribe".

3. Have second user send email to list, as first user has unsubscribed, they should not receive this email.

[Erica Wolfe (erica-wolfe)]

I tested the proposed patch and it did fix the issue. However, it is not appropriate. Moving the dlist handler forward in the pipeline queue causes the message to be sent before it is processed by (now) subsequent handlers such as hold and mimedel.

The hold handler is the source of the issue. Currently it is generic and does not distinguish between dlists and regular lists.

I'm attaching a patch that causes dlist subjects to not be considered criteria for administrivia. This may disable other functionality that depend upon the subject's contents. Additionally, I'm not certain that either of the files are part of the Systers Mailman customization. While I'm certain that the patch fixes the bug and may be appropriate, I'm not sure it's the right fix for the Systers project. What are the next steps? I'd like some guidance.

[Erica Wolfe (erica-wolfe)]

http://bazaar.launchpad.net/~erica-wolfe/systers/wishlist/revision/85

Committed revision 85 to the wishlist branch.

The two bugs are small issues with unsubscribing. To resolve these issues, I split the Handler/Dlists.py into two files, Handlers/PreprocessDlists and Handlers/ProcessDlists. Shared functions were put into DlistUtils. Small edits to mm_cfg.py were required to insert the new files into the handler pipeline.