Everyone knows what an email address is, right? (Quiz)
-
This post did not contain any content.
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.
-
I'm gonna have a mailbox per device and the addresses will be deviceip@serverip. [email protected].
Needs to be IPv6, including support for subnets to message multiple devices
-
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. -
What kind of "light validation"? I'm guessing a
.*@.*
regex match.@
matches -
This post did not contain any content.
If qoutes are removed and internal spaces are invalid, how could
":(){β£:|:&β£};:"@example.com
be valid? -
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!
-
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?
-
What kind of "light validation"? I'm guessing a
.*@.*
regex match.wrote last edited by [email protected]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.
-
You shouldnβt be validating emails yourself anyway. Use a library or check for only the
@
and then send an email confirmation.This is the way.
-
Question 5 is incorrect,
name@example
is a fully valid email address, even after RFC 2822The 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 domainsGoogle even owns a
gmail
TLD so I wouldn't even be surprised if they decided to use itwrote last edited by [email protected]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 youremail@google
address? -
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.
-
This post did not contain any content.
I did not like this and quit after ten questions
But I respect that it exists.
-
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.
-
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.
-
This post did not contain any content.
Average
-
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.
-
This post did not contain any content.
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 see you accept lemmy handles.
if i can email them and the user gets it - fine by me
-
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.
-
If qoutes are removed and internal spaces are invalid, how could
":(){β£:|:&β£};:"@example.com
be valid?Not too sure, but a previous one says spaces are allowed in comments. I would assume the
{}
is similar?