61–70 of 211 posts
I agree with the author of this blog, but he doesn't address the problem where you want to scrap all the email addresses in a text file. For this situation, I don't see what to use except regexp.
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).
The question is why people are validating the email in the first place. * to ensure it is deliverable? Well, then you better send them an email. * to let people know when they misread the labels and put something that was clearly not an email in the email field? A simple check for an at-sign is usually sufficient. * because some tester opens a ticket saying you can enter an invalid email in the email field? Yeah, tha…
If you really want to do checking of email addresses right on the signup page, include a confirmation field so they have to type it twice. No. This puts the burden of checking email validity on every user , even perfectly capable valid users. If you're validating for edge cases (mistakes or otherwise invalid addresses), treat it as an edge case and don't annoy users who can type.
? Whenever I hit a form which wants me to retype my address, I just triple-click to select the entire address, then middle-click to paste it into the confirmation field.
Earlier quoted context omitted.
I thought new TLD being worked on didn't need to have dots in them. Why not just check for x@x?
That's exactly what you should do. ^(.+)@(.+)$ max length is 254 according to the RFC I believe, so you can check for that too.
The question is why people are validating the email in the first place. * to ensure it is deliverable? Well, then you better send them an email. * to let people know when they misread the labels and put something that was clearly not an email in the email field? A simple check for an at-sign is usually sufficient. * because some tester opens a ticket saying you can enter an invalid email in the email field? Yeah, tha…
* Because users often miss a character like a dot or an @, and catching that early saves a lot of pain with undelivered confirmation e-mails and so on.
I actually think that this library functions as a really great client-side validation that won't get you tripped up in trying to be RFC compliant. There's really not anything more that I'd do aside from sending that blessed confirmation email.
I don't validate emails at all. If you want to enter 'a' that's fine but you won't get any emails.
Some people use many email addresses and so could create many accounts. With one email address they can still use the '+blahblah' method to sign up unlimited times, unless you prevent that which would annoy people who use it legitimately for filtering.
Some people have a garbage or throwaway email account that they sign up for everything with, and only ever look at to find the confirmation emails.
If people don't want to give you a valid email then there's no reason to be sending them anything.
1) use LPeg or something similar to validate the actual text of the email (here's some LPeg that parses the headers of an email, certain one can pull out the email address portion: https://github.com/spc476/LPeg-Parsers/blob/master/email.lua).
2) Take the domain part and do a DNS MX lookup on it (to be pedantic, if that fails, then one should do a DNS A lookup). That will check if the domain is at least valid.