RFC 2822 strict

[bcardarella]

Nearly all of the issues that have been opened up recently are related to relaxing the RFC 2822 parser, which makes sense because there are so many implementations that go outside the spec. However, I feel strongly there is also a need for a strict parser for certain use-caes. I think we should support a strict: true parser option that will strictly enforce the spec. The default should be permissive as the module has moved toward as this is where more of the use-cases will be.

@andrewtimberlake thoughts?

[andrewtimberlake]

I disagree. Many of the latest fixes have been bug fixes in incorrect handling of certain RFCs.
The only relaxed handling we support is in date parsing, which seems to be the most loose part of email encoding.
Also, while elixir-mail is based on RFC 2822, technically that RFC is a replacement of RFC 822, and is itself an obsolete RFC that has been replaced by RFC 5322
Also there are multiple other RFCs that have to come into play in correctly handling email (like RFC 2047 for encoded words, RFC 2046 for mime)
If I‘ve missed this, can you point to the places where elixir-mail has become relaxed outside of date handling?

From my point of view, and this is similar to HTML, an email parser should be able to parse any email found on the internet and produce a sane working result.
On the other hand, an email encoder should follow strict rules to the letter.
I think we should have a relaxed parser and a strict encoder.

What use cases do you think we need a strict parser for? If we do this, then we need a good way of reporting failures that always point back to the spec—I personally don’t think this is worth it.