My understanding is that the guy running gg actually tried it, and found it did not work. Partly down to email clients, but annoyingly, whilst a top level domain can have an MX record, it is actually part of the RFC that disallows this.
RFC2822 makes domain :-
Domain = (sub-domain 1*("." sub-domain)) / address-literal
But the older RFC822 made it :-
domain = sub-domain *("." sub-domain)
So it used to allow a domain with no dots in it, but now requires dots.
Shame, especially for many of those applying for new TLDs as they cannot have things like info@google as an email address.
Update: See comments as it seems I missed something and such email addresses are valid, just unlikely to work.
Would it work if you just stuck a trailing period on the end, i.e. an 'empty' final domain?
ReplyDeleteNo, a trailing '.' is not permitted by the RFCs - see the ABNF definition above or check RFC5322 3.4.1.
DeleteNot sure how you read the RFC, but RFC 5322 (and 2822 which it supersedes) both have:
ReplyDeleteatext = ALPHA / DIGIT / ...
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
domain = dot-atom / domain-literal / obs-domain
dot-atom-text isn't '1*atext 1*("." 1*atext)' in either.
Note also that RFC5321 specifically mentions this case:
2.3.5. Domain Names
A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots.
I think it's more likely that MTAs tend to rewrite unqualified addresses into their own domain, or assume they are a local host. No '.' definitely looks far more like a hostname than a FQDN. It was common practise a few years ago to assume no '.' meant a local hostname, but these days seems to have fallen out of use a bit, both with centralised e-mail systems and as people make so much use of address books as they have so many contacts. Shortening addresses is just not needed so much.
It's also a consequence of the spam battle - localpart@hostname is so uncommon, and occurs in spam, so it's likely to get blocked.
The biggest problem is probably web page e-mail address verifiers. Most of them are horribly broken, and assume something much simpler than the RFCs actually allow (spaces in a local part, for instance - there's nothing syntactically wrong with "The Reverend"@gg, or even !@gg).
So although it sounds like a nice idea for a short address, it's likely to have so many issues you'd be unable to use it most of the time.
Very comprehensive reply, thanks. I obviously missed something there... I was copy/pasting from the RFCs.
Delete