Email Validation script

[mwinter]

The Email Validation script rejects valid e-mail addresses, such as joe.bloggs@nationalhistory.london.museum. Top-level domains are not limited to only four letters, and any similar limitation will only require future monitoring and maintenance. The script also accepts addresses that are clearly wrong, such as jane.smith@foo.123.

It's been argued on Usenet fairly recently that it may just be better to leave proper validation to the server, which is more likely to be equipped to parse the address in full. In that instance, code on the client only needs to make sure that the input looks vaguely like an address (something as simple as /.+@.+(\..+)+/).

Mike

[ddadmin]

I've wanted to go back and tighten the rules of this script a bit more, though keep putting it off. I'll have to get to that soon. I disagree though that any client side email validation script should be very vague so to be 100% error proof. I guess I kind of see them in the same manner as CAPCHA scripts- sometimes they will unwittingly even stump a human, but for the most part, they work, and that's what's inportant. In those rare instances that they don't, the user can always contact the webmaster informing them of his/her issue.

It's just about giving people more options I think. Those that want to and know how to can always go the server route for email validation.

[djr33]

I disagree as well about a simple client side script.

If you accept the address at the client side level and the user gets no error, they will be very confused when the server side script then says there was an error. This is inconsistant.

Relying on client side is bad, but using it for something and confusing the user by having it vary from the server side code is weird.

[mwinter]

I disagree though that any client side email validation script should be very vague so to be 100% error proof.

I'm of two minds about it, myself - I did say "It's been argued", not that I necessarily agree. However, the opinion is valid.

Those that want to and know how to can always go the server route for email validation.

If the address is going to be used to prepare e-mail messages, then there's little option but to validate the address thoroughly, both to avoid possible spamming attacks and to ensure that the e-mail will be transmitted without error.

If you accept the address at the client side level and the user gets no error, they will be very confused when the server side script then says there was an error. This is inconsistant.

Confused? I sincerely doubt that. Most users won't even understand that two levels of validation occur.

It's not uncommon to encounter something that can only be validated server-side. For instance, client-side code can check that a new log-in name consists only of characters drawn from a permissible set, and that there are the right number of them. However, a script can't guarantee that the name is unused. Even using AJAX, it's possible - though unlikely - that someone else will register the name after the check is made.

It would be inconsistent if a script showed a dialogue that read, "Everything's fine!", only to have the server contradict that message, but no-one's daft enough to do the former. It would also be a mistake to name a function, isValidEmailAddress, if it doesn't actually assert that the address is valid, not that an end-user would notice such things. However, it's far from inconsistent just to make sure that the user didn't make a mistake like leaving the field empty or entering something that doesn't even have the most basic resemblance to an address, leaving the real check to the server. After all, client-side validation is meant to reduce the time and traffic necessary to validate user input, not do everything - that's still the server's responsibility.

Mike

[ddadmin]

Hi Mike:
It's a balancing act for sure. Personally if I had a server side script that does the email validation, client side, I'd just look for the precense of a "@" to act as a simple filter. Sure, I could code something a little more sophisticated yet have it remain 100% error proof, but in reality, it's all about minimizing the time I have to devote to a task. In my case, I see that most people who do enter garbage emails on my site will type complete gibberish without even the "@" character, so a simple client side script to weed out these users will suffice as the real validation takes over.

In the case of the Email Validation Script, my intent was that it'd be used by "newbies" who require a comprehensive client side script to weed out bad emails, as they don't have the knowledge to implement a server side solution. In this case the script needs to be comprehensive, and as part of the risk, may accidently reject a valid email as well. But in the real world, I'd say that's an acceptable risk for the type of people that will be using this script. That being said, of course there's always room for improving the filter, as you've suggested above.

[djr33]

Mike, you're not totally wrong here, but, really, what's the harm of using a correct server side script?
If you just want to avoid the work, then fine, but aside from that how does it harm anything to use it?
Seems to me like it's worth writing once, then sharing with everyone and being done with it... it'll never need to be updated or anything...

[mwinter]

Mike, you're not totally wrong here, but, really, what's the harm of using a correct server side script?

I assume you mean client-side?

There's no harm in using one, but neither the effort nor the size of the script is justified, in my opinion. To parse an e-mail address properly, one needs to use at least a context-free grammar and an appropriate parser.

it'll never need to be updated or anything...

That's not necessarily true: if RFC 2822 is updated or obsoleted, then it may need revising, similarly if the DNS aspect is changed.

Mike