2.0.8 borks on dot in local part of addr

Bug #265608 reported by Monkeymaster
2
Affects Status Importance Assigned to Milestone
GNU Mailman
Invalid
Medium
Unassigned

Bug Description

In a mail address's local part (the part to the left of
the at sign), it is perfectly valid to have periods.
However, mailman stops reading the address right at the
@, so that "<email address hidden>" is shown as "mr.bad".
this is disastrous for lists where only subscribers are
allowed to post, since the system doesn't allow for
exceptions that lack an @ and a FQDN.

Either allowing exceptions to be of a more forgiving
format, or fixing the broken regex that truncates the
mail addresses would solve my problem. I'm getting
tired of moderating a legitimate user's posts,
especially since the system won't even send the
warnings to the correct address.

[http://sourceforge.net/tracker/index.php?func=detail&aid=517192&group_id=103&atid=100103]

Revision history for this message
Barry Warsaw (barry) wrote :

Either I need more information, or this problem is fixed in
MM2.1. Quite often I uses test addresses like
"barry.warsaw@<wherever>" and I've had no problems with
it.

Revision history for this message
Monkeymaster (monkeymaster) wrote :

The bug turns out not to be when there is a period in the
address, but in the plain text name. The mail address in
question is:

Mr. Bad <email address hidden>

I realized this when I saw people who had different text
names from their e-mail addresses, as in:

Jr. Pickle <email address hidden>

This would show up as the mythical address "jr.pickle" in
mailman, and things would b0rk.

Revision history for this message
Barry Warsaw (barry) wrote :

This is really a bug with earlier versions of Python, I
believe. MM2.0.x uses the standard library function
rfc822.parseaddr() to break and address into its realname +
email constituent parts. Here are some examples:

% python
Python 2.2.1 (#1, Apr 22 2002, 17:14:12)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "help", "copyright", "credits" or
"license" for more
information.
>>> from rfc822 import parseaddr
>>> parseaddr('Mr. Bad <email address hidden>')
('Mr. Bad', '<email address hidden>')

% python2.1
Python 2.1.3 (#1, Apr 22 2002, 18:17:38)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for
more information.
>>> from rfc822 import parseaddr
>>> parseaddr('Mr. Bad <email address hidden>')
('', 'Mr.Bad')

So this is clearly broken in Python 2.1.3, and works in
Python 2.2.1. I'll look at backporting the fix to Python
2.1 in case there's ever a 2.1.4. But if you're using an
earlier version of Python, this will still be broken.
Consider upgrading to Python 2.2.1.

Revision history for this message
Monkeymaster (monkeymaster) wrote :

This happens even when I use python 2.2

Revision history for this message
Dmick (dmick) wrote :

I can echo that Python 2.2 doesn't have the parseaddr
problem. monkeymaster, can you try Barry's two-line
experiment and see if that works or fails?

Revision history for this message
Barry Warsaw (barry) wrote :

BTW, I'm attaching the patch to Python 2.1.3's rfc822.py
that I plan on checking in momentarily. This backports the
Python 2.2.1 patch for the problem, and with this, my 2-line
example below also succeeds for Python 2.1.3.

If there's ever a Python 2.1.4, this patch will be part of it.

Revision history for this message
Barry Warsaw (barry) wrote :

monkeymaster, please try the patch, or include a Python
2.2.1 session that shows the bug still exists. I believe
this bug report should be marked closed.

Revision history for this message
Monkeymaster (monkeymaster) wrote :

So when testing the 2.2.1 Python, I see the difference.
However, the following headers cause it to reject "mr.bad"
as a non-subscriber:

Received: from mail15.speakeasy.net (mail.speakeasy.net)
[216.254.0.215]
 by zork.zork.net with esmtp (Exim 3.35 #1 (Debian))
 id 174ukJ-0000VO-00; Mon, 06 May 2002 19:30:31 -0700
Received: (qmail 3123 invoked from network); 7 May 2002
02:30:29 -0000
Received: from unknown (HELO tyrell) ([66.217.50.46])
(envelope-sender <email address hidden>)
          by mail15.speakeasy.net (qmail-ldap-1.03) with
DES-CBC3-SHA encrypted SMTP
          for <email address hidden>; 7 May 2002
02:30:29 -0000
Received: from evan by tyrell with local (Exim 3.35 #1 (Debian))
 id 174uii-0002m8-00
 for <email address hidden>; Mon, 06 May 2002 22:28:52
-0400
To: <email address hidden>
Subject: %^$!$^$%!! W32.Elkern and Kin
From: Mr. Bad <email address hidden>
Organization: Pigdog Journal
X-PGP-Fingerprint: 91F8 6B2D EBEA 8D7A 3F20 E5B0 6D97 B3BC
F498 A1D9
X-Revolutionary-Date: Septidi, 17 Flore'al 210 9:25:94 -20833
Date: Mon, 06 May 2002 22:28:48 -0400
Message-ID:
<email address hidden>
Lines: 27
User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1
 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Revision history for this message
Barry Warsaw (barry) wrote :

I don't quite understand, are you saying that even though
"<email address hidden>" is a member of the list, this message is
being not matching as being posted from a member? Under
Python 2.2.1?

Revision history for this message
Monkeymaster (monkeymaster) wrote :

<email address hidden> *is* a member of the list, but those
headers cause mailman to tell me:

List: <email address hidden>
                    From: mr.bad
                                        Subject: %^$!$^$%!!
W32.Elkern and Kin
Reason: Post by non-member to a members-only list

Note the lack of an @ or FQDN in the From:

Yes, I am using python 2.2.1

Revision history for this message
Monkeymaster (monkeymaster) wrote :

Oh, and for what it's worth, I applied that patch as well to
my 2.1 copy, so there's no chance that's screwing this up
(it's pretty definitely running 2.2.1 now, which doesn't
have that 2822 problem)

Revision history for this message
Barry Warsaw (barry) wrote :

I simply can't reproduce this problem with Python 2.2.1 and
current cvs of Mailman 2.1 beta 3+

I subscribed an address like <email address hidden> (Barry
Warsaw, Jr.) and then sent a message coming from that
address and it went through just fine.

Unless we can get more information, I'm going to have to
close this report. Moving it to Pending status in lieu of
follow ups.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.