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.
Somebody made a shitty regex.
Probably, from what I can see the address in question isn’t really that exotic. but an email regex that validates 100% correctly is near impossible. And then you still don’t know if the email address actually exists.
I’d just take the user at their word and send an email with an activation link to the address that was supplied. If the address is invalid, the mail won’t get delivered. No harm done.
Email standard sucks anyway. By the official standard, User@email.com and user@email.com should be treated as separate users…
Personally I don’t think that sucks or is even wrong. Case-independent text processing is more cumbersome. ‘U’ and ‘u’ are two different symbols. And you have to make such rules for every language a part of your processing logic.
If people can take case-dependence for passwords (or official letters and their school papers), then it’s also fine for email addresses.
The actual problem is cultural, coming from DOS and Windows where many things are case-independent. It’s an acquired taste.
TLDs could theoretically have MX records too! Email addresses as specified also support IPv6 addresses! The regex would need to be
.+@.+and at this point it’s probably easier to just send an email.I’m with you, and I agree that is technically correct, but I believe the sheer number of people who might accidentally write “gmail” instead of “gmail.com” compared to people using an IPv6 address (seems like a spam bot) or using a TLD like “admin@com” make requiring the dot worthwhile.
That’s why I have an “allow anyway” button for addresses that look misspelled but are still technically valid.
Edit: believe it or not, that was a typo.
The best of validation is just to confirm that the email contains a
@and a.and if it does send it an email with a confirmation link.TLDs are valid in emails, as are IP V6 addresses, so checking for a
.is technically not correct. For examplea@banda@[IPv6:2001:db8::1]are both valid email addresses.I feel like using
a@[IPv6:2001:db8::1]is asking for trouble everywhere online.But its tempting to try out, not many people would expect this.
try user@123.45.67.89.in-addr.arpa or user@d.e.a.d.b.e.e.f.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.1.2.3.4.ip6.arpa just for the giggles. Mix it with BANG-Adressing:
123.45.67.89.in-addr.arpa!d.e.a.d.b.e.e.f.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.1.2.3.4.ip6.arpa!user
That’s what it looks like to me too
I could probably write a RegEx for email format validation that’s accurate, but why would I when there are ones already written and readily available that covers all possible legit variations on the standard? I never understood why people insist on writing their own (crap) RegEx for something with as many possible variations they can miss like email…
And that one isn’t even a weird edge case! It’s a domain with a sub domain, if they can’t even cover that case then it’s an extra shitty RegEx