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’re talking to a bot that has a crappy parser and doesn’t understand what a subdomain is.
This is why you never attempt to validate an email address beyond requiring an @ followed by a period, and send a verification email
Technically you don’t need a period for a valid address. “a@a” is a valid email address.
Not a lot of people sending emails using hostnames nowadays though.
DON’T TELL ME HOW TO ELECTRONIC MY MAIL
I don’t recommend switching the electric switches by hand. Takes hella long.
Could be a Tld without a domain in front.
Can you give an example of that?
Ian Goldberg had an email at a TLD in 2002.
I’ve been working with websites, frontend and backend code for almost 20 years, somehow never knew this was a thing. Weird.
That’s really neat. It of course makes sense because I can’t see any reason why a TLD couldn’t have MX records, but I am surprised that any TLD actually does.
I found an RFC with domains that have MX, A, and/or AAAA records. https://datatracker.ietf.org/doc/html/rfc7085
Yeah, I’ve noticed that a lot of sites are starting to disallow aliasing with email addresses. So annoying.
laughs in aliased Gmail addresses.
.+@[^\.]+\..+I sent you some nudes…
Which is blatant incompetence considering there is a very straightforward RFC covering domain names.
https://www.ietf.org/rfc/rfc1035.txt
Has anyone followed standards properly? There are weird workarounds in Linux’s TCP implementation because they had to do the same non-standard workarounds as BSD which was added since there are too many buggy TCP implementations out there that will break if the RFC is followed to the letter…
I think you intended a different RFC?
Good catch! It is 1034.
https://www.ietf.org/rfc/rfc1034.txt