I gave up using mail@<nickname>.network because of the significant percentage of sites that refuse the .network TLD.

One large financial services provider even told me that their "policy" was to allow 3, 4, or 5 characters as the last part of the domain. So .ninja is A-OK. I pointed out how ludicrous this was, and they told me it was their "policy" again, and that's why Australian Super doesn't have any of my money.

I would bet on a number of sites this is because they all copied and pasted the same email validation regrex they found online when googling, which was made before TLDs could be that long, and they don't know how to fix it.

> their "policy" was to allow 3, 4, or 5 characters as the last part of the domain

Wow, no country codes? I could understand a restriction dating from before the great expansion of TLDs, but expect it to have a 2 in it.

Ah, apologies. My mistake, yes, 2 digits was fine.

Actually I wonder then if it was 2, 3, or 4. I think it was, because I remember thinking that .wiki would have been okay.

Either way. Arbitrary and stupid.

There's probably a "misconceptions people have about e-mail addresses" post out there somewhere; the tl;dr is that so much is or will be allowed, for validation you should really only check if there's an @ in the address, for the rest just try to send an email and see if it bounces.

But don't activate an account without e-mail verification. I got a random account on Deezer because someone signed up with my e-mail address; they probably got it off a spam list. But it kind of implies that Deezer didn't do e-mail verification before letting people use their platform.

I've had problems with sites accepting my .is email address too, probably due to similar logic.

I have something similar when I used contact@<firstname>.<lastname>.name

There were various ways in which that failed.

1. ".name" was pretty new by then, so some frontends did not accept it

2. some frontends objected to the third level of my domain part, accepting third levels only in such cases as the well know. ".co.uk" for example

3. some frontends let me sign up, but something in the backend failed, I can only suspect if it was the ".name" tld or my third level, but I never got any mails after signing up

> 2. some frontends objected to the third level of my domain part, accepting third levels only in such cases as the well know. ".co.uk" for example

This is actually not such a rare edge case. My university, for example, uses <name>@students.<university>.de . So there's really not much excuse for not handling this.

The number of sites that send mail to "[email protected]" when you give them "[email protected]" is staggering, too. It's a mystery to me why they would ever want to do that, but it happens a lot.

I can see how that happens immediatly...

    var domain = addr.split(['@','.']).take_last(2)
    var tld = domain[1]
    // check TLD against wacky rules...

See, boss, it's easy. What's next?

It's also possibly just some arcane regex incantation that someone implemented 12 years ago and nobody has been able to decipher it since.

> Turns out folks mostly validate <3chars>.com in my experience, which I assume is because of good old mail.com.

I wonder what happens with .co.uk, and other two-letter second-level domains.

My student email was @tcd.ie - I had plenty of websites I wasn't able to sign up to, offers I couldn't redeem and mail that just never arrived...

Probably hard coded exceptions.

You could probably put a +. Instead of [email protected], it could be [email protected] or [email protected]. These would still forward it to [email protected] [0]

This has the side effect of knowing who has been selling out your email to spammers.

[0] https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addr...

I mean I legit wish I owned cik.com, that'd be awesome :p. Seriously though tonnes of folks fail the +. You know what's especially awesome? Ever try shot non-UTF8 domains. Those are fun.

My email address is *@example.tld

Fails a lot of validations because ‘example’ can’t possible by right eh?!

This one actually almost makes sense because of RFC 2606 [1]. It reserves the .example TLD as well as example.com, example.org, and example.net as only example domains that cannot/should not be used. Back when .com/.net/.org were "the only TLDs that matter" a blanket check for example in the second level made some sense, and/or to just assume that RFC 2606 would apply to future TLDs (despite it being quite specific in which domains it reserved).

[1] https://tools.ietf.org/html/rfc2606

Some second level example addresses are actually reserved and not for use. See rfc 2606.

Similar experience with IDN domains. Most places altogether reject them, but those which accept them, only a subset accept IDN recipient in the mail address.

The SMTPUTF8 RFC to support non-ASCII local parts is from February 2012 and thus fairly new [1]. Postfix supports it since July 2014 [2] and to the best of my knowledge Dovecot still does not yet support SMTPUTF8 for LMTP.

Personally I did not enable SMTPUTF8 support in my Postfix due to the lack of Dovecot support.

[1] https://tools.ietf.org/html/rfc6531 [2] http://www.postfix.org/SMTPUTF8_README.html