Hacker News Reader

Comment by smackfu | Hacker News Reader

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, that's where most of the complicated regexps come from.

View on HN

    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 if the validation email has been sent yet (to deal with "well maybe I should wait 5 more minutes") and if it has and they don't have it allow them to change their email to their real email address. So many sites (incl. the one I manage) do not allow this, it's crazy.

>if it has and they don't have it allow them to change their email to their real email address

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?

From my experience a user will almost always remember the password they've just entered, even if they got the email wrong. They should be able to login to a not-yet activated account and be presented with the option to correct the email for the activation email to be sent to. There's no potential for abuse there.

* 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.

Kicksend has a library for that: https://github.com/kicksend/mailcheck

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.

> 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.

That's roughly 40 chars ? People coming from some regions easily have 20 to 30 chars for the family name alone [1]. That's more or less the length of our test string if the add the given name(s).

[1] http://news.bbc.co.uk/2/hi/africa/5651310.stm

I think the point is that they are using all capital W's which are the widest letter, but real strings of the same length are never that wide.

Thanks, I didn't get it.

If the issue only appeared on all W's I'd guess you could set the bug as minor and discuss if it's worth fixing. If it costs an incredible amount of time to fix it, the problem relies more on defining priorities than on having too much granularity on the testing side.

To go back on your parent post, I'd say validating funky emails is of the same level. The test team should bring up the edge cases, fixing them or not is a matter of priorities.

Because most users couldn't type their own email address, or even a properly formatted email address to save their life.

"My email address is joe.aol or was it aol.com@joe? Wait joeaol@com?"

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.

There are times when it is good business to stand on principle, and then there are times to just help your customers a little bit. Email signups are definitely the latter IMO.

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.

Refusing to send email to someone because your software mistakenly rejects their email address is not exactly being as inclusive as possible, though, is it?

I agree. In addition to being pretty damn old at this point the pronunciation of "@" should resolve the "aol.com@joe/joe@aol.com" issue for all but the most clueless (all but the most likely to cost you in support). That case is particularly egregious.

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.

It's featureful because it's old. Who routes email to UUCP any more? Just look at the sections of 5322 that are devoted to "Obsolete Syntax".

Actually, I was just thinking the core error was something else; conflating routing with identity. bob@subgenius.com is a routing instruction, 'J. R. "Bob" Dobbs' is a human identity, and '"J. R. 'Bob' Dobbs" <bob@subgenius.com>' is just a mess.

This is a really good point.

> 'J. R. "Bob" Dobbs' is a human identity

Is he really though?

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.

I feel about this much the same way I feel about the endless proliferation of Markdown variants; if we could all agree on one simplification, sure, but the current situation where we haven't really stinks. For instance, ask early Gmail users about putting + in the email.

So while I agree with you in principle, in practice it seems infeasible. The differences bite in practice, unfortunately.

Only ticket I've ever seen about email validation was that a webapp was refusing to accept a customer's valid (and already registered/paying money in another system) address.

Testers gotta find bugs. QA's needs eat too you know.

Reply on news.ycombinator.com