I also reached out to them on Twitter but they directed me to this form. I followed up with them on Twitter with what happened in this screenshot but they are now ignoring me.
I also reached out to them on Twitter but they directed me to this form. I followed up with them on Twitter with what happened in this screenshot but they are now ignoring me.
You can use symbols like [ ] . { } ~ = | $ in the local-part (bit before the @) of email addresses. They’re all perfectly valid but a lot of email validators reject them. You can even use spaces as long as it’s using quotation marks, like
"hello world"@example.com.A lot of validators try to do too much. Just strip spaces from the start and end, look for an
@and a., and send an email to it to validate it. You don’t really care if the email address looks valid; you just care whether it can actually receive email, so that’s what you should be testing for.Not even a dot: TLDs are valid email domains. joe@google is a correct address.
Mmm… That doesn’t seem right, it’s usually gotta be fully expanded to at least a particular A record/MX.
How would you tie the tld itself to an MX?
TLD is just another DNS layer, try an SOA or NS lookup for “com.” those are obviously hosted somewhere. Hell the “.” at the end is even another layer with the root nameservers. You’d probably trip up a bunch of systems that filter on common convention rather than the actual RFC, but you could do it.
How the hell were the original rfc designers so creative as to result in such a flexible system?? It’s gets crazier the more you look at it.
It makes the system as a whole simpler. Your computer only needs to remember one root DNS server (although most computers allow setting 4 for redundancy) as opposed to one DNS server for each TLD, and it also makes adding TLDs easier.
To this point, there’s a website dedicated to the subject. Some of the regexes get pretty wild…
https://emailregex.com/
Don’t forget +
Super handy with Google email.
A lot of providers support plus‑aliasing, although it’s usually in a company’s best interest to block plus‑aliases.
+symbols aren’t always used for aliasing though, and companies that strip them out can break the email address. There’s no guarantee thatdan+foo@example.comis the same person asdan@example.com.I have a catchall domain and used to use email addresses like
shopping+amazon@example.comwith a Sieve rule to filter it into a “shopping” folder, but these days I just doamazon@example.comwithout the category or filtering.Yea but most of the time its more important to block code injection than to have the last promille of valid mail adresses be accepted.
You’re not going to get code injection via an email address field. Just make sure you’re using prepared statements (if you’re using a SQL database) and that you properly escape the email if you output it to a HTML page.
I think emailregex.com offers best of both worlds.