Hacker News Reader

Comment by Lucent | Hacker News Reader

Here's another: Email addresses must have at least one dot.

There are MX records at the apex of .ai, so postmaster@ai probably works.

I once scanned many millions of emails to see what kind of "strange" addresses people are using. Everyone uses "@one-or-more-label.tld"; the only ones that didn't were bad spam scripts.

For all practical purposes for public services, it's a "truth", with the biggest real-world exception being "user@localhost" and such for local email delivery (or email delivery inside your network).

It depends which email addresses you are talking about. Email works with local addresses and mail relays will cleanup any incoming destinations without a host or domain name to be routed to whoever handles local mailboxes.

Technically, a trailing dot is required for the root domain.

"ai" is not valid but "ai." is.

Though I suspect a lot of software is quite lenient.

Conversely, the address joe@example.com. (with a trailing dot) is valid, but probably breaks countless programs.

Once upon a time it used to work for Youtube, but break the adverts. Halcyon days.

It seems like most MTAs just append it for you quietly, as someone who has chased ghosts through way too many smtp logs.

The domain can also be an ipv6 address with no dot. Really the only thing that can be said is there will be something, an @, and another something.

Are decimal & hexadecimal addresses accepted as email domains? e.g. root@2130706433 & root@0x7f000001

No. For IPv4 the dotted syntax must be used and for IPv6, the colon syntax preceded by the string “IPv6:”. In either case the whole thing must be enclosed in square brackets.

Technically, the address must also be surrounded by brackets.

Isn’t that what I said?

You’re right, you did. Sorry, I must have missed it.

Those would be interpreted as strings, not hex.

"Address literals" as domains are not something that will work widely; if my memory serves most MTAs don't have them enabled in their default configs.

I tend to use something like this rule, too. Except that I don't like having an IP in the domain part (it's valid, but screams spam), and a FQDN instead of a (possibly local/internal) hostname. So /.+@.+\..+/ it is for me (plus checking it's not an IP). Unless of course the application interacts with intranet hostnames, but imho those should be avoided these days anyway.

Imho it's more important to allow a user to fix a mistake: "We sent you a confirmation e-mail to $email_address. Spotted a mistake? Click here to change your email address."

i'm not sure there must be something before the "@".

I am certain. There must be something before the @.

The @ itself is optional (I believe the RFC disagrees, but on practice it is), but if it's there, there must be something after it too. So the only really required "field" is the one before the @.

ok, i admit the rfc may prescribes something like .+(@.+)?

i've just drawn the conclusion from that the local part is interpredet solely by the receiving party. that's why case-conversion should be avoided, since the receiving party may be case sensitive. so further thinking, local part can be empty perhaps, depending on the implementation.

Reply on news.ycombinator.com