141–150 of 211 posts
Earlier quoted context omitted.
That's exactly what you should do. ^(.+)@(.+)$ max length is 254 according to the RFC I believe, so you can check for that too.
IIRC, last I checked max length was 320.
http://stackoverflow.com/questions/386294/what-is-the-maximu...
Turns out the 320 value was actually incorrect, its 256 but the mailbox is wrapped in square brackets, so 256 - 2 = 254.
Earlier quoted context omitted.
Because it takes system resources to deliver email. Furthermore, if people make a simple typo, why go to the extent of attempting to send something to it when it's obvious?
Because it's not obvious. Ask developers to recite the rules for correct email address, and most of them will get it laughably wrong. I blame the standard, which is far more "featureful" than is actually required, but that is the way it is.
We need a much more restrictive standard for emails, but until we have that we have to accept that each site will have a competing not-completely-overlapping set of standards. So make sure your email doesn't attempt to do anything too funny.
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).
You are only trying to catch email addresses that are entered in error at account creation time so that a user will actually get the confirmation email.
The actual problem is that if they enter an email address incorrectly they will crate a dead account that they can never log into again. In addition if they used their favorite user name, or a referral code or any other important consumable when creating the account then you've effectively blocked that user from even creating a second account.
The real solution is to use validation email to confirm an email address, but to allow them to login to the account even if the email is not yet validated. You won't even have to make them type it in twice. Simply limit them to only being able to edit account information and settings.
Email is validated, users have a window to correct any issues and you've eliminated the unrecoverable error altogether... oh and no regex.
Earlier quoted context omitted.
I'll admit I hadn't considered IPv6b addresses, might have to rethink my trusty regex. Sad, it's served me well for so many years.
IPv4 also has a valid decimal representation. http://1249764136/ will send you to Google!
I wonder what the security implications of this is.
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 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.
Earlier quoted context omitted.
> misplaced concern for users that they believe can't type their own e-mail address How is this misplaced? People screw up even the most basic of computer tasks all the time.
1) Because the solutions actually prevent some users from typing their actual e-mail address. 2) There are so many ways to get the e-mail address wrong that it's almost not worth bothering validating the few things that you can validate. Now, here's what would be an interesting validation method that doesn't actually require sending an e-mail. It requires an RFC-compliant e-mail parser, not a regexp: - Perform A/MX l…
Earlier quoted context omitted.
Because it's not obvious. Ask developers to recite the rules for correct email address, and most of them will get it laughably wrong. I blame the standard, which is far more "featureful" than is actually required, but that is the way it is.
So don't attempt to register an email with comments in it, or for that matter with an ip host. We need a much more restrictive standard for emails, but until we have that we have to accept that each site will have a competing not-completely-overlapping set of standards. So make sure your email doesn't attempt to do anything too funny.
So while I agree with you in principle, in practice it seems infeasible. The differences bite in practice, unfortunately.
Assuming that running the regex is much faster than sending an email, it would probably be much less server load to check the regex and never send X% of emails, unless X is extremely small. (Looking up and implementing a regex) * 1 + (running the regex) * (every email) + (sending email) * (every valid email) Also, this post only considers the signup/activation use case. If you're getting an email for ecommerce to sen…
This assumes that you get the regex 100% right and never lose a user by rejecting a valid email address. This is much harder than it seems ( http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html ), and is no guarantee an valid email address that is in use, as the article makes clear. After some very basic checks, e.g. "contains at at least 3 chars, one of which is an @", you should Just. Send. The. Email. Who bother…
Earlier quoted context omitted.
1) Because the solutions actually prevent some users from typing their actual e-mail address. 2) There are so many ways to get the e-mail address wrong that it's almost not worth bothering validating the few things that you can validate. Now, here's what would be an interesting validation method that doesn't actually require sending an e-mail. It requires an RFC-compliant e-mail parser, not a regexp: - Perform A/MX l…
That won't really work with people who mistype domains, e.g gmale.com as that domain may have catchall enabled.