Re: I-D Action:draft-newman-email-subaddr-01.txt

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 03 December 2007 09:43 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7qG-0005a3-BR; Mon, 03 Dec 2007 04:43:56 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iz7qE-0005ZB-FL for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 04:43:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7qE-0005Z2-5o for discuss@apps.ietf.org; Mon, 03 Dec 2007 04:43:54 -0500
Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz7qC-0002XX-6r for discuss@apps.ietf.org; Mon, 03 Dec 2007 04:43:54 -0500
Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 452F01C00F4; Mon, 3 Dec 2007 10:43:51 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 409541C00D7; Mon, 3 Dec 2007 10:43:51 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3E7C958ECBE; Mon, 3 Dec 2007 10:43:51 +0100 (CET)
Date: Mon, 3 Dec 2007 10:43:51 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Dave Cridland <dave.cridland@isode.com>
Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt
Message-ID: <20071203094351.GA19449@nic.fr>
References: <E1It5KL-00032t-Up@stiedprstage1.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1It5KL-00032t-Up@stiedprstage1.ietf.org>
X-Operating-System: Debian GNU/Linux 4.0
X-Kernel: Linux 2.6.18-5-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: Apps Discuss <discuss@apps.ietf.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

[No discussion list indicated in the draft, trying the Application
Area general list.]

On Fri, Nov 16, 2007 at 12:50:01PM -0500,
 Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> wrote 
 a message of 97 lines which said:

> 	Title           : Internet Email Subaddressing
> 	Author(s)       : D. Cridland
> 	Filename        : draft-newman-email-subaddr-01.txt

I'm quite puzzled by this draft and I do not really understand what it
normalizes or what its purpose is.

The entire idea of subaddressing is to be a local decision, only the
final MTA and/or its MDA will have to know it. Besides stuff like RFC
3598, there is little room for IETF work. 

Some sentences in the draft are strange, in that respect. For
instance, section 4.2 says "A subaddress-aware gateway or firewall
SHOULD preserve the detail part when rewriting an address." while I
thought that the SMTP rule was much stronger: "DO NOT MESS with
addresses", and that is a general rule, it is not only for
subaddressing.

Apart from that, the draft puts too much emphasis on the most common
"+" (with a MTA like Postfix, it is trivial to change it - the
recipient_delimiter option, and many people do so to avoid the problem
of broken software mentioned later). Again, the IETF should not
mention this separator, since it is a local decision.

Strangely enough, the draft does not talk about *the* big problem with
subaddressing: the fact that many stupid and broken Web forms and/or
mail software do not accept them or do not handle them
properly. Certainly, an informational RFC asking to accept valid email
addresses would be an useful document. See a good start in
http://www.linuxjournal.com/article/9585, specially the conclusion
("There is some danger that common usage and widespread sloppy coding
will establish a de facto standard for e-mail addresses that is more
restrictive than the recorded formal standard.") or in
http://worsethanfailure.com/Articles/Validating_Email_Addresses.aspx
(the comments are interesting, too).