1030228 Mass Subscribe address with control character - can't delete
Subject Bug report is posted on sourceforge.net.
http://list.org/bugs.html says "It is also recommended that you email a note about your submission to the mailman-developers mailing list", thus this post.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Subject Bug report is posted on sourceforge.net.
http://list.org/bugs.html says "It is also recommended that you email a note about your submission to the mailman-developers mailing list", thus this post.
I have two reasons for this followup. First, I neglected to include a
direct link to the report in my original post. Here it is.
http://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103
The second reason is to try to start a discussion on what Mailman
should allow in e-mail addresses. I have looked a little more
carefully at the standards, but I'm still not sure what they allow.
It appears that RFC 2822 (Internet Message Format) allows anything in a
domain-literal which "is interpreted as the literal Internet address
of the particular host", but that RFC 2821 (SMTP) does not allow a
domain-literal to be used at all and is more restrictive than RFC 2822
on other forms of domains as well. Section 2.3.5 of RFC 2821 says in
part "A domain (or domain name) consists of one or more dot-separated
components. These components ("labels" in DNS terminology) are
restricted for SMTP purposes to consist of a sequence of letters,
digits, and hyphens drawn from the ASCII character set.
With regard to the "user" or local-part of the address, the situation
is not so clear. RFC 2821 in section 2.3.10 says in part "(T)he
local-part MUST be interpreted and assigned semantics only by the host
specified in the domain part of the address." It defines the
local-part in the same way as RFC 2822 which allows ascii letters,
digits, internal dots (.) and the following !#$%&'*+-/=?^_`{|}~ which
is all the "printable" ascii characters except space and "(),:;<>@[\]
Both RFCs also allow a local-part to be a quoted-string which can
contain almost any ascii character in \001-\177 except \011 \012 \015
and \040 (<HT>, <LF>, <CR> and <SP>), BUT RFC 2821 says in part in
section 4.1.2 "Systems MUST NOT define mailboxes in such a way as to
require the use in SMTP of non-ASCII characters (octets with the high
order bit set to one) or ASCII "control characters" (decimal value
0-31 and 127). These characters MUST NOT be used in MAIL or RCPT
commands or other commands that require mailbox names."
Thus, it would seem as a practical matter, Mailman should not accept
for subscription any address containing any characters in the ranges
\000-\037 and \177-\377. Thus I suggest the following, totally
untested change:
--- mailman-2.1.5/Mailman/Utils.py 2003-12-26 14:50:04.000000000
-0800
+++ mailman-mas/Mailman/Utils.py 2004-09-19 12:49:30.000000000
-0700
@@ -198,7 +198,7 @@
# TBD: what other characters should be disallowed?
-_badchars = re.compile(r'[][()<>|;^,/\200-\377]')
+_badchars = re.compile(r'[][()<>|;^,/\000-\037\177-\377]')
def ValidateEmail(s):
"""Verify that the an email address isn't grossly evil."""
This still leaves open the question of whether the printable characters
in the _badchars RE are the right ones and what to do with
quoted-string local-parts, but I think it would prevent my immediate
problem from recurring.
--
Mark Sapiro
At 12:54 PM -0700 2004-09-19, Mark Sapiro wrote:
It appears that RFC 2822 (Internet Message Format) allows anything in a domain-literal which "is interpreted as the literal Internet address of the particular host", but that RFC 2821 (SMTP) does not allow a domain-literal to be used at all and is more restrictive than RFC 2822 on other forms of domains as well.
RFC 2821 is used for envelope addresses in the SMTP dialog, 2822 is used for header addresses. If MTAs want bizarre characters in the recipient addresses, they need to make sure that they get used only in the headers and not the envelope. Where you run into problems is where an address in one format is inappropriately used in the other.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
Brad Knowles wrote:
At 12:54 PM -0700 2004-09-19, Mark Sapiro wrote:
It appears that RFC 2822 (Internet Message Format) allows anything in a domain-literal which "is interpreted as the literal Internet address of the particular host", but that RFC 2821 (SMTP) does not allow a domain-literal to be used at all and is more restrictive than RFC 2822 on other forms of domains as well.
RFC 2821 is used for envelope addresses in the SMTP dialog, 2822 is used for header addresses. If MTAs want bizarre characters in the recipient addresses, they need to make sure that they get used only in the headers and not the envelope. Where you run into problems is where an address in one format is inappropriately used in the other.
Thanks for the clarification Brad. I had missed that concept. The crux here seems to be that since subscribed addresses are ultimately going to end up as envelope to addresses, they need to meet the requirements that RFC 2821 places on the content of RCPT commands, namely they must not contain non-ascii characters or ascii control characters.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi, Mark Sapiro wrote:
Thus, it would seem as a practical matter, Mailman should not accept for subscription any address containing any characters in the ranges \000-\037 and \177-\377. Thus I suggest the following, totally untested change:
--- mailman-2.1.5/Mailman/Utils.py 2003-12-26 14:50:04.000000000 -0800 +++ mailman-mas/Mailman/Utils.py 2004-09-19 12:49:30.000000000 -0700 @@ -198,7 +198,7 @@
# TBD: what other characters should be disallowed? -_badchars = re.compile(r'[][()<>|;^,/\200-\377]') +_badchars = re.compile(r'[][()<>|;^,/\000-\037\177-\377]')
def ValidateEmail(s): """Verify that the an email address isn't grossly evil."""
This patch looks reasonable and will be merged in CVS soon. Also, I wonder if '/' should be removed from this list. It is X.400 char and long have been asked for allowing. My test with postfix looks like to accept at least in aliases and testing with mailman options interface looks OK. (although a little bit uneasy because mailman cgi separates command options with '/' character.)
This still leaves open the question of whether the printable characters in the _badchars RE are the right ones and what to do with quoted-string local-parts, but I think it would prevent my immediate problem from recurring.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Tokio Kikuchi wrote:
Hi,
Mark Sapiro wrote:
Thus, it would seem as a practical matter, Mailman should not accept for subscription any address containing any characters in the ranges \000-\037 and \177-\377. Thus I suggest the following, totally untested change:
--- mailman-2.1.5/Mailman/Utils.py 2003-12-26 14:50:04.000000000 -0800 +++ mailman-mas/Mailman/Utils.py 2004-09-19 12:49:30.000000000 -0700 @@ -198,7 +198,7 @@
# TBD: what other characters should be disallowed? -_badchars = re.compile(r'[][()<>|;^,/\200-\377]') +_badchars = re.compile(r'[][()<>|;^,/\000-\037\177-\377]')
def ValidateEmail(s): """Verify that the an email address isn't grossly evil."""
This patch looks reasonable and will be merged in CVS soon. Also, I wonder if '/' should be removed from this list. It is X.400 char and long have been asked for allowing. My test with postfix looks like to accept at least in aliases and testing with mailman options interface looks OK. (although a little bit uneasy because mailman cgi separates command options with '/' character.)
I would be more than a bit uneasy about removing the '/' from this list
for just that reason. Removing it would allow an address with a '/' to
be subscribed or at least to pass this test before being subscribed.
The problem that comes immediately to mind is what happens to the links
to the user's options page which are of the form
http://server/mailman/options/listname/user--at--domain or
http://server/mailman/options/listname/user@domain when user contains
a '/'?
My gut feeling is that allowing the '/' would involve a lot more work
than just removing it from the _badchars list.
--
Mark Sapiro
Hi,
I would be more than a bit uneasy about removing the '/' from this list for just that reason. Removing it would allow an address with a '/' to be subscribed or at least to pass this test before being subscribed.
The problem that comes immediately to mind is what happens to the links to the user's options page which are of the form http://server/mailman/options/listname/user--at--domain or http://server/mailman/options/listname/user@domain when user contains a '/'?
Problem was that '/' is not allowed to use in cookies. I will generate a patch to fix this and upload in SF for the developers to check.
My gut feeling is that allowing the '/' would involve a lot more work than just removing it from the _badchars list.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
participants (3)
-
Brad Knowles -
Mark Sapiro -
Tokio Kikuchi