Dusting off this particular bit of ancient history...
--On Wednesday, 17 October, 2007 09:46 -0700 Pete Resnick
<presnick(_at_)qualcomm(_dot_)com> wrote:
I've copied this conversation over to ietf-822, since I think
that will probably be where this issue is addressed.
On 10/17/07 at 6:51 AM -0700, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Peter J. Holzer wrote:
Which reminds me: What is the reason for allowing control
characters in email addresses?
Idiocy.
I try hard to stay out of these sorts of debates, but in this
case I am forced to agree. We are way past the point where
backwards compatibility is an acceptable excuse for
something like this. It should be obvious why allowing
nonprinting control characters in addresses is a bad idea on
many levels.
And if common sense isn't enough here, how about the fact
that it is pretty clear that these things have obvious and
severe interoperability problems that will make it hard to
meet the criterua for draft standard?
Right now, control characters are allowed in the following:
- Domain literals on the right hand side of addresses
This is the one that affects 2821bis. The control characters
cannot appear in either IPv4 address or IPv6 address domain
literals. They can, in principle, appear in General Address
literal, but those require standards track action, etc., and one
could easily cut them off there. In other words, they are
permitted in principle, but prohibited in practice and are going
to stay that way. It is therefore probably safe to let this
go.
I'm not going to do any for the version of 2821 that I intend to
post later tonight, but, if there is consensus that it is time
to do away with the puppies (and I am very much in agreement
with Ned that they should go), it may be time to invent a new
metalanguage rule for, e.g., "pcontent" (for printable) which
consists of characters in the ASCII range from 20 to 7E (hex).
Looking ahead to i18n issues, it may be desirable to have a
similar rule for Unicode characters, but the characters can't be
enumerated (in practice and to preserve version-independence) so
the rule would have to be defined in terms of character class
and properties.
- Quoted strings (which can be on the left hand size of
addresses as well as lots of other structured header fields)
The address part of this is a little more problematic than the
case above, but also easier, under the "you can screw only
yourself by putting one of those addresses up on your server"
principle.
The rest of this is, indeed, a 2822 problem.
- Comments (which can appear in lots of structured header
fields including address fields)
- Unstructured text (in fields and in the body)
john