Hello,
I am trying to debug a problem with the confirmation from one of my
users.
The user as replied to the invitation email but her subscriptions has
been refused (her state is still S).
Here are the gory details:
(I have obscured only mail addresses and list details. IP addresses
and confirmation string are untouched.
Sorry for the long line length.)
invitation sent:
2006-03-16 00:38:07 IW70BJ-000K5I-JO <= mylist-bounces
+user=domain@list.server H=localhost (g4.local) [127.0.0.1] P=esmtp
S=2041 id=mailman.0.1142465885.26117.mylist@list.server
2006-03-16 00:38:08 IW70BJ-000K5I-JO => user@domain R=dnslookup
T=remote_smtp H=mx1.libero.it [193.70.193.95]
3 attempts by the user to confirm subscription, they are sent to the
correct confirm address:
2006-03-16 10:43:17 IW7SC5-0002D5-0Z <= user@domain H=smtp5.libero.it
[193.70.192.55] P=esmtp S=1982 id=IW7S96
$A6460D465ACAB1F3B705458C794DF7C1@libero.it
2006-03-16 10:43:18 IW7SC5-0002D5-0Z => mylist <mylist-confirm
+8a671672b88489848cd212b368d290cc343af848@list.server>
R=mailman_router T=mailman_transport
2006-03-16 10:43:18 IW7SC5-0002D5-0Z Completed
2006-03-16 10:43:22 IW7SCA-0002DA-HL <= mylist-bounces
+user=domain@list.server H=localhost (g4.local) [127.0.0.1] P=esmtp
S=3833 id=mailman.54.1142502199.2491.mylist@list.server
2006-03-16 10:43:24 IW7SCA-0002DA-HL => user@domain R=dnslookup
T=remote_smtp H=mx1.libero.it [193.70.193.95]
2006-03-16 10:43:24 IW7SCA-0002DA-HL Completed
2006-03-16 10:45:09 IW7SF9-0002DI-2J <= user@domain H=smtp2.libero.it
[193.70.192.52] P=esmtp S=2905 id=IW7SCA
$74805EBCDDDF86B284ECA9380FB5979F@libero.it
2006-03-16 10:45:10 IW7SF9-0002DI-2J => mylist <mylist-confirm
+8a671672b88489848cd212b368d290cc343af848@list.server>
R=mailman_router T=mailman_transport
2006-03-16 10:45:10 IW7SF9-0002DI-2J Completed
2006-03-16 10:45:13 IW7SFD-0002DR-3R <= mylist-bounces
+user=domain@list.server H=localhost (g4.local) [127.0.0.1] P=esmtp
S=5836 id=mailman.55.1142502310.2491.mylist@list.server
2006-03-16 10:45:16 IW7SFD-0002DR-3R => user@domain R=dnslookup
T=remote_smtp H=mx1.libero.it [193.70.193.95]
2006-03-16 10:45:16 IW7SFD-0002DR-3R Completed
2006-03-16 10:46:58 IW7SIA-0002DU-E3 <= user@domain H=smtp3.libero.it
[193.70.192.127] P=esmtp S=1771 id=IW7SFC
$6E27427742E6C42C9FB6F56151FC9726@libero.it
2006-03-16 10:46:59 IW7SIA-0002DU-E3 => mylist <mylist-confirm
+8a671672b88489848cd212b368d290cc343af848@list.server>
R=mailman_router T=mailman_transport
2006-03-16 10:46:59 IW7SIA-0002DU-E3 Completed
The user received the following error after the first attempt, I just
cut some received lines.
The message is in italian and reads more or less:
Results: invalid confirmation string [...]
Not processed: confirm 8a671672b88489848cd212b368d290cc343af848
End
Return-Path: <mylist-bounces+user=domain@list.server>
Received: from smtp3.libero.it (193.70.192.127) by ims19c.libero.it
(7.2.059.5)
id 4406D169001733AB for user@domain; Thu, 16 Mar 2006
10:43:19 +0100
[...]
Received: from localhost ([127.0.0.1] helo=g4.local)
by tempesta.mydomain with esmtp (Exim 4.60)
(envelope-from <mylist-bounces+user=domain@list.server>)
id IW7SIE-0002DZ-GK
for user@domain; Thu, 16 Mar 2006 10:47:02 +0100
Subject: =?iso-8859-1?q?Risultati_dei_comandi_nel_tuo_messaggio?=
From: mylist-bounces@list.server
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1898544924=="
Message-ID: <mailman.56.1142502420.2491.mylist@list.server>
Date: Thu, 16 Mar 2006 10:47:00 +0100
Precedence: bulk
X-BeenThere: mylist@list.server
X-Mailman-Version: 2.1.7
List-Id: newsletters <mylist.list.server>
X-List-Administrivia: yes
To: user@domain
Sender: mylist-bounces+user=domain@list.server
Errors-To: mylist-bounces+user=domain@list.server
X-HUMPH-Peer-rDNS: localhost
--===============1898544924== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
I risultati dei comandi che erano nel tuo messaggio sono mostrati qui sotto. Allegato trovi il tuo messaggio originale.
- Risultati:
Stringa di conferma non valida. Nota che le stringhe di
convalida =
scadono approssimativamente dopo 3 giorni dalla richiesta iniziale. Se la tua richiesta =E8 scaduta, per favore ripeti la procedura da capo.
Non elaborati: confirm 8a671672b88489848cd212b368d290cc343af848
Finito.
--===============1898544924== Content-Type: message/rfc822 MIME-Version: 1.0
Received: from smtp3.libero.it ([193.70.192.127]) by tempesta.mydomain with esmtp (Exim 4.60) (envelope-from <user@domain>) id IW7SIA-0002DU-E3 for mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server; Thu, 16 Mar 2006 10:46:58 +0100 [...] Thu, 16 Mar 2006 10:46:49 +0100 Date: Thu, 16 Mar 2006 10:45:12 +0100 Message-Id: <IW7SFC$6E27427742E6C42C9FB6F56151FC9726@libero.it> Subject: =?iso-8859-1?b? UmU6yCByaWNoaWVzdGEgbGEgdHVhIGNvbmZlcm1hIHBlcg==?= =?iso-8859-1?b?IGlzY3JpdmVydGkgYWxsYSBsaXN0YSBlbGZvLW5ld3M=?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "user\@domain\.it" <user@domain> To: "mylist-confirm+8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server> X-XaM3-API-Version: 4.3 (R1) (B3pl14) X-SenderIP: 85.18.136.77 X-Scanned: with antispam and antivirus automated system at libero.it X-HUMPH-Peer-rDNS: ns2.libero.it ns1.libero.it
confirm 8a671672b88489848cd212b368d290cc343af848
the list pending pick contains:
'8a671672b88489848cd212b368d290cc343af848': ( 'S',
<UserDesc user@domain (User Name) [password] [digest? no] [it]>),
'evictions': { '1fb8a40026d6ba70cd0b7673aee8b981cb8357fe':
1142730263.5198989,
'3e60d959c6fcbb0283b99aeb8d989dbdcfc9add5':
1142532050.440028,
'4b6064163c503671ab56742747995dc69b4e5340':
1142515273.500232,
'4d00983d4870ded7dd7f71b4afa076d933cb20b4':
1142606644.057848,
'4f596c21fc862542571bd0a27f69fb9e28cc4d37':
1142515273.444937,
'69688a2fd5d9b58b9d742fd759414f5cc7488986':
1142730265.8702731,
'73216e6fe18ef24607477491f1abc345cd7f670f':
1142724911.066819,
'8339c1f4fb851dbdd954f697120d367e480637cd':
1142764046.192688,
'84af391da0af8bfc54b16214082ebb0f2b7c758e':
1142684865.5612831,
'8a671672b88489848cd212b368d290cc343af848':
1142725085.0594411,
'fe7403de2e82c6834deb1bae05b403a1fc7fa03f':
1142730263.8872991},
Note that the confirmation string is correct but that the
confirmation string also appears in evictions.
Any ideas?
Thanks
Giuliano
Giuliano Gavazzi wrote:
To: "mylist-confirm+8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server>
This is the problem. You have VERP_CONFIRMATIONS = Yes so the confirmation is From: and the user's reply should be To:
mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server
but the user's MUA has replied To: as above.
VERP_CONFIRM_REGEXP doesn't expect this and parses the cookie as
8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848
which doesn't work. Then there's been an error, so the confirm command in the body is not processed.
Solutions:
The user can use a different MUA
The user can manually edit the To: to remove the "real name"
You can change VERP_CONFIRM_REGEXP in mm_cfg.py to parse this one without breaking normal ones. Possibly something like
VERP_CONFIRM_REGEXP =
r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
will work
Note that the confirmation string is correct but that the
confirmation string also appears in evictions.
It has a time still in the future, so this is normal.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Giuliano Gavazzi wrote:
To: "mylist-confirm+8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server>
This is the problem. You have VERP_CONFIRMATIONS = Yes so the confirmation is From: and the user's reply should be To:
mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server
but the user's MUA has replied To: as above.
VERP_CONFIRM_REGEXP doesn't expect this and parses the cookie as
8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848
which doesn't work. Then there's been an error, so the confirm command in the body is not processed.
Solutions:
The user can use a different MUA
That's a work-around rather than a solution. This problem needlessly makes it harder for both list owners and subscribers to use Mailman hosted lists.
The user can manually edit the To: to remove the "real name"
IMHO, this is a bug. Mailman should correctly parse email sent to:
"mylist-confirm+8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server>
since that is a correctly formatted email address header per the example:
To: "Mary Smith: Personal Account" <smith@home.example>
in RFC 2822:
<http://www.faqs.org/rfcs/rfc2822.html>
jc
JC Dill wrote:
IMHO, this is a bug. Mailman should correctly parse email sent to:
"mylist-confirm+8a671672b88489848cd212b368d290cc343af848" <mylist-confirm+8a671672b88489848cd212b368d290cc343af848@list.server>
since that is a correctly formatted email address header per the example:
To: "Mary Smith: Personal Account" <smith@home.example>
in RFC 2822:
I agree that it's a bug, but I think the primary bug is in an MUA that is generating a reply to mail
From: smith@home.example
and addresses it
To: "smith@home.example" <smith@home.example>
However, I have no objection to Mailman "working around" this MUA bug :-) by changing
VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
in Defaults.py.in
I ask though, does anyone have a better suggestion for a replacement than
VERP_CONFIRM_REGEXP =
r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
or is that OK?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
I agree that it's a bug, but I think the primary bug is in an MUA that is generating a reply to mail
From: smith@home.example
and addresses it
To: "smith@home.example" <smith@home.example>
Not exactly, it does only add the local_part and without quotes.
I have tested your regexp for a "regular" reply and it works. Of
course it does not work with that buggy format (wherever one consider
the bug to be...) and the fixed version is below.
However, I have no objection to Mailman "working around" this MUA bug :-) by changing
VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
in Defaults.py.in
I ask though, does anyone have a better suggestion for a replacement than
VERP_CONFIRM_REGEXP =
r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'or is that OK?
it is too specific as I said. This works instead:
VERP_CONFIRM_REGEXP = r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) @.*$'
This was checked against many formats and probably the simpler and
less reduntant:
VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
would work too. Or even:
VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
as I do not see the point of checking for the line beginning.
Giuliano
On 17 Mar 2006, at 11:18, g wrote:
would work too. Or even:
VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
as I do not see the point of checking for the line beginning.
well, if that is correct, then one can shorten it to:
VERP_CONFIRM_REGEXP = r'?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
(but what is the first "?" for?).
By following the old advice "if it ain't broken don't fix it", I will
not test these alternatives..
Giuliano
Giuliano wrote:
On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
I agree that it's a bug, but I think the primary bug is in an MUA that is generating a reply to mail
From: smith@home.example
and addresses it
To: "smith@home.example" <smith@home.example>
Not exactly, it does only add the local_part and without quotes.
But does it ever do it in the case we are concerned with? Namely where the message is
From: list-confirm+string_of_hex_digits@example.com.
Note that the original regexp works as long as the MUA added stuff doesn't contain '+'.
I have tested your regexp for a "regular" reply and it works. Of
course it does not work with that buggy format (wherever one consider
the bug to be...) and the fixed version is below.
I'm not sure what "your regexp" means here. Is it the one that is currently in Defaults.py(.in), or my suggested change?
However, I have no objection to Mailman "working around" this MUA bug :-) by changing
VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
in Defaults.py.in
I ask though, does anyone have a better suggestion for a replacement than
VERP_CONFIRM_REGEXP =
r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'or is that OK?
it is too specific as I said. This works instead:
Yes, it requires quotes, but as I ask above. Does any MUA that adds this not put quotes around it when it contains '+'?
VERP_CONFIRM_REGEXP = r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) @.*$'
This was checked against many formats and probably the simpler and
less reduntant:VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
would work too. Or even:
VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
as I do not see the point of checking for the line beginning.
Well, I don't think the 'addr' field is actually used, but I think these suggestions eat up all but the last character of it. How about
VERP_CONFIRM_REGEXP = r'(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 17 Mar 2006, at 16:33, Mark Sapiro wrote:
Giuliano wrote:
On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
I agree that it's a bug, but I think the primary bug is in an MUA
that is generating a reply to mailFrom: smith@home.example
and addresses it
To: "smith@home.example" <smith@home.example>
Not exactly, it does only add the local_part and without quotes.
But does it ever do it in the case we are concerned with? Namely where the message is
From: list-confirm+string_of_hex_digits@example.com.
Note that the original regexp works as long as the MUA added stuff doesn't contain '+'.
in the case in question, if I understood you well, the MUA (it might
be a webmail interface)
adds list-confirm+string_of_hex_digit so it does add the + and no
quotes.
I have tested your regexp for a "regular" reply and it works. Of course it does not work with that buggy format (wherever one consider the bug to be...) and the fixed version is below.
I'm not sure what "your regexp" means here. Is it the one that is currently in Defaults.py(.in), or my suggested change?
your suggested change.
However, I have no objection to Mailman "working around" this MUA
bug :-) by changingVERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
in Defaults.py.in
I ask though, does anyone have a better suggestion for a replacement than
VERP_CONFIRM_REGEXP =
r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'or is that OK?
it is too specific as I said. This works instead:
Yes, it requires quotes, but as I ask above. Does any MUA that adds this not put quotes around it when it contains '+'?
No, and I do not think it is required is it?
VERP_CONFIRM_REGEXP = r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) @.*$'
This was checked against many formats and probably the simpler and less reduntant:
VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) @.*$'
would work too. Or even:
VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
as I do not see the point of checking for the line beginning.
Well, I don't think the 'addr' field is actually used, but I think these suggestions eat up all but the last character of it. How about
VERP_CONFIRM_REGEXP = r'(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
don't know. I could test it (when I know there are no pending
subscriptions...). I am not sure I understood what ?P means here. Is
it a macro for "print here the value of what follows". So ?P<addr>
prints the confirmation address minus cookie?
Giuliano
-- H U M P H || ||| software
Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X http://www.humph.com/
Giuliano Gavazzi wrote:
in the case in question, if I understood you well, the MUA (it might
be a webmail interface) adds list-confirm+string_of_hex_digit so it does add the + and no
quotes.
So where did the qoutes come from in the message you included in your original post?
(Moot anyway, since I have moved away from the regexp that matches quotes).
I am not sure I understood what ?P means here. Is
it a macro for "print here the value of what follows". So ?P<addr>
prints the confirmation address minus cookie?
It assigns the value of what matched the expression in parentheses to the named variable. See <http://docs.python.org/lib/re-syntax.html>.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 17 Mar 2006, at 18:02, Mark Sapiro wrote:
Giuliano Gavazzi wrote:
in the case in question, if I understood you well, the MUA (it might be a webmail interface) adds list-confirm+string_of_hex_digit so it does add the + and no quotes.
So where did the qoutes come from in the message you included in your original post?
mmm, I cannot understand where the quotes disappeared in my mind...
Yes, you are correct, there are quotes, but for some reason I decided
that there were none...
(Moot anyway, since I have moved away from the regexp that matches quotes).
I am not sure I understood what ?P means here. Is it a macro for "print here the value of what follows". So ?P<addr> prints the confirmation address minus cookie?
It assigns the value of what matched the expression in parentheses to the named variable. See <http://docs.python.org/lib/re-syntax.html>.
ah, so my expression only worked because addr is not used, while
cookie, which is used, was correctly assigned. Whatever. I will have
a look at that doc to understand your RE fully, thanks.
The only observation is that these errors should be probably logged,
if not forwarded to the list admin, or they might pass undetected
without the collaboration of attentive users.
Thanks again.
Giuliano
Mark Sapiro wrote:
Giuliano wrote:
On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
I agree that it's a bug, but I think the primary bug is in an MUA that is generating a reply to mail
From: smith@home.example
and addresses it
To: "smith@home.example" <smith@home.example>
Not exactly, it does only add the local_part and without quotes.
But does it ever do it in the case we are concerned with? Namely where the message is
From: list-confirm+string_of_hex_digits@example.com.
Note that the original regexp works as long as the MUA added stuff doesn't contain '+'.
To clarify, yes I see in the OP that the added 'real name' only contains the local part, but it was quoted in the OP, so does or does not the MUA put quotes around it?
In any case, I've tested
VERP_CONFIRM_REGEXP = r'(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
against various forms, with and without quotes, and I think it's good, but I'd still like more feedback.
I'v also tested all these:
VERP_CONFIRM_REGEXP =
r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
VERP_CONFIRM_REGEXP = r'?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
and only the first works (for cookie, but not addr). I'm not sure why the second and third don't work, but they and the fourth all give
raise error, v # invalid expressionsre_constants.error: nothing to repeat
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
g -
Giuliano Gavazzi
-
JC Dill -
Mark Sapiro