go to bug id or search bugs for
From time to time, we see that users cannot confirm their subscription (or unsubscription). The first mail to request works fine, but when the +confsub part comes, it fails - users report they just get "Posting not allowed" instead of a confirmation, and in fact, the confirmation never happens.
For one user we could now nail the problem down to Evolution being used as mail client. Same server, same sender, but Thunderbird, and +confsub worked like a charm.
I lack further details, like Evolution version, but wanted to share in case someone has cycles free to investigate.
Add a Patch
If you have a willing user who is able to help, there are a couple of things to try.
1. Presumably the denial messages are being sent because subonlypost is set. If you also set modnonsubposts and set up a moderator in moderators, you should be able to snag yourself a copy of the message (in $listdir/moderation). It won't be completely unchanged, but it would be better than nothing. At least you may be able to examine the To: header, etc. (as long as your delheaders tunable and preprocessing doesn't blow it away). Ideally, of course, you'd actually make a test list for this. If you did that, you could use a preprocessing script that cats incoming messages somewhere for even more reliable capture. :-)
2. Does the user have a "Sent Items" box? If so, perhaps you could get them to send you a copy of the source of the failed +confsub message.
Having a good idea what left the client as well as what arrived at Mlmmj would definitely be helpful.
This may be related to bug #52. I suggest keeping an eye on that bug.
Actually, I am the user that is hit by this behavior...
When I confirm my subscription, and the To: header looks like (all that on one line):
I get "The message from <kendy@collabora...> with subject "Re: Confirm subscription to email@example.com" was unable to be delivered to the list", but when I manually change the To: in Evolution to be like:
all is fine, and I get subscribed.
Thank you in advance!
Although Kendy sent me mails from sent items that had and hadn't worked in October 2015, I have been unable to reproduce this bug using current Mlmmj (188.8.131.52) with Exim 4 or Postfix (2.9.6) on a Debian Wheezy VM, nor by commenting out some of Mlmmj's code to force it to execute code paths I suspected as containing this bug.
If this is still a problem with the current version, I'll need some more help (e.g. from Florian) to track this down.
At the moment, I'm leaning towards either believing this problem to be fixed in the current version, or blaming another component, e.g. a custom filter running in front of Mlmmj.
Please close this bug.
Telling how to close bugs would even better.