- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Admin
Funny thing that E-Mail addresses like
MyEmail@[email protected] seem to be valid by the above code... (More funny that nobody pointed that out so far)
Admin
TRWTF is that there's not much point in validating the syntax of the email address closely because that doesn't prove that the email address actually exists, let alone that it is the correct one.
if someone makes a mistake typing in an email address, most of the time what they actually type will be a valid email address and will either bounce or go to the wrong person
Admin
Admin
How do you think I'm configuring my dependency-injection framework? Lot's of lovely XML there ...
Admin
Actually why would you bother to even do this. Why would you want a developer who wouldn't know to look up the relevant RFC writing your app anyway?
Admin
Seems to me about the only way of finding out for sure if an email address is valid (but not necessarily real) is to an nslookup on the host portion. Of course if your code waits 30 seconds for the resolution to time out then . . .
As a side note, one nice thing about LotusScript (I'll wait for all the Lotus Notes jokes to die down before continuing) is that you can use "", {} or || as string delimiters, so including " in your string is easy. Very handy when writing HTML codes.
print {Hello World!}
Admin
The dev who has to clean this up in a few years cares. As does the dev who has to work on the 400 bugs generated by the shit code.
Admin
A dev who uses the RFC standard instead of the PHB standard is not long for most jobs.
Admin
Not sure if serious.
Admin
They may be stupid, but they are also wrong. '+' SHOULD be allowed.
Admin
Andrew completed his functional design document detailing valid email address requirements - the address must contain an "@" symbol, must include a domain name, alphanumeric characters only, and punctuation like underscores, hyphens, periods are all OK
Andrew sounds exactly like the kind of tool who thinks he is clever for incorrectly specifying how to solve a problem that was fixed back in the 80s. No need to know anything, just spout shit and hope it sticks - much like his equally inept "remote coding team".
Admin
Well, I'd say "often easier", not necessarily "always".
Like if your function won't work with a quote mark but will work with any other Unicode character, it's sure easier to say char!='"' then char=='a' or char=='b' or char=='c' or ... or char=0x128 or char=0x129 or ... etc
Or if you accept user ids of any length except 9, it's easier to write len!=9 rather than len==1 or len==2 or len==3 ... or len==8 or len==10 or ...
Admin
If you really absolutely need to be sure that the email is real, sure.
But for most purposes, sending the user an email and requiring a response is an unnecessary pain. We have to write code to create the emails, and then more code to receive the replies and update the database that this email is now confirmed. More important, the user has to reply to our email. Are we going to hold up processing his order until we get the email response? What if he never replies to the email? We could be losing an order, i.e. money, just because the user forgot to respond to the email or decided it was too much trouble or deliberately gave us a wrong address because he doesn't want to receive spam. If the purpose of collecting the email was just so we could send him order status messages or future advertising, do we want to lose an order for that? Etc.
By the same reasoning, you could say that if we ask for a phone number, instead of validating format we should call the number and make sure someone answers. Or that if, say, a web site that sells auto parts asks the user what model car he needs parts for, instead of just verifying that this model is in our database we should send someone to his house to verify that he really owns such a car. Etc.
There might be times when such additional rigor is necessary. But often it is just too much trouble.
Admin
I was just working on a program the other day that used a similar approach to validate that a date was within a date range. Instead of doing something lazy like "date >= start_date and date <= end_date", the programmer wrote a loop that generated all the dates between the start and the end dates, and then checked that every date given was found on this list.
I cried.
Admin
Agree. If you check that it includes an @ sign and a period, that's a good indication that the person did indeed type an email address and not that he got confused and typed his zip code there by mistake or some such. Beyond that, yeah, if someone's email address is "[email protected]" and he bounces on the keyboard and types "[email protected]", no format test is going to catch that.
Admin
Oh... my god. I think I just found v2 of this function. I just got an email about a contest I could enter if I gave them my email and said they could spam me. I don't mind that, but I do like knowing if they gave out my email to anyone else, so I used the gmail trick where you add +[the site name] to the end of your email address. I was told it wasn't a valid email address. I was like... this is going to be good, I'm going to look what they did. It was better than I expected:
They do check to make sure you don't have any plus, dot, space, comma, semicolon, colon, forward slash, backslash, bang, open or close parens, hashes, open or close curly or square brackets, or dollar signs. They also check to make sure you don't have more than one @, and then after that, also check that you don't have two @s or two periods next to each other.
Finally, and this is the huge kicker, they make sure that your domain isn't in a large list of mispellings of common domains, and that your tld isn't in a list of common tld mispellings (and a lot of these overlap). So if you wanted to run your own email server at, say, yaho.com, or al.com, or rocketmaill.com, or hoymail.com... tough luck. Also if you live in China, because .cn is apparently a mispelling of .com, and therefore invalid.
If I saw this code written by someone at my company, you can frelling bet I'd submit it, cause holy frack is it awful. (There's even a commented out "endsWithGoodDomain" function that only accepts a handful of domains, with a comment that they used to call it, but they "had so many folks in Europe that wanted to subscribe", they had to comment it out. Apparently they only care about Europe, though, not China. :D)
I don't think you can submit just random code you find online, though, sadly? I recommend you visit it and see for yourself, though, anyway, if you want a laugh. http://staticcdn13.tastingtable.com/javascript_v2/mc_main.js
Admin
Yes, it's valid, but if it's really your e-mail address, you need a different one.
Admin
Here is an interesting fact: The asterisk (*) is valid in email addresses.
my*[email protected] is valid.
Admin
Admin
Before I was able to use aliases, I used + signs a lot in my only address. It was rejected by half of the contact forms. I'm not sure where and why this (in)validation is coming from but it seems all too common :(
Admin
Sites that reject valid email addresses should be blackholed.
Admin
Admin
And why reject email with + in? That's so annoying.
Admin
I hate people that code like that. Don't ever do that.
Admin
Admin
People who use InStr() need to be slapped around a bit with a large trout.
if(strEmail.IndexOf("@") == -1) { ... } If strEmail.IndexOf("@") = -1 Then ... End IfAdmin
"MyEmail@somewhere"@url.com would be valid, some mail agents will so the quoting for you.
Admin
I laughed for 10 minutes straight at this. If I hadn't have laughed, I'd have cried, because I've just had the same experience with a (locally-based) contractor we hired.
Admin
^[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,4}$
Whoops.
Admin
Admin
And...............trout.
Admin
While I'm at it, what's the fascination with the magic number -1? At least zero is ubiquitously understood to be equivalent to the Boolean value False (and non-zero integers are similarly understood to be True). The meaning of -1 is typically True, which is entirely nonsensical: the index of needle within haystack is True?
Admin
The sad part is that domain names truly end with '.', just try navigating to 'google.com.'. By convention everyone leaves it off but it's the root.
Admin
Well, in this example it can take thirty seconds to write a basic validator that will be good enough for 99% of cases...and maybe a couple hours to write one that fits the RFC. More possibilities for bugs too if you try to match the RFC, as there will be far more code. Also very easy for coders to misinterpret the RFC, as it's not the easiest thing to read. Unless you have some reason where you really need to be 100% certain the emails are valid to the RFC (like if you're coding a mail server or something), I'd argue you should almost never try to validate everything in the RFC -- when in doubt, accept it all. You should be sending a confirmation email to verify anyway, right?
Even if you validate to the RFC, all you've verified is that it's a valid email address, not that it is their email address, which is what you really want. So you have to do extra steps which, as an extra bonus, will fully validate the address for you!
Admin
They use -1 because zero is the first character in the string....
Admin
Admin
Good point.
If you want to check if an email address is valid and really exists, you should use a service like e.g. http://www.email-validator.net. We have been using their API for 6 months now and are really impressed by the quality of their service and the fast turnaround.