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 12/21 on https://e-mail.wtf/ and all I got was this lousy text to share on social media.
17/21. Would have been 18 but the first example of spaces screwed me.
Average :/
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
matches
What if we 👉@👈 …? 🤭
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.
This is the way.
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
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
I did not like this and quit after ten questions 😅
But I respect that it exists.
If qoutes are removed and internal spaces are invalid, how could
":(){␣:|:&␣};:"@example.combe valid?Presumably the space between quotes is “escaped”, meaning it’s supposed to act like any other character.
Not too sure, but a previous one says spaces are allowed in comments. I would assume the
{}is similar?
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.
A domaine without tld (me@home) is a valide address. I saw an email server being used as a mqtt-like server this way (it is very old and predate those software).
An address without a domain is irrelevant for a signin/registration form. Which is like 90% of the code being written in the wild to validate addresses.
If you’re writing an email server, then you need to care about all these details. Most of us never will.
Hey! IPv6 is valid in the inter-network context and needs no dots!
You gonna fill an IPv6 address for your email server into the DoorDash signin page?
Don’t be ridiculous, I’m going to use an open source password manager to fill an IPv6 address for my email server into the DoorDash signin page.
I know you’re being facetious, but I’m thinking through the implications of someone actually doing this. ISPs aren’t always handing out static IPv6 prefixes for some damn reason, so you can’t count on that address staying the same when self-hosting. Even if you can, you don’t know what will happen when you change ISPs.
So yeah, really bad idea regardless.
I got 13/21. I mean thats not bad 😄
Pretty much everything I’ve seen in e-mail is needlessly complicated and weird. So of course addresses are as well.
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?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
I see what you mean, I’m with you now.
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?
