A lot of people seem to be operate successful businesses without even allowing ‘+’ in the local part.

The fact that you are even looking at RFC5322 puts you in a whole different stratum to the 24-year-old computer kids who seem to have coded most of the software I seem to have the misfortune to bump into.

I would tend to support RFC5322 but:

- not bothering with quoted local parts

- not bothering with IP address literals

- not bothering with embedded white space and comments

Let us say that no-one comes up with a complaint (let alone a complaint which materially affects your or their business) for a period of say, 10 years; then I’d say compared to all the other problems in a typical person’s life, you had this issue licked.

The 255 CHARACTER limit (as opposed to OCTET) is for HOSTnames, which are different to DOMAIN names (so some hostnames cannot be stored on the DNS). Unless the RFCs are not using the term “domain name” correctly when giving the format of email addresses, 253 is indeed the maximum length of the text after the @ symbol.

This does, however, seem to conflict with domain names being able to have 128 labels. 128 labels of a single character, plus the 127 separator dots, makes 255. Which is too long. The only solution to this problem is if one of these labels is the (empty) root domain. Which makes the TLD the SECOND label, not the first. There could then be 127 (explicit) labels in a domain name, with 126 separator dots, brining the total to 253; the apparent limit.

And as the maximum length of an email address is 254 characters, as you yourself have mentioned in an errata to RFC 3696, a 253-character length domain name, plus the @ symbol, reaches the limit of 254. Thus, apparently, it cannot have email addresses associated with it. Unless, of course, an empty quoted string is used as the local-part (the double quotes are semantically invisible).

I completely agree with your last paragraph. My intention was to write an RFC-compliant validator, but some days I just let common sense get the better of me. I should have stuck to one or the other. I hope to do a new version (when I have time) that lets you switch between absolute compliance and the real world.

Or if not, presumably it would be a way to ensure an email was sent to the default account; that account which catches all unrouted mail to that domain.

For example, let us say that I have the domain andrewsurname.com, and have it hosted on some popular hosting company’s surver(s). The default email account would be something like andrew123. This email account would catch all mail sent to FakeAccount@andrewsurname.com.

Personally, I think that if you’re writing a validator that allows for commented obsolete quoted string local part email addresses with IPv6 address domain literals and folding white spaces, then you shouldn’t then decide not to allow for empty quoted strings because it’s not very practical.

You can see the detailed results from the validation tests here: http://www.dominicsayers.com/isemail/results.php

All the validators correctly allow the plus sign (the test case is user+mailbox@example.com)

I agree that sending an email is a great way of testing if it’s valid in the real world. I believe that checking its format is valuable too – no need to block the internets with test emails if the address is nonsense in the first place. Also some people might have need for an offline validator.

One school of thought that says you shouldn’t try and valdiate – just send an email and if it doesn’t work it’s invalid.

Also the security advantages of an obscure email address might well be outweighed by the inconvenience of having it rejected by all those brain-dead validators.

If you’re worried about people harvesting your address then just use a public one like I do (dominic_sayers@hotmail.com). I get buckets of spam to this address but I only use it for website registrations so who cares?.

I know some people who deliberately use email addresses [not this one, but different ones] that are designed to exploit obscure corners of the address grammar precisely because they don’t want address harvesters written by poorly-trained skript-kiddies using brain-dead regular expression processors to see them so easily.

I’m not sure you care about giving those people the hand and forcing them to use a more readily scanned and identifiable email address on your form, but it’s a consideration.