6 ms·

I think many people are thinking about email address validation the wrong way. RFC 822 describes how messages are encoded when email servers talk to each other

by eli 11y ago

I think many people are thinking about email address validation the wrong way. RFC 822 describes how messages are encoded when email servers talk to each other. It isn't really about email address validation and is not intended to be used to validate a form field on some registration page. Unless you're writing an MTA or similar piece of infrastructure there is no reason you should be using the RFC grammar. Even if implementation were easy, it probably isn't what you want. For example, the spec permits inline comments but that's a nonsensical thing to have in the middle of an address you typed into an HTML form. Email addresses entered on a web form should be rejected if they contain comments, IMHO. I think what most developers really want to know is something like: Can this given email address receive messages? Or: Does this given address actually belong to this user? Well, the only way to test that is to send it a message. At best, regex validation might warn you earlier that a given address couldn't possibly work because it's so obviously malformed. But you can't validate your way into getting people to enter their real email address if they don't want to or if they don't know what it is. If your intent is really just to help catch typos and mistakes, you'd be much better off looking to something like mailcheck [0] which will flag common typos like "foo@hotnail.com" even if they result in valid looking addresses. [0] https://github.com/mailcheck/mailcheck https://github.com/mailcheck/mailcheck

saurik 11y ago
I agree with you "100% in spirit", but feel the need to point out that RFC 5322 (822 is ancient...) is for MIME, and thereby isn't what is even used "when e-mail servers talk to each other": it is the format of the e-mail message itself that is used only within a mailbox (when either your client or, if you are using IMAP, your server parses the message). The actual standard used by e-mail servers talking to each other is 5321 (which you might still know 821 ;P), the standard for SMTP: this protocol actually has a different way to write comments and escape characters, as it is embedded into a different structure (which I think decimates the arguments people tend to make that you should validate comments). Years ago I was working quite in earnest on an e-mail server suite, and at the time I was extremely deep in the various standards, and wrote a comment that goes into somewhat more depth on the semantics of e-mail verification. The example I was really happy with is the notion that you would never ask your user to HTML escape their username or password ;P. https://news.ycombinator.com/item?id=4486872 https://news.ycombinator.com/item?id=4486872
huuu 11y ago
I very much agree because in the end the only validation seems to be "does it contain a @ character somewhere in the middle". For example: example@localhost is valid but is refused by most validators.
- maweki 11y ago
  Localhost is obviously not a fully qualified domain name which would be expected in any internet setting.
  - hcf 11y ago
    Top level domains do resolve though, email@bs is completely legal to try to send email to.
lmm 11y ago
> Email addresses entered on a web form should be rejected if they contain comments, IMHO. Why? I use several addresses that start something like myfirstname.mylastname@... . A comment at the start could make it much easier for me to use browser autofill. (Arguably that's "really" a browser UX issue, but we work with the tools we have)
xenophonf 11y ago
I really hate browser- or webapp-side email validation. I've rarely seen a web developer get this right. My advice is to treat email addresses like blobs and attempt delivery with a confirmation link. That will catch users who typo their own address, and it will let people use whatever address format they want (the "+" in an email address not being considered valid is my own personal bugaboo).
- jgalt212 11y ago
  I dunno. I think people with edge case emails (i.e. those not easily validated with a simpleish regex) should be nudged towards getting more standardized emails. Our company won't accept weird emails for free trial sign ups. We should be nudging users towards good behavior. Of course, if your email address is provided at the corp level, then you don't have as many options. Non-standard emails can be used as tools for phishing is another reason why we should not validate them.

by eli 11y ago

saurik 11y ago

I agree with you "100% in spirit", but feel the need to point out that RFC 5322 (822 is ancient...) is for MIME, and thereby isn't what is even used "when e-mail servers talk to each other": it is the format of the e-mail message itself that is used only within a mailbox (when either your client or, if you are using IMAP, your server parses the message). The actual standard used by e-mail servers talking to each other is 5321 (which you might still know 821 ;P), the standard for SMTP: this protocol actually has a different way to write comments and escape characters, as it is embedded into a different structure (which I think decimates the arguments people tend to make that you should validate comments). Years ago I was working quite in earnest on an e-mail server suite, and at the time I was extremely deep in the various standards, and wrote a comment that goes into somewhat more depth on the semantics of e-mail verification. The example I was really happy with is the notion that you would never ask your user to HTML escape their username or password ;P. https://news.ycombinator.com/item?id=4486872 https://news.ycombinator.com/item?id=4486872

huuu 11y ago

I very much agree because in the end the only validation seems to be "does it contain a @ character somewhere in the middle". For example: example@localhost is valid but is refused by most validators.

maweki 11y ago
Localhost is obviously not a fully qualified domain name which would be expected in any internet setting.
- hcf 11y ago
  Top level domains do resolve though, email@bs is completely legal to try to send email to.

lmm 11y ago

> Email addresses entered on a web form should be rejected if they contain comments, IMHO. Why? I use several addresses that start something like myfirstname.mylastname@... . A comment at the start could make it much easier for me to use browser autofill. (Arguably that's "really" a browser UX issue, but we work with the tools we have)

xenophonf 11y ago

I really hate browser- or webapp-side email validation. I've rarely seen a web developer get this right. My advice is to treat email addresses like blobs and attempt delivery with a confirmation link. That will catch users who typo their own address, and it will let people use whatever address format they want (the "+" in an email address not being considered valid is my own personal bugaboo).

jgalt212 11y ago
I dunno. I think people with edge case emails (i.e. those not easily validated with a simpleish regex) should be nudged towards getting more standardized emails. Our company won't accept weird emails for free trial sign ups. We should be nudging users towards good behavior. Of course, if your email address is provided at the corp level, then you don't have as many options. Non-standard emails can be used as tools for phishing is another reason why we should not validate them.