Everyone knows what an email address is, right? (Quiz)
Everyone knows what an email address is, right? (Quiz)

Email is Easy

Everyone knows what an email address is, right? (Quiz)
Email is Easy
I scored 16/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
I feel pretty good about that
I don't think it really matters what the standard is, because you'll be completely limited by some 25 year old bit of Regex from Stack Overflow that every web developer ever has implemented into their form sanity checks.
The main one that gets passed around will match the weirdness fine. In fact, it probably matches things you don't want, anyway.
A signin/registration form really only needs to do sanity checks to get rid of obviously bad addresses. You'll have to send a round-trip email confirmation message to make sure the email is real, anyway, so why bother going into great detail? Just check that there's an '@' symbol and a dot in the domain. Most of the rest is wanking off.
nice. though valid but obsolete is not a thing... if it's obsolete it's invalid.
Agreed! (because then I would get 3 more points on the test)
I don't care who the IRS sends, I am not validating emails with spaces on them.
You shouldn’t be validating emails yourself anyway. Use a library or check for only the @
and then send an email confirmation.
Even if it's a completely valid address and the domain exists, they still might've fat fingered the username part. Going to extreme lengths to validate email addresses is pointless, you still have to send an email to it anyway.
Use a library
Please, no. If someone wrote email address "validation" complex enough to warrant a library, then their code is almost certainly wrong.
or check for only the @ and then send an email confirmation.
Yes. Do that.
If your boss demands a more detailed check at input time, then make it display warnings, not errors, and continue to the confirmation sending step if the user chooses to ignore the warning.
This is the way.
Also as the registrant of one of those new fancy TLDs, much like the owner of this website (email.wtf), their own email addresses will fail those stupid email validation checks that only believe in example@example.[com|net|org]
Shitty websites will fail "example@email.wtf", guaranteed - despite it being 100% valid AND potentially live.
Source - I have a ".family" domain for my email server. Totally functional, but some shitty websites refuse to believe it.
Yeah I have a .engineering for my biz. I also registered mycompanyengineering.com to get through places that won’t take the new TLDs.
Usually banks.
Seems like a weird choice as the primary TLD.
I'd switch it just to reduce the annoying typing hassle and to avoid misspelling.
It's already unusual if I say "My email is givenName@LastName.eu"
And that trips so many persons.
First: I have my own domain
Second: It's not gmail, apple or a local provider
Third: The TLD isnt .de
or .com
but .eu
I have plenty of website reject even my fairly vanilla [email]+XYZ@ address add–ons
I have a spam collecting address @freemail.hu , the domain is live and working since 96, sometimes it's not accepted, because it's not Gmail I guess
I'm not sure I blame the sites. The spec is so complex that it's not even possible to know which regex to use
The spec is so complex that it’s not even possible to know which regex to use
Yes. Almost like a regex is not the correct tool to use, and instead they should use a well-tested library function to validate email addresses.
const emailRegExp = /^[\w.!#$%&'*+/=?^`{|}~-]+@[a-z\d-]+(?:\.[a-z\d-]+)*$/i;
per the HTML specification. From https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation#validating_forms_without_a_built-in_api
Same as I have a .party domain. So I made a place holder (looking at you progressive) email ___+haslazydevs@gmail.com
I rage quit gave up at 12.
A fork bomb is apparently a valid email address.
I quit, this is stupid.
Let us recite the email validator’s oath:
If it has something before the
@
, something between the@
and the.
, and something after the.
, it’s valid enough.
The ultimate validation is to see if it gets sent.
Fails for when there is no TLD. Just send an email and validate a response eg from a link.
No. The number of users who have a real email with no TLD is far less than the number of users who will accidentally type an email with no TLD if you don’t validate on the front end.
I’m here to help 99.9% of users sign up correctly, not to be completely spec-compliant for the 0.1% who think they’re special.
I scored 16/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
This was fun!
Edit: people, upvote the OP, not me
13/21 here. Mostly got hung up on several "this was valid in earlier RFC, and later removed" kind of situations. There are several where I picked the correct answer, but where I know many websites that won't accept it as valid, and that's not even the more esoteric ones.
I got 14/21
Me too and it said that is the amount you'd get if you just picked "valid" for every response. Lmao
Samsies
Yay! Same. But only because I've already heard of some email craziness before.
Don't tell me what to do!
yay 16/21 club
What if we 👉@👈 ..? 🤭
Now i just need a registrar that allows emoji...
Any should. Any unicode is converted to alphabetical anyways, through "xn--" + a punycode conversion. Which is actually fairly important for places that don't use the Latin alphabet.
See http://xn-bdk.gay/, which is the same as http://xn--bdk.gay/
(Someone set this up on 196 a while ago, they said they were using Namecheap)
Self-host it.
People may find that weird, however.
Question 5 is incorrect, name@example
is a fully valid email address, even after RFC 2822
The spec of RFC 2822 defines an address (3.4.1) as:
local-part "@" domain
domain
is defined (3.4.1) as:
domain = dot-atom / domain-literal / obs-domain
dot-atom
is defined (3.2.4) as:
dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext)
1*atext
meaning at least 1 alphanumeric character, followed by *("." 1*atext)
meaning at least 0 "." 1*atext
If tomorrow, google decided to use its google
top-level domain as an email domain, it would be perfectly valid, as could any other company owning top-level domains
Google even owns a gmail
TLD so I wouldn't even be surprised if they decided to use it
I don't know if they changes the answer to the question, but it now says name@example
is valid.
It does say it's valid, but also that it's obsolete, and while the RFC does define valid but obsolete specs, there is nothing defining domains without a dot as obsolete, and it is in fact defined in the regular spec, not the obsolete section
It says valid but obsolete, which sounds like a contradiction to me.
This is technically valid but considered obsolete. RFC 822 allowed domains without dots, but RFC 2822 made this obsolete.
Do email suffix not indicate a different domain like .org and .com for websites?
I didn't understand this one. How do you have a no dot domain? Like you need to distinguish from example.com or example.wtf
Edit: do you mean if you own .google
you can have your email@google
address?
In response to your edit.
Yes, or countries could use their cctld, e.g. email@us or noreply@uk.
Or any tld owner could do the same with theirs, of course.
Yes, the top-level domain is still just a domain. I'm not aware of any public Internet services which are reachable from a TLD directly, and it's strongly discouraged by ICANN, but there isn't any technical limitation preventing e.g. someone at Verisign from setting up example@com
.
you could also send mails within your local network, the hostname just has to resolve and have a mail service running
👉@👈
Bottom-ass email address.
No ring for that.
THIS THING IS STUPID!!!!
Or it’s just me that is the fool. Thanks for sharing. I just learned about 9 new things.
All of the modern internet is built on the decaying carcasses of temporary solutions and things that seemed like a good idea at the moment but are now too widely used to change.
I gave up when I got like 5 wrong. I've ran mail servers for decades, most of the invalid "valids" would get rejected by any mailservers I've administered.
Just because it's not something you'd use anymore doesn't mean it isn't valid.
WEP is still a valid form of wireless encryption, but no one would use it anymore (and so would be obsolete). It's still a part of the 802.11 standard.
And for a good reason.
I don't validate emails, I test them.
That's your email? OK, what did we send it? if we couldn't send to it or the user can't read it there's no reason to accept it.
OK, maybe I do some light validation first, but I don't trust the email address just because it's email-address-shaped.
Hooray, you have better security than Apple, who won't let me use my own email because some idiot in Australia used it first.
What kind of "light validation"? I'm guessing a .*@.*
regex match.
I don’t validate emails, I test them.
Hooray! You get a gold star.
OK, maybe I do some light validation first,
I hope your "validation" does nothing more than show a warning that the user is allowed to ignore.
I have seen too many systems built by people who think they know what's valid or not before and after the @
sign*, and they are almost always dead wrong. In the worst cases, such systems accept an unusual-looking address and claim to send the expected verification message, but never actually send it. Of course, these systems won't work for some people, and since none of their online docs or support staff know why, those people will be locked out of using the system and funneled into bottomless pit of misery if they try. Please don't build broken garbage like this.
*Fun fact: Not so terribly long ago, even the @
sign didn't have to be present. Some email addresses were bang paths. I'm not sure if any of these are still in use, but it wouldn't shock me to learn that they are.
I vaguely remember a panel where a guy went through various cases like these.
One of the things that stood out is that not every email provides implements the same specs, so one provider might allow you to set up a "valid" email address that might not be able to communicate with other providers as they consider it "invalid".
So much better than I thought it would be! Thank you for making the world a better & more informed place
Two of my "favorite" features it didn't even touch on. You can have nested comments:
foo(one(two(three(four(five(six(seven)))))))@example.com
This will actually fail on that big email regex that gets copied around (originally from Mastering Regular Expressions in 1997), because it can only handle comment nesting to a depth of six. It is actually possible to do indefinite nesting now with recursive regex, but it was developed before that feature existed.
RFC822 also allows routing addresses through multiple servers:
<@foo.example.com@bar.example.com:123@example.com>
But this is almost always denied on modern email servers because it was abused by spammers.
The routing feature is so cursed XD
I lost it at the fork bomb. I mean I hit valid because there was no way it was on the and not valid, but there's no way i'd have expected that. after that I just kept guessing the most stupid answer and did pretty well
I scored 16/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
Damn, and here I thought I had this locked down because I was salty that so many places struggle with +
in the email addy. But my god, there's comments?
I scored 14/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
I actually died at the poop emoji one. Actually amazing awareness to test for that
TIL that emoji transcend spoilers.
Spoilers!
I scored 13/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
5/21 for me LoL 😂
I had to make an email address just for paypal because those idiots don't accept subdomains in email addresses.
Pizza Hut doesn't allow dashes in the domain. This prevents me from ordering Pizza Hut with the email under my personal domain. This can be considered a feature.
13 right answers and I didn't expect so many lol
I'll never validate some of the 💩 I've learnt today.
13 here too
Validation should just check if it has a @ and send an email and wait for a response... because who knows if mailservers "respect" the spec anyway.
12/21
are things that are considered out of current spec really "valid" though?
And is it really valid if my email provider doesn't accept it? If it's not universally accepted or standard, then it doesn't matter if it's technically valid.
The RFC is the standard.
If your email provider doesn’t accept email@email.wtf is it then invalid?
Thanks to RFC 6532, Zalgo text is a-okay.
hmmm...
Yay! You're average! Time to start making plans for what you'll do when an LLM takes your job.
I already have plans.
And they are ...
Wow. if I ever have the madness required to self-host, I'll have my email at an IP address.
I'm gonna have a mailbox per device and the addresses will be deviceip@serverip. 10.254.17.5@145.80.205.19.
Needs to be IPv6, including support for subnets to message multiple devices
12/21. It was highly entertaining though.
Pretty much everything I've seen in e-mail is needlessly complicated and weird. So of course addresses are as well.
Nested comments. RFC822 had a whole bunch of bad ideas in it, but nobody thought much of it at the time. Most programming languages don't even do nested comments, because they want to filter them out with a simple lexer before the grammar ever sees it.
Average :/
I got 13/21. I mean thats not bad 😄
Relevant talk from FOSDEM 2018 (warning: poor audio quality): https://youtu.be/xxX81WmXjPg
I kind of expected a lot of this; I remember the sendmail 4 book from back in the day when O'Reilly had that, DNS and BIND, and Perl as the entirety of its corpus.
15
Going to have to try some of those.... Can you actually register emojis as a domain, or is that just the email validation that allows them?
Edit: most TLDs don't. Smaller ones do sometimes.
Emoji domains can be registered using punycode, and you're right that it's up to the TLD whether they're allowed or not.
For example: http://xn--yt8h.la/%F0%9F%90%B6
📙.la is encoded using punycode to http://xn--yt8h.la/
🐶 is URL-encoded to %F0%9F%90%B6
Giving the 'true' URL http://xn--yt8h.la/%F0%9F%90%B6 which then redirects to https://emojipedia.org/dog-face
Emails should generally use @xn--yt8h.la
instead of @📙.la
for maximum compatibility. I'm not sure if the email spec allows punycode.
I scored 18/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
If qoutes are removed and internal spaces are invalid, how could ":(){␣:|:&␣};:"@example.com
be valid?
Presumably the space between quotes is "escaped", meaning it's supposed to act like any other character.
Yeah they're processed, but not passed through.
Not too sure, but a previous one says spaces are allowed in comments. I would assume the {}
is similar?
Well... like Bill Clinton said, it depends on what the definition of "is" is.
I scored 16/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
Jesus effin Christ! I had no idea! This is madness! This is ... Omfg I just can't
15/21
I scored 13/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
Try explaining that last one to someone over the phone
I can't even view it...I get a TLS error
My phone blocked the site, citing "harmful content"
I get "not found". You got farther than me.
And after that, I now can't wait for the next pull request with a regular expression on email validation to come through.
I scored 12/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
Hey dont share my email out 😡
same
should have just randomly clicked lol
#18 seems really bad, like no-one-has-ever-sanity-checked-this bad.
Im still trying to figure out what that means. How does @ resolve to an IP address?
I did not like this and quit after ten questions 😅
But I respect that it exists.
13/21, seems like I am not significantly different from random guessing
Got the same, I can't believe how many weird comments and extra random things can get added into an email address.