Valid Email Addresses

Re:Valid Email Addresses by haberman on Friday November 30, 2012 @09:24PM (#4856579)

Thanks for the clarification, I did not realize that there are multiple parallel RFC tracks that define differing syntax and semantics of email addresses. Your claim then, is that all of the complicated syntax defined for email addresses in RFC2822 and RFC5322 is for the sole purpose of escaping characters that are significant to MIME? What about "+" -- is it just convention that most email hosts ignore everything to the right of that, or is that actually specified somewhere?

[ Parent | on HN ]

Re:Valid Email Addresses by saurik on Saturday December 01, 2012 @05:39AM (#4857321)

Yes: that is just convention. In fact, RFC5233 defines an extension to Sieve (a purposely-not Turing-complete language for filtering e-mail that is implemented as part of many mail systems) that parses those + addresses; this is the only e-mail-related standard I've so far come across that mentions this common feature (and I've read through numerous at this point ;P).

However, it does not define the syntax for + addresses (even so far as to define the "+"), as + is only a convention (as is the entire concept of having detailed/sub-addressing at all): it even has various examples, such as "5551212#[email protected]", that use alternate characters.

> NOTE: Because the encoding of detailed addresses are site and/or implementation specific, using the subaddress extension on foreign addresses (such as the envelope "from" address or originator header fields) may lead to inconsistent or incorrect results.

> Implementations MUST make sure that the encoding method used for detailed addresses matches that which is used and/or allowed by the encompassing mail system, otherwise unexpected results might occur. Note that the mechanisms used to define and/or query the encoding method used by the mail system are outside the scope of this document.

Also, yes: RFC5322 defines a ton of syntax, and all of that syntax is related to MIME headers; a "structured header" has particular rules related to whitespace and is allowed to contain comments, so e-mail addresses included as part of the address lists used in headers like To and From are going to be adapted to follow those rules.

FWIW, RFC5322 actually has a SHOULD NOT on the things that make it un-similar to the SMTP specification. The two specifications really do attempt to use fairly similar syntax. You thereby are allowed to have comments and crazy whitespace in weird places in MIME, but "please don't" ;P.

> Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.

The goal really did seem to be, I will happily admit, to have the two protocols be largely compatible to the extent that they could: the same list of reserved characters is used by both (as a key example, SMTP also doesn't allow the ()'s despite not supporting MIME comments). There are some weird differences, like RFC5321 allowing empty double-quotes as the local part; although, RFC821 did not seem to have that corner case, so I'm starting to think this is bug introduced in RFC2821 (I had read mailing list posts about this issue a while back, but somehow it wasn't clear from those that it is a mistake).

I maintain, though, that it is very weird to be forcing this particular escape sequence set everywhere: when you lift e-mail addresses out of angle addresses and lists you don't need it anymore, as you can parse the address from the right unambiguously once you hit the @. Regardless, I do need to emphasize the statement in one of the earlier versions of my comment that RFC3696 has recommendations for e-mail address validation, and it includes the MIME escaping. I thereby doubt that my opinion, to be explicit, is shared by some of the people who worked on these specifications.

(That said, RFC3696 is weird... it mentions, for example, a limit of 64 characters on a username, but in fact that was just a "minimum maximum" from SMTP, and SMTP was quite clear that "TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH OF THESE OBJECTS SHOULD BE USED", while at the same time saying that you must not send such things; I guess "welcome to Postel" ;P.)

[ Parent | on HN ]