Comment by ComputerGuru | Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

Parent Full thread

My problem with all these is simple: unlike dealing with people's names which, for the most part, they did not choose and have legitimate cultural reasons for the presence of special characters therein, it's not my problem if someone wants to register on my site with an (RFC-compliant!) email like @1st.relay,@2nd.relay:user@final.domain or a quoted email like (following payload is unquoted, quotes you see are part of the email address) "<>"@netmeister.org

I am going to put a (sane and reasonable) maximum length for email addresses on my postgres db column so it's not stored in TOAST; I don't care if you're technically allowed 256 bytes before the @ sign: I'm not wasting space in my database so you can feel special.

I do validate that the domain not only resolves but that it also has a valid MX record because this benefits ~100% of my users and protects them from their typos. It's not my problem if you want to register for my service before you set up your nameservers - its yours.

etc, etc, etc.

It's a fun thought experiment but there's no way in hell I'm going to advise any company to actually allow any of these and open themselves up to a can of worms.

A more sane list of rules would be things like "make sure you support - in the prefix or the domain" and others of its ilk. Also, I came across an email address that was created automatically from Active Directory to Azure with the apostrophe preserved (think "Sean O'Henry" turned into "sean.o'henry@example.com" and it blew my mind when that "just worked" in testing. These would be helpful rules because you'll actually encounter them in the real-world and not supporting them will genuinely inconvenience real people and not someone's PhD research.

> I do validate that the domain not only resolves but that it also has a valid MX record because this benefits ~100% of my users and protects them from their typos. It's not my problem if you want to register for my service before you set up your nameservers - its yours.

In absence of an MX record MTA will use an A record and a small but non-zero fraction of domains really has an A record pointing to a mail server.

Having no mx record and the domain A record pointing to a mail server is valid and is a small edge case. If one were to validate mx records for an a to spam measure using this the false positive rate would be extremely low. Really anyone not having an mx record and using the A record of the root domain I’d love to hear what you are doing. I didn’t even know this was a thing until a two years ago in a career of 20 plus years.

I did this for years with my self hosted mail server until Vimeo refused to let me register. Basically, I didn't see any reason anyone needs to know that I'm running a mail server unless they already know my address. I wondered if it might help me avoid spam. No idea whether it actually did, but I just figured it wouldn't hurt to be a little more discreet.

It's not a huge deal, but I would have preferred to continue without one.

Not an "instead of" approach, but the best thing I'd implemented when running an ecom site was a typo detector that prompted people to fix their email if it looked wrong, like "joe@gnail.com", "Did you mean joe@gmail.com?".

At the time I used "mailcheck": https://github.com/mailcheck/mailcheck

There appears to be a more modern implementation here: https://github.com/ZooTools/email-spell-checker

It reduced the amount of badly entered emails more than any other approach I tried.

The HTML <input type="email"> regex is a good starting point for "what's a valid email address": [1]

    /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

If you want to be a little more precise, the '.' characters in the local part cannot be consecutive nor occur at the start or end of the string. Also, the syntax does not account for EAI (add any non-C1 control non-ASCII Unicode character to the list of allowable characters), nor does it account for IDN (complicated, but it's IDN, there's libraries for it).

Unfortunately, email is in a weird space where there's a lot of clearly incorrect validators out there that fail on common stuff (e.g., dashes in domain names, weird TLDs, etc.), but trying to find a good one is hard because many people want to "help" by flexing how good they are at covering really, really weird cases that you honestly shouldn't want to support, like relay routing, or RFC 822 comments in email addresses (which aren't actually part of the email address!).

[1] https://html.spec.whatwg.org/multipage/input.html#email-stat...

Except that the HTML spec explicitly states just before that regex that what it checks is not whether it's a valid e-mail address, and that it intentionally rejects valid e-mail address.

Indeed.

<local portion>@<destination portion> is how I seem to remember "email address validation".

The '@' is the only reserved visible character.

The local portion is ONLY to be interpreted by the destination host.

Destination portion does not have to follow any pattern except to specify something (such as a path or resource name) findable by the mail server.

Of course, if you specify a destination only understood by your local email server as a destination in your LAN/WAN/whatever when talking to somebody/something outside that, they won't be able to reach you.

Addresses tend to look a lot more orderly than they used to, but I think this would be a "valid" address (within a given system):

12855977.233~foo+esr@bar!baz.crunchly!test%test#test\\splat\3

Reply on news.ycombinator.com