Bad Confirmation String to cancel Message that was too large.
Good Morning MMUsers,
I have MM2.1.23 installed from sources on CentOS5.
I have a list that has a max message size of 20kb to encourage plain text and trimming.
Recently some users have been getting the notice that their message is too big, and when they click the link to cancel the post, the link returns a page with a "Bad Confirmation String" error.
The latest was this morning. A user sent an email that was too big, and almost immediately click the link in the email they received and got the bad confirmation string.
I tried sending a large email to test and the confirmation string worked for me.
Looking in the vette log, I can see where the email was held, but I'm not sure where the confirmation string is coming from. This is the entry:
Apr 03 04:42:48 2017 (548) dba-OT post from USER@gmail.com held, message-id=<CAEkqQpXMAvPkOXK-3O1Y16CFF8cVVs-Ry850nYBpcy73U2nsxA@mail.gmail.com>: Message body is too big: 27563 bytes with a limit of 20 KB
The confirmation string from the email is: 93321f4b6ef46ce0148f5da147bda4c02a63f5c7
Any ideas what to look at next to try and figure out why this is happening?
This isn't the first time that users have reported that the confirmation strings didn't work.
Thanks, Bryan
-- Bryan Carbonnell - carbonnb@gmail.com Life's journey is not to arrive at the grave safely in a well-preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"
On 04/03/2017 07:18 AM, Bryan Carbonnell wrote:
too big, and when they click the link to cancel the post, the link returns a page with a "Bad Confirmation String" error.
The latest was this morning. A user sent an email that was too big, and almost immediately click the link in the email they received and got the bad confirmation string.
I tried sending a large email to test and the confirmation string worked for me.
Looking in the vette log, I can see where the email was held, but I'm not sure where the confirmation string is coming from. This is the entry:
Apr 03 04:42:48 2017 (548) dba-OT post from USER@gmail.com held, message-id=<CAEkqQpXMAvPkOXK-3O1Y16CFF8cVVs-Ry850nYBpcy73U2nsxA@mail.gmail.com>: Message body is too big: 27563 bytes with a limit of 20 KB
The confirmation string from the email is: 93321f4b6ef46ce0148f5da147bda4c02a63f5c7
The confirmation string is the token in the pending database for the entry for this held message. There is a script at <https://www.msapiro.net/scripts/list_pending> (mirrored at <https://fog.ccsf.edu/~msapiro/scripts/list_pending>) that can be used to dump the pending database.
Any ideas what to look at next to try and figure out why this is happening?
This isn't the first time that users have reported that the confirmation strings didn't work.
One possibility is the user's MUA which is rendering the confirmation URL as 'clickable' is not linking to the correct URL.
E.g. a url like
http://example.net/mailman/confirm/list1/dc2cf48d519423a7ff9d96d138317fb4a57...
might get folded so when clicked, it actually goes to something like
http://example.net/mailman/confirm/list1/dc2cf48d519423a7ff9d96d138317f
One thing to check is when the user gets the
Bad confirmation string Invalid confirmation string: ...
response that the string is actually the exact 40 character string from the email. What happens if the user clicks "re-enter" in the "Otherwise, re-enter your confirmation string." line and enters the exact 40 character string from the email?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks Mark. No Luck. :( Comments inline
On 3 April 2017 at 10:59, Mark Sapiro <mark@msapiro.net> wrote:
On 04/03/2017 07:18 AM, Bryan Carbonnell wrote:
I tried sending a large email to test and the confirmation string worked for me. <snip> The confirmation string from the email is: 93321f4b6ef46ce0148f5da147bda4c02a63f5c7
The confirmation string is the token in the pending database for the entry for this held message. There is a script at <https://www.msapiro.net/scripts/list_pending> (mirrored at <https://fog.ccsf.edu/~msapiro/scripts/list_pending>) that can be used to dump the pending database.
I don't see the confirmation string in the list's db even though I still see the email in held moderation queue.
It's actually weird. There are 6 messages that are held in the db, but only 2 in the moderation queue
One possibility is the user's MUA which is rendering the confirmation URL as 'clickable' is not linking to the correct URL.
response that the string is actually the exact 40 character string from the email. What happens if the user clicks "re-enter" in the "Otherwise, re-enter your confirmation string." line and enters the exact 40 character string from the email?
There was no line wrapping that I could see. They forwarded the email to me, and when I click the link, it returns the 40 character string that isn't in the db.
Is there anything else I can check, or should I write this one off as an anomoly?
-- Bryan Carbonnell - carbonnb@gmail.com Life's journey is not to arrive at the grave safely in a well-preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"
On 04/03/2017 11:36 AM, Bryan Carbonnell wrote:
The confirmation string is the token in the pending database for the entry for this held message. There is a script at <https://www.msapiro.net/scripts/list_pending> (mirrored at <https://fog.ccsf.edu/~msapiro/scripts/list_pending>) that can be used to dump the pending database.
I don't see the confirmation string in the list's db even though I still see the email in held moderation queue.
Did you give the '-m' option to the script. Without it, you won't see held messages.
It's actually weird. There are 6 messages that are held in the db, but only 2 in the moderation queue
Perhaps the admindb interface is not for the current mailman installation?
If you run the list_requests script from <https://www.msapiro.net/scripts/list_requests> with the -l LISTNAME and -v options, does it correlate with the admindb list?
Do the IDs in that output correlate with those in the list_pending -m -v output?
Also, do the data/heldmsg-LISTNAME-ID.pck files correlate with the admindb.
If there are discrepancies, are there any exceptions logged in Mailman's error log?
Is there anything else I can check, or should I write this one off as an anomoly?
If the message is in the admindb interface, it should be in the pending.pck, at least if it's recent. Older messages could have had their pending confirmations removed after PENDING_REQUEST_LIFE (default 3 days).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3 April 2017 at 12:01, Mark Sapiro <mark@msapiro.net> wrote:
On 04/03/2017 11:36 AM, Bryan Carbonnell wrote:
I don't see the confirmation string in the list's db even though I still see the email in held moderation queue.
Did you give the '-m' option to the script. Without it, you won't see held messages.
Yes. (Down to 5 now)
$ ./list_pending -m -v dba-ot
cookie: e218b075f231a8aceeeae3bc9bb301b4328b0d79 type: H data: 5640 expiration: Thu Apr 6 06:56:58 2017 cookie: 628801c2354da0f1472f6a20a7fbe9e32f8dff48 type: H data: 5637 expiration: Wed Apr 5 14:01:54 2017 cookie: b63c013faa69b2d37d3d1c53580294a8fe3ed669 type: H data: 5635 expiration: Mon Apr 3 23:46:25 2017 cookie: 20ea7168e15b739d8b56b8a68057c86f6fdf11ff type: H data: 5636 expiration: Wed Apr 5 06:23:30 2017 cookie: 10f908cac1d37bc935d215bcb51f74421b5cb236 type: H data: 5638 expiration: Wed Apr 5 17:43:59 2017
It's actually weird. There are 6 messages that are held in the db, but only 2 in the moderation queue
Perhaps the admindb interface is not for the current mailman installation?
AFAIK it's the only Mailman installation on the server. I've been the only one who has done anything on this server in a long time (but that doesn't mean I haven't messed something up :).
If you run the list_requests script from <https://www.msapiro.net/scripts/list_requests> with the -l LISTNAME and -v options, does it correlate with the admindb list?
Yes. Both only have 2 messages.
$ ./list_requests -l dba-ot
2 dba-OT moderator request(s) waiting
Pending posts: From: eptept@gmail.com on Mon Apr 3 04:42:48 2017 Subject: Re: [dba-OT] Turmoil on the Home Front Cause: Message body is too big: 27563 bytes with a limit of 20 KB
From: ssharkins@gmail.com on Mon Apr 3 06:56:58 201v Subject: Re: [dba-OT] Turmoil on the Home Front (Redux) Cause: Message body is too big: 20749 bytes with a limit of 20 K
$ ./list_requests -v
2 dba-OT moderator request(s) waiting
Pending posts: From: eptept@gmail.com on Mon Apr 3 04:42:48 2017 Subject: Re: [dba-OT] Turmoil on the Home Front Cause: Message body is too big: 27563 bytes with a limit of 20 KB 5639
From: ssharkins@gmail.com on Mon Apr 3 06:56:58 2017 Subject: Re: [dba-OT] Turmoil on the Home Front (Redux) Cause: Message body is too big: 20749 bytes with a limit of 20 KB 5640
Do the IDs in that output correlate with those in the list_pending -m -v output?
Yes and no. One, 5640, is there. One, 5639, isn't and 5639 is the one that had the problem with the confirmation string.
Also, do the data/heldmsg-LISTNAME-ID.pck files correlate with the admindb.
Yes. There are only 2 heldmsg-LISTNAME-ID.pck files The IDs correspond to the IDs after running ./list_request -v
$ ls ../data/heldmsg-dba-ot-*
../data/heldmsg-dba-ot-5639.pck ../data/heldmsg-dba-ot-5640.pck
If there are discrepancies, are there any exceptions logged in Mailman's error log?
Nothing in the error log except a couple of invalid listname errors and an invalid arcive file request
Is there anything else I can check, or should I write this one off as an anomoly?
If the message is in the admindb interface, it should be in the pending.pck, at least if it's recent. Older messages could have had their pending confirmations removed after PENDING_REQUEST_LIFE (default 3 days).
Thanks for trying to help me out Mark. I do appreciate it.
-- Bryan Carbonnell - carbonnb@gmail.com Life's journey is not to arrive at the grave safely in a well-preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"
On 04/03/2017 12:57 PM, Bryan Carbonnell wrote:
Thanks for trying to help me out Mark. I do appreciate it.
Some of my prior replies may have been misleading. I just did some more detailed looking and here's some info.
First, when a held message is handled via the admindb interface (approved, discarded, rejected) the entry in the pending db is not removed. This is probably why you have entries in the pending db that aren't in the admindb interface.
The other side of this is if the user goes to the confirm URL and clicks "Continue awaiting approval", the entry in the pending db is removed so if the user goes back a second time, she gets the invalid confirmation string message.
This can explain why there is a held message not in the pending db.
This can obviously come about from the user clicking "Continue awaiting approval" and then going back, but conceivably it can happen if the user "stutters" on the mouse and clicks more than once and possibly clicks on the "Continue awaiting approval" button without really seeing that page.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3 April 2017 at 15:06, Mark Sapiro <mark@msapiro.net> wrote:
On 04/03/2017 12:57 PM, Bryan Carbonnell wrote:
Thanks for trying to help me out Mark. I do appreciate it.
Some of my prior replies may have been misleading. I just did some more detailed looking and here's some info.
I've got new tools to help manage my Mailman install, so even if they were misleading, it's all good.
First, when a held message is handled via the admindb interface (approved, discarded, rejected) the entry in the pending db is not removed. This is probably why you have entries in the pending db that aren't in the admindb interface.
OK, that makes sense.
The other side of this is if the user goes to the confirm URL and clicks "Continue awaiting approval", the entry in the pending db is removed so if the user goes back a second time, she gets the invalid confirmation string message.
This can explain why there is a held message not in the pending db.
This can obviously come about from the user clicking "Continue awaiting approval" and then going back, but conceivably it can happen if the user "stutters" on the mouse and clicks more than once and possibly clicks on the "Continue awaiting approval" button without really seeing that page.
I've gone back to the user and asked them. So for now, I'm going to wait and see what they have to say.
B
-- Bryan Carbonnell - carbonnb@gmail.com Life's journey is not to arrive at the grave safely in a well-preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"
participants (2)
-
Bryan Carbonnell -
Mark Sapiro