TIL (about the Dark Arts of HTML)
-
Seriously, what kind of developer lives by the creed: "I don't care about edge cases?"
A soon-to-be-ex developer?
-
I think you meant a-soon-to-be-manager
-
"Why would I care about edge-cases when I have minions who can be coerced into caring about them on my behalf?"
-
Our product manager used to go "You know what I want stop bothering me and build it" on questions like that, though it's been less bad nowadays.
-
You just won yourself a promotion
-
-
I believe that insane standards that nobody follows have no right to be called standards. The "official" email address format is definitely both. So screw those edge cases.
Be careful what you wish for.
OK, not literally forever, but a million years or so would be nice.
I do hope there isn't a djinn here monitoring everything I say to grant me evil wishes.
-
a million years or so would be nice
Still several orders of magnitude less than the Sun, though.
Filed under: that is one big old bunch of hot gas
-
The "official" email address format is definitely both.
-
I believe that insane standards that nobody follows have no right to be called standards. The "official" email address format is definitely both. So screw those edge cases.
Well, the thing is that the standard is indeed problematic. However, you have to validate the email addresses you get by sending a validation email anyway (no format validator in the world will help you if the address does not exists on the target server, is mistyped or does not belong to the user).
Thus the email either bounces or goes through upon sending. And you needn't bother with the headache of format validation or angry users who did indeed rely on edge cases.
-
TL;DR version ?
-
-
Well, the thing is that the standard is indeed problematic. However, you have to validate the email addresses you get by sending a validation email anyway (no format validator in the world will help you if the address does not exists on the target server, is mistyped or does not belong to the user).
You can't fully validate without sending email, but you can avoid most of the bozo mistakes with a simple check (which might be implemented with an RE). For example, you can check that there is an
@
, and that it separates a non-empty mailbox part and a non-empty host part. This does make some types of email address unusable, but they're rare and you would be entirely justified in declaring that you aren't interested in delivering to them.I wouldn't get much more complex than that though. You're stopping obviously wrong, not working out a perfect answer.
-
Again, why whould you need to? You're sending an email anyway so what's the point?
You still have to write the routine to wipe accounts off the database whose email address either bounced or was never confirmed.
-
You're sending an email anyway so what's the point?
To provide an immediate validation to the user while they are typing the address. Yes, I'm talking about hoisting it to the client-side. It won't stop them from submitting rubbish — nothing will — but it will nudge them towards not sending you utter crap and there's no reason for not applying the same basic filter server-side. Sure, you low-ball the check (because you're about to a proper check by sending an email), but that's better than nothing and hardly more intrusive on genuine (non-fuckwit) users.
-
Again, why would you care if they enter crap? Does it offend your sense of aesthetics, or what? It boils down to two options: They receive the email or not.
And since you have to deal with the latter possibility on the server-side anyway, you needn't bother with client-side.
It's almost as if you're arguing for creating more work for yourself needlessly.
-
Again, why would you care if they enter crap?
Personally? I wouldn't care. But it's good general policy for a UI to indicate where an obviously wrong value is present so that users know that there's something they need to correct. It gives a better user experience than letting the user go all the way through filling out the rest of the form and submitting it only to get “computer says ha ha no” in response. For an email address, all I'd validate is that there's a non-empty mailbox name and a non-empty mail host name separated by an
@
.If you were going to get really fancy, validating that there's a real host or an MX record in DNS would be possible, but that'd be a server-side only check and you might as well do that by trying to send email at that point (which is the only way to validate the mailbox name these days). But that's no longer about pre-commit checks, but rather about post-commit ones, and they're a whole 'nother ball of wax.
-
Again, the standard is so broad that there is no way to tell something is obviously wrong. As such, it doesn't make sense. It only adds unneeded complexity.
And checking for MX records is a bad idea. The destination address does not have to have such a record.
-
the standard is so broad that there is no way to tell something is obviously wrong.
An email address which doesn't contain an @ is obviously wrong, is it not?
-
there is no way to tell something is obviously wrong
Whut?
- No @ (as covered by @tar)
- Nothing before the @
- Nothing after the @
- No . in whatever follows
proceedsthe @
Can you confirm it's a valid email address? No, of course not. Can you check it's not obviously invalid? Yes.
-
-
No . in whatever proceeds the @
The host name need not strictly contain a
.
, but probably ought to. Internal users can suck it up and use the full hostname. ;)
-
I meant it as an antonym of precedes but amended for clarity.
-
Yes. And? Again, why do you need to validate twice? What for?
WHAT is the use of that? You guys seem hellbent on creating extra and useless work for yourself.
If it's invalid it will get pruned by the cron job which purges non-confirmed accounts.
Again, you can't catch invalid email addresses anyway. So why bother?
- No . in whatever <ins>follows</ins><del>proceeds</del> the @
"JonDoe@.test"@example.org
That's a valid address.
-
WHAT is the use of that? You guys seem hellbent on creating extra and useless work for yourself.
Here I am, registering on the forums... ok, username... password... email...
myemail#somehost.com ^ typo ---
I never receive the email.
"This forum SUCKS!"
Fixed by 3 lines of Javascript.
-
But You're Doing It Wrong™! We developers can't handle every single mistake an idiot could do.
-
We developers can't handle every single mistake an idiot could do.
No, but stuff like this is not even an idiot thing to do. It's an honest typo. You just want to stop @accalia from registering, don't you? :P
-
Maybe that's why she never got to join the old forums!
-
Here I am, registering on the forums... ok, username... password... email...
myemail#somehost.com ^ typo ---
I never receive the email.
"This forum SUCKS!"
Fixed by 3 lines of Javascript.
Someone typesJonDeo@example.org
While meaning to write:
JonDoe@example.org
Your point being? Not that I'm seeing how someone could accidentally type a hash instead of an @ since they're on opposite sides of the keyboard.
-
Oh oh oh!
I know a way to prevent those:
Make the users type their E-Mail address twice.Not very user-friendly but it should work!
-
That's a valid address.
I simplified it, which is never going to get an edge case like yours.
-
Your point being?
The point is that if someone just puts in
JohnDoe
, you're not interested in even kicking off the emailing process, because you know it won't work in any useful way. (And some users do that stuff; they can be dumber than a box of rocks.)
-
The point is that if someone just puts in
JohnDoe
, you're not interested in even kicking off the emailing process, because you know it won't work in any useful way.That only makes sense if you are the one who has to trigger the email manually for each and every entry.
Or if your server's CPU load jumps to 100% everytime an email is sent.
-
-
They're right next to each other on a UK keyboard.
So, then it's a typo. Do you also intend to catch all the other infinite possibilities for typos?
-
same on en-US (SHIFT-2 is @ SHIFT-3 is #)
-
So, then it's a typo. Do you also intend to catch all the other infinite possibilities for typos?
Of course not.
We're just talking about a basic check that what's been typed looks like a valid email address, not trying to catch each of the 70 bazillion ways they could be invalid otherwise.
What a valid email address looks like is a long-solved problem, and validating that is trivial.Obviously validating that it's actually a valid address and is owned by the person using it, via way of verification email, is sensible but it's also sensible to check it looks right on submission.
-
Why is it sensible? That is the underlying current of seemingly all opinions here, for which I have yet to hear a sensible justification besides "a user might yell at me!"
-
-
So, then it's a typo. Do you also intend to catch all the other infinite possibilities for typos?
Just the obviously wrong ones.
-
-
-
Why is it sensible?
Why care about that?
User experience.Why wouldn't you considering how trivial it is?
-
Because we don't totally hate our users.
Yes, of course. Preventing them from making a typo will bring peace on earth.
-
Why wouldn't you considering how trivial it is?
NO, we must validate bobs$bumhole by making SMTP servers do unnecessary work, pissing off our users in the process, it's the only elegant solution.
-
NO, we must validate <tt>bobs$bumhole</tt> by making SMTP servers do unnecessary work, pissing off our users in the process, it's the only elegant solution.
Oh, someone think of the poor, poor smtp server! Are you running that on a Hamster or have you already upgraded to Dual-Hamster?
-
Oh, someone think of the poor, poor smtp server! Are you running that on a Hamster or have you already upgraded to Dual-Hamster?
Pfft. Quad-Hamster, obviously.
-
-
Pfft. Quad-Hamster, obviously.
Well, there you go. Feed them regularly and they might just be able to cope with a typo'ed address, or even two!
-
Depending on the downstream SMTP service, it's probably best to avoid too many invalid requests.
Why don't you tell us your objection to this?