131–140 of 211 posts
We use this clever (and well-explained) solution from http://my.rails-royce.org/2010/07/21/email-validation-in-rub...
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 think it's great advice; remember, the advice is: Stop Validating Email Addresses __With Your Complex Regex__. Remember that new TLDs are added, and that john@tld can actually be entirely valid. If you want to prevent "john@gmail", then use a real RFC-compliant e-mail address parser, and attempt to resolve the domain component MX/A records (and remember, it might be an IP address). If that fails (or your regex fail…
Bingo. Help people, don't hinder them.
Earlier quoted context omitted.
I'd say nothing of value is lost in that case. These people are very costly to support. Email has been in common use for at least 20 years. They need to step up to the plate and learn at this point.
might I remind you one of the reasons why Apple have posted record profits over the last decade? It's worth nailing the UX experience to be as inclusive as possible. It's also worth considering that one of the biggest generational markets (baby boomers) include a lot of those people you're telling us to ignore.
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.
> This puts the burden of checking email validity on every user, even perfectly capable valid users. ? 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.
:(
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.
First you verify the email, then you process the emails. What good is a list of email addresses if you haven't verified their authenticity?
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…
to ensure it is deliverable? Well, then you better send them an email. I deal with user support for a site and I'd estimate at least 2% of our new users (>50 people PER DAY) enter wrong email addresses. Not "I forgot to put .com at the end" but "I thought my email was john.doe@gmail.com when it's actually john.doe@yahoo.com" which would pass validation with flying colours. The only real "solution" is to tell a user i…
Couldn't an unscrupulous individual use that feature to take over non-activated accounts? An immediate use for that exploit doesn't spring to mind but this makes my spidey sense tingle. What sites allow this?
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 think it's great advice; remember, the advice is: Stop Validating Email Addresses __With Your Complex Regex__. Remember that new TLDs are added, and that john@tld can actually be entirely valid. If you want to prevent "john@gmail", then use a real RFC-compliant e-mail address parser, and attempt to resolve the domain component MX/A records (and remember, it might be an IP address). If that fails (or your regex fail…
That's just me.
Earlier quoted context omitted.
I think it's great advice; remember, the advice is: Stop Validating Email Addresses __With Your Complex Regex__. Remember that new TLDs are added, and that john@tld can actually be entirely valid. If you want to prevent "john@gmail", then use a real RFC-compliant e-mail address parser, and attempt to resolve the domain component MX/A records (and remember, it might be an IP address). If that fails (or your regex fail…
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.
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 user enter an address, but also to define what is and is not 'reasonable'.
Imagine if companies refused to accept "1 Infinite Loop" as a street address because it's clearly ridiculous. Except that it's Apple's actual street address.