Hacker News Reader

Hacker News

Comment by young_unixer | Hacker News Reader

Full thread

young_unixer

Question: would it be correct to have an email of the type name@TLD? Example:

John@com

Is this kind of name spec-compliant?

View on HN

The operators of the .ai TLD for Anguilla have done this for a while and hit interesting bugs in mail clients.

(Also notable, they have an A record on the hostname "ai." - you can see their website at http://ai./)

the dot at the end is an ambiguity in a few specs. if I recall correctly, dns requires to end in a dot as it signals the root servers or something, but obviously can be left empty.

then browsers started to support it, but over time bugs pilled up and now it is treated as a different hostname (e.g. "www.example.org" is completely different to your browser than "www.example.org." even though they are the same to the dns spec)

then tls specs considers the dot in an earlier version, and they should be the same but because of the browser bugs it is all too much fun. my bank actually has a server that replies the same for domains with or without the root dot. but they only signed their certs for the no dot name, which again, is the same, but for browsers is kinda of not.

ah! living Standards.

The dot at the end has a technical meaning in two different contexts. The first is to disable search lists in the DNS stub resolver. If you try to look up, say 'ai', then the sub resolver is likely to append your current domain name during the lookup. Looking up 'ai.' disables that.

The other use is in DNS zone files where everything that does not end in a '.' get the name of the zone appended.

The for mail (SMTP) the dot at the end is implicitly present, and adding one is not allowed.

HTML/HTTP basically doesn't define semantics with respect to the dot at the end. That's why "www.example.org" and "www.example.org." are different. They are different strings, and nobody defined them to be equivalent. At the same time, the name is just passed to the stub resolver in many cases. So search lists may be applied under the hood.

Untrue. RFC 1738 was in fact quite explicit on this subject. It was almost universally disregarded.

* http://jdebp.info./FGA/web-fully-qualified-domain-name.html

ICAAN seemed to have prohibited this in 2013 [0], but "ai" still seems to be up so..

0: https://www.icann.org/news/announcement-2013-08-30-en

That's one of many ICANN rules which don't apply to country-code TLD operators.

Another example of a rule that's optional for them is ICANN's Uniform Dispute Resolution Policy. Indeed, only some of them have adopted it, with others using a variation and still others not basing any of their dispute mechanisms on the UDRP.

Pretty sad that this was prohibited for gTLD.

My (sister) company has the .schwarz tld, and they use blabla@mail.schwarz. Such a waste, really.

Your link will not work for all Systemd users, might want to mention that.

https://github.com/systemd/systemd/issues/6224#issuecomment-...

I get a "name not resolved" when trying to navigate to your link

are you using systemd?

Chrome on Windows

Yes, it is. But as with many things on the internet, it might be spec compliant but nobody can use it because most programmers didn't actually read the spec and thus implemented what they think is the spec.

Most websites will probably validate email addresses with regexes that expect a dot in the host part.

I still have trouble using .co instead of .com even. No dot would definitely throw a bunch of sites off.

The situation is even worse with more obscure TLDs like .FYI.

I honestly cannot register to a good 80% of the sites I want to.

I have a .red domain and haven't hit any issues so far.

There is also a human problem to consider, my spouse owns surname.com (their address is firstname@lastname.com , we run our own authoritative DNS and manage the MX records for lastname.com) , a bunch of people out there assume that they are such a foolish, technically ignorant person that they don't know how to properly format an email address. To the extent that signing up for some things in person just results in time-wasting questions and "what, really", so they just give a gmail address to some people.

I remember receiving a phone-call from a tiny online shop - they seemed to think I'd mistyped my email address, because it was "their-company@example.com".

They found it unbelievable that my email address could match their domain, and assumed I'd made a mistake.

I do this too and it's most fun when giving my email address to physical stores. One time I was in a random optician's shop and had to ask what the store was called, "Such and such" - "alright then, that would be such and such at example.com".

I use a catchall as well, but if I think my email address is going to be read by humans somewhere, I try not to throw people off by using something like firstname.companyabbreviation@example.com.

Absolutely. I am always worried someone will think .co was me being silly and replace it with .com when giving it to people in person. I normally add "no M" to make sure they realise it's intentional.

Because of this problem I'd be really hesitant to use .co for anything I care about unless I was Colombian or doing business primarily in Colombia.

Unrelated to TLDs but on the subject of email validation: I like to put a +<some sort of tag> after the name on my Gmail address. This is a perfectly legitimate thing to do to tag your emails. Most websites I've come across don't accept such an email address.

I've also yet to find a website that isn't fooled by gmail's dot trick. They all thing myname@gmail.com is a different address to my.name@gmail.com. In fairness this is not an email standard, but you'd think devs would have copped this by now and started to recognise multiple signups from the same user

Validator[0] node package seems to have a "normalizeEmail" function, site operators just need to start using it.

0: https://www.npmjs.com/package/validator

Or maybe they should send email to the address their users give them?

A human creating many alt accounts may not be desirable by a website owner, so requiring multiple real email inboxes or running a mail server adds another barrier to prevent spam.

Not really. I understand why website owners would like that, but it's simply not possible. In the worst case user will use mailcatch.com, aliases or one-time email accounts. No way you can check if the e-mail address is a "real" one. Fortunatelly.

You can’t entirely prevent it but you can certainly raise the bar enough to deter a substantial fraction of those signing up multiple times. Whether that’s worth the effort or not it a business decision.

Well now I’m really happy that some library doesn’t know how to remove the sub-addresses on my custom e-mail setup :-)

Other email services might not ignore periods, and might really have separate myname@example.com and my.name@example.com users. If someone is going to make a site that tries to ignore periods for equality, then they should hardcode it to email domains that they know do that.

Yes, that's what I meant by it not being a standard. They should be making a special rule for gmail

Honestly though: why bother? If you're really set on opening a second account, email validations won't stop you. If I as a service provider want to stop you, I'd check your address, credit card number, vat Id, etc.

If you're unsure whether you've already registered an account, I could understand the frustration of finding your "proper" dot configuration, but as a developer I'd figure that to be your problem.

Still works on Twitter an other top 100 sites, but many examples of regex matching skip this valid and useful case.

With Gmail you can move the dot around, it's effectively stripped, to make sorta unique ones. But everyone serious about validating against Gmail knows to strip it out.

I'm in a habit of putting it in and it seems to be about 50/50 as to whether or not any given site will accept it. Surprisingly, I've run into at least one YC company which doesn't like it.

It's rarer now than in the past, but I too still encounter sites occasionally that won't let me use the +label form.

I'm in progress to migrating to an e-mail in my own domain, and I'm enjoying the extra control it gives me. I now use e-mails in the form of label@username.mydomain, which get internally translated to username+label@mydomain. Beyond solving problems with broken registration forms, it also makes it more difficult for spammers/data brokers to normalize the address - I assume most won't bother.

I wish people would stop using regex to validate email. Literally the only way you can check if an email address is a valid one is to send that address a validation email ("Click this link to confirm this is your email address" type thing).

Validation emails also come with the added benefit of ensuring people enter their correct address (is not just randomly mashing the keyboard). Of course that doesn't stop them from using multiple addresses nor those burner address services, but neither would regex.

The problem is validation emails take more dev time to build so some people get lazy and use form validation such as regex instead.

Yes. About the only thing you can count on is `.+@.+`

A little more elaborate would be [^@]+@[^@]+. It might still be possible to construct an email address that is valid and does not pass via comments in the address, but chances that this happens are low.

That's a little more elaborate but, as you note, wrong. Just send email to the address.

This does not match my favorite mail address, "@"@example.org

Validating email addresses with regular expressions can make sense from a UX perspective alongside sending a validation email after the address has been validated as "likely a valid email address".

If for example during a typical registration process the software merely sends an email instead of also trying to validate the address first the user either has to wait until the email has arrived before entering the remaining data or otherwise might end up with invalid registration data that cannot be retrieved anymore. In this case, the user would have to start over again.

This problem could be alleviated by having a two-step process, during which the software merely asks for the email address in the first step and the remaining data can only be filled in after the email address has been verified. However, depending on the requirements of the software it might make sense to not just ask for the email address but additional required information during the first step as well, in which case validating with regular expressions provides a better user experience through feedback.

> Validating email addresses with regular expressions can make sense from a UX perspective

... only to people who are not listening to the complaints from users whose perfectly valid mailboxes are rejected by such systems. It seems somewhat hypocritical for designers to go on about "good user experience" when the user experience in practice turns out to be that it is impossible to give the system their actual electronic mail addresses at all.

* https://github.com/kdeldycke/awesome-falsehood#emails

It'd be interesting to investigate if there's useful common error patterns that can be detected and then prompt the user to check. E.g. "you entered an e-mail address @gmmail.com. Did you mean @gmail.com?"

Then you could do the hard-fail checks very conservatively and still catch some mistakes early.

One solution would be to be lenient as to what address patterns to accept, e.g. using a regular expression such as /\S+@\S+/ that catches common entry errors but doesn't keep the user from entering uncommon but valid patterns.

The idea here is to help the user avoid mistakes not to actually verify the email address. That's happening at a later stage, i.e. when the user clicks on a confirmation link.

>using a regular expression such as /\S+@\S+/ that catches common entry errors but doesn't keep the user from entering uncommon but valid patterns.

your regex is too strict and doesn't accept all valid email addresses. my."really uncommon".email@is.valid is a valid email address that you would be rejecting.

the sane regex is /.+@.+/. Anything beyond checking for an @ is getting into very complicated territory (even the domain part allows stuff like round and square brackets)

I concede your point. I haven’t come across that particular pattern yet but it’s certainly valid.

All you're checking is if the user has entered an at symbol. If your regex pattern is going to be that loose then what's the bloody point in even having one? I mean you're ultimately just going to rely on authentication emails anyway.

This expression not only checks for the @ symbol but also makes sure there are no white space symbols (which is a wrong assumption as user wongarsu has pointed out).

Anyway, the point is to assist the user, not to verify the email address actually is valid.

But if you're rejecting valid addresses then you're not assisting the user.

I don't care how they do it, so long as the service refuses to send any emails other than a confirmation email, until confirmed.

My simple gmail address gets added to some new service by someone with a similar name at least once a week. And those services may or may not ask for confirmation, but then proceed to not care either way. It's super annoying. I get that people sometimes can't be bothered to confirm an account, but it still feels somehow very wrong.

Forget SMTP, you’d have more problems with bad email regexes on sign up forms that assume anything more than an @.

This is why people should write proper code to parse and validate email addresses and not use regex

regex are proper code when written competently

Assuming "competently" means "not using them when the grammar is not regular".

I don’t even try. I put my hands up and accept [anything] @ [anything]

Well, you can still check MX record for the second "anything", that should be pretty safe, right?

I don't think that's sufficient on its own. If there's a CNAME on the domain, you'd have to follow the chain of CNAMEs to find an MX record (granted, that's not very common, but I think it's valid usage)

Resolving proxy DNS servers do that for you. A successful transaction against a resolving proxy DNS server yields a complete answer with all of the alias chain and the final resource record set (or "no such name" indicator).

* http://jdebp.info./FGA/dns-query-resolution.html

After you removed the comments from the second anything, and checked that it isn't a raw IPv4 or IPv6 address. jsmith@[IPv6:2001:db8::1] is a valid email address, as is jsmith@(comment)example.com.

Though you could argue that there are good reasons to disallow ip-based email addresses.

Thanks, didn't know that! E-mail is really full of surprises. :)

I am not aware of any specifications which would prevent using mail hosts on toplevel domains. However, dotless domain names are currently prohibited by the ICANN Board New gTLD Program Committee,[1] so actually creating one may be a challenge.

1. https://www.icann.org/news/announcement-2013-08-30-en

2. https://serverfault.com/a/721929/61174

Yes, and there are some traditional domains too with A records, at least this one:

  > host -t aaaa dk.
  dk has IPv6 address 2a01:630:0:40::58

I don't know if they run SMTP (my ISP blocks it) but at least it answers http://dk/ :)

Relevant informational RFC:

https://tools.ietf.org/html/rfc7085 (Top-Level Domains That Are Already Dotless)

Interesting but I suspect that whilst possible they would be reserved for the registry.

A bit like in x.400 you could have a mail address of say C=UK CN=brian" but only if you where the ADMD operator - btw my boss did have that email address when I worked on x.400

Yes it would! We used to have a fake TLD for our internal Network. It just works.

Reply on news.ycombinator.com