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

Dave Cridland <> Wed, 19 December 2007 17:38 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1J52se-0006r9-Jk; Wed, 19 Dec 2007 12:38:52 -0500
Received: from discuss by with local (Exim 4.43) id 1IzJiK-0003wp-Ug for; Mon, 03 Dec 2007 17:24:32 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IzJiK-0003wU-Kd for; Mon, 03 Dec 2007 17:24:32 -0500
Received: from [2001:838:378:0:211:9ff:fe2c:e28e] ( by with esmtp (Exim 4.43) id 1IzJiF-0008UK-Kz for; Mon, 03 Dec 2007 17:24:32 -0500
Received: from ([]) by (submission) via TCP with ESMTPA id <>; Mon, 3 Dec 2007 22:24:04 +0000
X-SMTP-Protocol-Errors: PIPELINING
Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <>
Date: Mon, 03 Dec 2007 22:24:03 +0000
From: Dave Cridland <>
To: Stephane Bortzmeyer <>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
X-Mailman-Approved-At: Wed, 19 Dec 2007 12:38:51 -0500
Cc: Apps Discuss <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Mon Dec  3 09:43:51 2007, Stephane Bortzmeyer wrote:
> [No discussion list indicated in the draft, trying the Application
> Area general list.]
As good as any.

> I'm quite puzzled by this draft and I do not really understand what  
> it
> normalizes or what its purpose is.
Subaddressing isn't described anywhere, much - the closest we come is  
in the SIEVE subaddress extension. This is fine - as you say, it's a  
purely local thing - except that multiple components are involved.  
 From an inter-domain perspective, there is nothing to do - unless  
you consider mailing list managers - but for the communications  
between the components of an MHS, there are several areas which would  
benefit from a consistent handling of subaddressing.

> 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  
> 3598, there is little room for IETF work. 
No, every component needs to know about it.

1) The final MTA.
2) The MDA.
3) The MUA.
4) The Submission server.

The behaviour of all of these, and in particular how they interact,  
most certainly is within the scope of the IETF.

> 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.
Oh, indeed, there's lots of sentences which were much more useful a  
decade ago, and these days are surplus to requirements.

> 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.
Now here I disagree - a common syntax for subaddressing isn't  
absolutely required from a technical perspective, but it makes  
considerable sense for subaddress-aware entities to have the same  
general notion of what syntax to use, to reduce configuration  
requirements, both for sysadmins and users alike.

> 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
>, 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
> (the comments are interesting, too).

You're not the first to raise this, but I'm not convinced that this  
draft is the right place to give such advice. It would, however, be a  
useful place for such a draft to point to by way of example.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade