I scored 12/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media. That was absolutely hilarious!
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.
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://ツ.gay/
(Someone set this up on 196 a while ago, they said they were using Namecheap)
Question 5 is incorrect,
name@exampleis a fully valid email address, even after RFC 2822The spec of RFC 2822 defines an address (3.4.1) as:
local-part "@" domaindomainis defined (3.4.1) as:domain = dot-atom / domain-literal / obs-domaindot-atomis defined (3.2.4) as:dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext)1meaning at least 1 alphanumeric character, followed by*("." 1*atext)meaning at least 0"." 1*atext
If tomorrow, google decided to use its
googletop-level domain as an email domain, it would be perfectly valid, as could any other company owning top-level domainsGoogle even owns a
gmailTLD so I wouldn’t even be surprised if they decided to use itI 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
.googleyou can have youremail@googleaddress?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.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.
I don’t know if they changes the answer to the question, but it now says
name@exampleis 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
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 scored 15/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
brb omw to try and reserve
👉@👈as e-mail addressTwo of my “favorite” features it didn’t even touch on. You can have nested comments:
foo(one(two(three(four(five(six(seven)))))))@example.comThis 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.
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.
What kind of “light validation”? I’m guessing a
.*@.*regex match.Almost correct. ^.+@.+$
Too hard to validate properly to be worth it. Even if it is technically valid that’s insufficient. It must also work, and the easiest way to test that is to use it and verify that the user got what we sent.
I see you accept lemmy handles.
if i can email them and the user gets it - fine by me
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.
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.
Yeah I feel like the correct answer for anything obsoleted by a more recent RFC should be “Invalid”.
Complaints about the quiz? Send them to 💩@💩
My top five from this (all valid):
- ":()␣:;:"@example.com # fork bomb
- 👉@👈 and poop@[💩]
- “@”@[@]
- c̷̨̈́i̵̮̅l̶̠̐͊͝ȁ̷̠̗̆̍̍n̷͖̘̯̍̈͒̅t̶͍͂͋ř̵̞͈̓ȯ̷̯̠-̸͚̖̟͋s̴͉̦̭̔̆̃͒û̵̥̪͆̒̕c̸̨̨̧̺̎k̵̼͗̀s̸̖̜͍̲̈́͋̂͠@example.com
- fed-up-yet@␣example.com␣ # ␣ = whitespace
TIL that emoji transcend spoilers.
Let us recite the email validator’s oath:
If it has something before the
, something between theand the., and something after the., it’s valid enough.Fails for when there is no TLD. Just send an email and validate a response eg from a link.
