Properly parse FROM email headers with colon, comma characters about email-addresses HOT 3 CLOSED

Are these not parsing properly because they don't meet the RFC 5322 standard?

I believe this is correct. The name before angle brackets is produced by an atom rule, and the comma cannot appear in an atom.

   atom            =   [CFWS] 1*atext [CFWS]
   specials        =   "(" / ")" /        ; Special characters that do
                       "<" / ">" /        ;  not appear in atext
                       "[" / "]" /
                       ":" / ";" /
                       "@" / "\" /
                       "," / "." /
                       DQUOTE

      Note: The "specials" token does not appear anywhere else in this
      specification.  It is simply the visible (i.e., non-control, non-
      white space) characters that do not appear in atext.  It is
      provided only because it is useful for implementers who use tools
      that lexically analyze messages.  Each of the characters in
      specials can be used to indicate a tokenization point in lexical
      analysis.

That said, if you knew for certainty that you were parsing a single address (where a comma should not appear as a tokenization point), you could escape the comma with a unique string and then unescape in the resulting output without too much difficulty.

from email-addresses.

hlian is right, but I'd also say "or they have to be quoted". The "display name" portion of an email address can be made up of words, which can only contain commas if they are quoted strings. So iZotope, Inc. <[email protected]> doesn't parse but "iZotope, Inc." <[email protected]> does.

It may be the assumption of the data (against the RFC) that since this is a single email address, it can drop the quotes. There's many imaginable hacks to get around that. For instance, if the email doesn't have a quote in it, but does have an angle bracket, start with a quote and replace '<' with '"<'. Unfortunate.

from email-addresses.

Thanks for the responses. An app using the library can definitely take some of the scrubbing/cleanup actions you're describing before parsing, but it'd be great if the lib had something like a standardize(address) or something similar that could either be called before attempting to parse or automatically included as part of the parse.

There's a certain elegance to this library that I can pass reasonably sensible headers to it and it just works, but having to precondition all of the data makes that feel a little kludgy.

This is all nit-picking, though... thanks for the responses! :-)

from email-addresses.