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

[Randall Gellens <[e-mail]>]

At 10:43 AM +0100 12/3/07, Stephane Bortzmeyer wrote:

>  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.

Currently, subaddressing is mostly part of the mostly undocumented 
email lore that some implementers are aware of while others are not. 
Formalizing the concept is a good thing.  It would still be a purely 
local decision to use it or not, and indeed to define what it means. 
But having a common basis for information seems helpful to me.

Also, the advice for mailing lists to ignore the detail, and the 
Security Considerations text on command-line handling, seem useful. 
The mailing list issue argues for a standardized character, but the 
prevalence of broken web forms argues against it.

>  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.

I think a gateway or firewall that rewrites addresses (or in any way 
alters the mail) is, by definition, within the local delivery domain, 
and hence the 2821 rule doesn't apply.  It is permitted to do as it 
pleases.  Given the widespread ignorance of user-detail addresses, it 
seems helpful to have something to point to that tells these boxes to 
preserve this.

>  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.

Mentioning it, with examples, is probably a good thing, since it can 
help gain understanding.  The text shouldn't dictate the specific 
character, though.  Perhaps the text in Section 1, for example, that 
currently says

    In general, deployed forms of subaddressing divide the local-part of
    an email address into two strings, seperated by a delimiter
    character.  This is most commonly a plus sign, "+".

    This document does not document all forms of subaddressing, merely
    the most common form, also known as "plus-addressing".  Other forms
    are also deployed, sometimes using a minus sign, and in some rare
    cases using encoding rules rather than simple catenation.

Could be changed to

    In general, deployed forms of subaddressing divide the local-part of
    an email address into two strings, seperated by a delimiter
    character.  This is most commonly a plus sign, "+".

    For clarity, the examples in this document all use the "+" (which is also
    known as "plus-addressing".  Other forms
    are also deployed, sometimes using a minus sign, and in some rare
    cases using encoding rules rather than simple catenation.

And then change non-example uses of "+" to "the delimiter".  Also add 
"the delimiter" to the Definitions, and fix the ABNF to allow other 
safe characters that aren't "%" as the delimiter.

Maybe it should also suggest NOT using "%", since many systems treat 
the presence of this character in the local-part as an attempt to 
relay and hence an attack.

>  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.

Yes, this is a major problem.

>   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).

This is useful, but separate.  (Also, wasn't this done a few years ago?)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If A = B and B = C, then A = C, except where void or prohibited by law.