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"

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

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

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

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 expression

sre_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

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