Re:Validating email addresses: A journey down RFC5321 [video]
by StavrosK on Monday February 12, 2018 @08:54AM
(#16358515)
Can you clarify on what CFWS is? I found what the acronym stands for, but not what it actually means.
Re:Validating email addresses: A journey down RFC5321 [video]
by jcranmer on Monday February 12, 2018 @08:58AM
(#16358541)
Comment-folded whitespace. It's the little things in parentheses (e.g., the timezone name is usually included in a comment in the Date: header). It's also the bane of anyone who has ever implemented an email message parser.
Re:Validating email addresses: A journey down RFC5321 [video]
by StavrosK on Monday February 12, 2018 @09:03AM
(#16358573)
That makes sense, thank you.
Re:Validating email addresses: A journey down RFC5321 [video]
by IIIIIIIIIIIIIII on Monday February 12, 2018 @09:00AM
(#16358553)
This StackOverflow replay happens to answer this question exactly, the actual definition of "CFWS" is near the bottom of the text:
https://stackoverflow.com/a/42193413/544779
It's just an excerpt of the spec, but I link to it instead of to the spec because I think it's easier to read (formatting/colors) and it has links to the spec anyway.
Re:Validating email addresses: A journey down RFC5321 [video]
by StavrosK on Monday February 12, 2018 @09:03AM
(#16358571)
Ahh, thank you, I missed that part of the spec. The "folding" part was what confused me, thanks again.
Re:Validating email addresses: A journey down RFC5321 [video]
by inopinatus on Monday February 12, 2018 @01:20PM
(#16360614)
> Sending someone an email and telling them to confirm that they received it (e.g., by making the next step be triggered from a link in the email) is the only way to validate that an email address actually works.
This is the gold standard but note it is itself prone to false negatives and can even have false positives.
* Just say no to CFWS. CFWS is not legal in an email address, and anyone who tells you otherwise is incapable of reading the standards. CFWS is legal to insert in the written representation of the email address in RFC 5322 and RFC 5321, but it is not a structural part of the email address (you get the email address by deleting all such instances).
* Everything to the right of the @ is either a domain name, an IPv4 address literal embedded in [], or an IPv6 address literal prefixed with IPv6: and embedded in [] (e.g., [IPv6:::1]).
* Enclosing a localpart in quotes does not change the email address. Ergo, you can require that people not use quoted localparts if they don't have to. Actually, in general, you can probably require that people not have quoted localparts at all.
* The only characters truly forbidden from email addresses are C0 (and maybe C1, although the EAI specs are hazy about that). In practice, though, any character that requires quoting to access can probably be excluded from valid email addresses.
* Sending someone an email and telling them to confirm that they received it (e.g., by making the next step be triggered from a link in the email) is the only way to validate that an email address actually works.