171–180 of 211 posts
A basic regex is more than enough and you don't even need to deliver a message, just connect to the MX for their domain and check that A) The domain resolves an MX and B) That you can handshake for a 250 OK on the rcpt to header only, then drop the socket. Done! It's not that slow and you're leveraging the one thing an SMTP server does really well - be RFC822 compliant. It's something that can be delegated out of pro…
I don't think this is good advice. From a previous startup we saw a ton of signups like, "john@gmail" and the like. Obviously this person will not get a validation email -- and in all likelihood will not be able to log in to his account when he returns. It's best to catch him when he's entering the information.
I love these articles that are posted and the ACCURATE answer is that the article proposes bad advice. In what world is not validating an email a good thing? It's not like emails vary after a certain complexity is reached. A better article would have been someone documenting a validation regex that approaches perfect without exceeding insane complexity. Next we'll see articles to not run the Luhn algorithm on credit…
Validating an email address is important. The way you do that is send an email to that address. You can't do it with regex, and attempting to do so leaves you open to a variety of flaws.
Earlier quoted context omitted.
Again, what material difference does it make to you? Overzealously rejecting valid addresses is an application of subjective and inaccurate ideas about what addresses 'should' look like, and ignores the simple fact we've already mutually and formally defined valid address formats via the IETF RFCs.
> Again, why does this matter to you, other than some sort of misplaced sense of authoritarian aesthetics? Yes! Great Comic Book Guy impression. Why it matters is that for most smallish companies, you want to get something up that helps your users not do stupid stuff (†), but due to time and resource constraints, you're likely to end up with some kind of 80/20 solution. It'll work well in most cases, and fall down in…
In that case, great junior engineer impression on your part.
Pedantry matters in complex interoperable systems, because otherwise they're not interoperable. This is why we have detailed standards documents on e-mail address formats.
> I would certainly agree with the idea that you not force people, but a nudge is probably going to save you money in increased user retention and fewer support hassles.
A 'nudge' isn't going to come from yet-another-broken-email-validation regexp. There's no need for an 80/20 solution; this just isn't that hard.
> † - I once had a person ask why their emails to http://somesite.com were failing.
That's not a valid e-mail address (as per RFC822).
Earlier quoted context omitted.
> because some tester opens a ticket saying you can enter an invalid email in the email field? This is the source of 80% of all "bugs" I've fixed over the years. Another personal favorite: If you enter WWWWWWWWWWWWWWWWWWWW W WWWWWWWWWWWWWWWW for name, it messes up the layout on the display screen.
That's roughly 40 chars ? People coming from some regions easily have 20 to 30 chars for the family name alone [1]. That's more or less the length of our test string if the add the given name(s). [1] http://news.bbc.co.uk/2/hi/africa/5651310.stm
Earlier quoted context omitted.
Hopefully that's not the SMTP syntax you're actually using. * There's no space between FROM: and the address in SMTP * Email addresses must come between angle brackets I'd reject (give you a 5xx) that from my mail server for those reasons alone.
> Hopefully that's not the SMTP syntax you're actually using. I typed it out live. I'm not an SMTP client and I don't have the RFCs memorized. > I'd reject (give you a 5xx) that from my mail server for those reasons alone. Postfix accepts it. I haven't checked the RFC to verify your concerns, but assuming they're correct, then my expectation is that postfix is liberal in what it accepts because A) it's a good idea, a…
Earlier quoted context omitted.
Honestly if the user is signing up with an ip email then you really shouldn't accept it - it may be valid but something fishy is going on for sure.
Why does it matter? If I managed to acquire the 8.8.8.0/24 netblock, I might very well want to use 'user@8.8.8.8' as my e-mail address. I don't see why it has any material affect on someone requesting e-mail addresses: if it's valid, then it's valid. This seems to be an example of the misplaced sense of propriety with which people approach validating e-mail addresses -- that somehow, your job isn't just to help the u…
This has come up so often on Hacker News that I decided to create a very simple JSON API for checking email addresses. Free to use for anyone. Performs the right regexp check for email addresses based on RFC-5321 rules (not the oft-quoted but incorrect RFC-822 rules, which are for mail headers), performs MX lookups to ensure mail can be delivered, and performs the same "did you mean" type checks that kicksend's mailc…
This has come up so often on Hacker News that I decided to create a very simple JSON API for checking email addresses. Free to use for anyone. Performs the right regexp check for email addresses based on RFC-5321 rules (not the oft-quoted but incorrect RFC-822 rules, which are for mail headers), performs MX lookups to ensure mail can be delivered, and performs the same "did you mean" type checks that kicksend's mailc…
My goto for email validation is /^.+?@.+?\..+?$/ Incase I've typed it wrong, that should basically work for anything that contains at least one @ and one dot, in that order, as well as at least one character at beginning, middle and end. It's served me well thusfar. Edit for clarification: The reason I prefer this over just checking for an @ is that if you're just checking for @ a common mistake like "me@hotmail,com"…
My favorite: /.\@.*\../ It should be similar to your version, but only matches just enough parts that require for email validation (i.e. "o@example.c" part of foo@example.com).