I know lots of developers (myself included) who thought they could write a functional email regex. Eventually you learn that in the end, the way to validate an email address is to send an email.

> Eventually you learn that in the end, the way to validate an email address is to send an email.

In my experience as a user, most people in the end also validate the email address by sending an email, but do no learning.

Strictly speaking, the dot in the latter space isn't actually necessary. It needs to be a resolvable domain, but if you bought a TLD you could be "name@tld"

I don't think an @domain is required if it's an email address on the same mail server.

That certainly used to work on Gmail; I haven't tried recently.

(Obvious caveat being that any provider can trivially append @provid.er if you don't specify, so this isn't really proof that email is specified that way.)

Wow, that is literally the only reason I would want a TLD

ICANN forbids application records at the apex of a TLD. The only TLDs that do funky things like this are ccTLDs.

And if you try to actually use a bare TLD you will crash hard into collisions with unqualifed domains and search paths. So, fun as a hack to amuse fellow techies but not useful for anything real.

...is there someone out there who did this?

Not that I'm aware of. Although I wouldn't be surprised if google did it for their employees. They already own the google TLD, they could very easily make it point to the google.com emails.

How many HN-reading googlers have you just made to send 'Test' emails to themselves, I wonder!

Can you actually attach an MX record to a tld?

Huh, cool. Though I don't see a lot of those records myself. For example, `dig MX ai.` gives me the MX record for ai., but I can't see any MX records for as., bj., or dj.

.+@.+\..+

That regex is defective. See benchaney's reply above.

.+@.+(\..+)?

should satisfy you both right? I use the original or a form of usually when I had to check emails.

That's identical to just doing .+@.+

Fully qualified domains actually end in a . If you're allowing sally@google then you must also allow sally@google. To be valid

No you don't. Email addresses explicitly require any periods in the domain to have at least one (non-period) character after the period. From RFC 5322, the relevant grammar production for the domain looks like

  dot-atom-text   =   1*atext *("." 1*atext)

(where atext is letters, digits, or a set of specific punctuation characters that doesn't include periods).

Ah, I wasn't aware that email addresses defined that differently. it looks like it's also the same way as part of obs-domain as defined by the addr-spec part of that. RFC 822 also seems to say the same thing, it's been way too long since i've tried to read those RFCs.

One (probably forgotten) reason people validated email addresses with convoluted regexps is that there are multiple (actually valid per RFC) email addresses formats that can do nasty things. Like explicitly specifying a series of mail servers to go through. They're (hopefully) deprecated and rejected by most servers nowadays, though.

> hopefully

Why?

> By default, this feature is turned off. This closes a nasty open relay loophole where a backup MX host can be tricked into forwarding junk mail to a primary MX host which then spams it out to the world.

http://www.postfix.org/postconf.5.html#allow_untrusted_routi...

Thankfully my email is @@@@@@@.......