Why does Text.Email.Parser call a parser on its intermediate results? about email-validate-hs HOT 5 CLOSED

/me waves from afar

from email-validate-hs.

The reason for this is that the email-address RFC (5322, section 3.4.1) specifies a really loose definition for domain names, so things that the email-address RFC says are valid might not really be a valid domain.

To fix this I've added a parser for domain names that is run on the result of the domain-name parse to ensure that it really is valid by the domain name RFC(s). (Note that this is not yet in a shipped version—since the change is not technically backwards-compatible & I haven't quite decided what to do with it yet...)

The reason it's not simply using the domain name parser instead is that the email-address parser performs some canonicalization as a "side-effect" of parsing—it strips out comments and something called 'folding whitespace' (collectively 'CFWS'). These are valid in the input email address but not in the resulting domain name.

Specifically, if one wanted to re-write the whole domainName parser to not use an inner parse, would that be possible in some way while giving correct results?

It would be possible to fold in the domain name parsing with the email-address version to come up with a parser that handles the CFWS, but I haven't done this yet as it was easier to show that the domain-name handling is correct when done in this manner.

To remedy this I should really just write the combined version, add some quickcheck properties to check that it does the same thing as the two-stage parse, then delete the old one 😄

from email-validate-hs.

I think I'll have some time tonight to look at this.

from email-validate-hs.

Made the change, want to add a few more tests & I'll push it tomorrow.

from email-validate-hs.

Finally pushed this...

from email-validate-hs.