Keith Moore wrote:
My suggestion is that you ask yourself - do you want a parser that
validates email or do you want a parser that is useful for email readers
or do you want a parser that can _correct_ malformed email? It can be
difficult to do more than one of these at the same time.
I believe that correcting errors first requires detecting said errors; i.e.
correcting errors has as a prerequisite a validating parser.
If you want the latter, you generally need to parse things according to
RFC 822 rather than 2822, because 822's grammar is simpler and more
permissive and more representative of what is out there.
In some cases, yes. In other case, RFC 2822 is more permissive. A
disadvantage of RFC 822 is its ambiguities. For example, to take
date-time specification as an example, it could be argued that
RFC 822 permits
1Jan8412:34UT
And it can be argued that it does not permit that.
For instance, dates are often malformed (in a wide variety of
ways), and "." often appears in a phrase before an address.
RFC 2822's parse grammar specifically provides for handling an
unquoted dot in a phrase, and is an example of more permissive
parsing under RFC 2822.