Email Address Length FAQ | Hacker News Reader

Email Address Length FAQ

eph.co.uk

24 pointsnreece18 comments

Wouldn't the shortest possible Email address be 3 characters long, as in "a@b", where b is a TLD with a MX record, or did I failed to understand something critical?

You are correct. Although I don't think there are any TLD's with one letter.

Sean Hastings <sean@ai> seems to be real, and ai has an MX record.

.ai seems to be a "personal TLD". Most of the websites I've found on the tld (www.ai and nic.ai) are written in first person. The registrar (same person?) takes 3 months to approve accounts after charges before giving you the domain, dns changes are made on weekends, and 2nd level domains (ie hn.ai) are reserved for residents and local companies. I don't have a problem with any of that. I'm just curious how you find yourself in charge of such a setup.

It's the TLD of Anguilla, and Anguilla is quite small (population of 13000, area just over 100 square kilometers), so most likely the internet of Anguilla is maintained by just a few persons whose first priority isn't the TLD and the domains in it.

Personal TLDs don't exist (at least as far as I know). Some registrars are just tiny, AdamsNames for example which maintains .TC, .VG and .GD.

Couldn't find that Email address listed anywhere. Do you have some further information?

[edit: Looks like my view is just plain wrong. Skip this and directly read the replies]

IMHO email address fields need not be 254 characters in length. Something like 64 is perfectly defendable I think.

Why would a person sign-up with an email address of 200+ characters if he is not looking for a buffer overflow? Why would a sane person even bother to have such a long email address? How much time would he take to type that?

He would have tried the email id on many other websites and some of them should have rejected it. So the person obviously does have a shorter version of his email address for those sites.

How would a person fill in the emial address in a paper form where there is something like 30 fields for the email address?

I'd say 64 is enough. Anything above is just weird. I can do away with those two users who have such long ids.

How do you defend deliberately making something fail, when there's no benefit whatsoever?

A uuid is 32 characters all by itself, and you can't get much shorter without having to start managing the way they're allocated. Not all addresses represent people.

What would you gain from limiting it to 64 characters, versus complying with the RFC?

Remember the days of 640Kb of ram and 360k disks?

What did you lose by making your database not fit on a disk because you allowed 256chars for an email address and 32768 for a surname?

That's actually addressed by the original post:

  The memory used by a VARCHAR or VARCHAR2 data type is
  dependent on the actual size of the contents, not the 
  maximum size specified. For example, one million email 
  addresses defined using VARCHAR(255) will only take up 
  approximately 23MB, not 255MB.

Do you know how recent SQL databases on small computers are?

Given that conforming with the standard is effectively free, do you have any other justification for your non-conformal position of "I'd say 64 is enough. Anything above is just weird"?

Willfully and capriciously ignoring standard requirements that you think are "weird" results in non-conformal implementations that confound users and other developers attempting to interoperate with your systems. I'm genuinely surprised to be writing a paragraph defending standards conformance -- I'd have thought that this position was basic common sense among software developers.

Conforming with the standard is not "effectively free".

The only way to _really_ validate an email address is to try to send mail to it. But that has non-zero cost (depending on how often you have to do it, what the odds are that you'll end up on a spam blacklist for no good reason, etc., etc.).

The alternative is to use purely server-side validation routines. But these become more and more expensive as you progress through less common edge cases (e.g., regular expressions are not capable of detecting every valid address). So most people, sooner or later, make a trade-off, favoring some more common subset of cases over some less common subset.

If anything, we should be arguing over what constitutes an acceptable place to make that trade-off. Should embedded comments be supported? What about bang paths?

If you are not going to email to it, why bother asking/storing it?

Maybe you don't need to send email right away, but want to store the address in case you need to get in touch with the user?

Sending one email per signup can be problematic depending on the volume of signups. Sending email only when absolutely necessary can help with that.

If you really care, use a real standards-comformant address parser, most languages have at least one -- Java does. Otherwise you're just wasting your time, and the time of any users you hose with your amateur-hour validation.

I wrote a greylist server ( http://www.x-grey.com/ ) and I arbitrarily capped emails at 108 characters. In testing, I collected 565,012 tuples (IP address, sender address, recpient address)---the longest in that testing corpus was 107 characters (15), the average length was 24.24 characters and the median was 23 (just checked now). Capping at 108 meant I could store two addresses, plus a IPv6 address, plus some timestamps in 256 bytes of memory (one feature of my greylist implementation---everything is stored in memory).

Over the year and a half it's been running, I have seen a few addresses exceed the 108 character limit (which isn't fatal as I do store such addresses, only the first 108 characters) and by few I mean "less than 1% of 1%". Bumping the record size to store a full 254 bytes (or is it characters? There is a difference) would double the memory consumption of the program for very little gain in return (but at least I have numbers to back up my position).

Isn't @a.gg (nothing before @) valid as an email address according to the RFC? That was my conclusion last time I parsed it..

Reply on news.ycombinator.com