If 5% of ecommerce shops refuse to accept it, it's likely you being clever.

My email is refused by 0% of ecommerce shops... because I just have a normal email.

Don't be clever, pick a better email.

What's "normal", though? "<8-10latinalphanumerics>@gmail.com?"

My email is just "me@<my-last-name>.al"[1] which is just a tiny bit "unusual" - and over the years it got refused by a couple stores because of TLD. And Albania is not Cocos Islands, they're surely not popular with spammers.

If a store believes there's only ".com" gTLD and nothing else (this had really happened to me, some galaxy-brain made a form with a hardcoded ".com" suffix; not even ".net" or ".org" were accepted, unfortunately I don't remember the site) - well, fuck that store, their loss not mine. Worst case, if I really want something they sell, I'll give them a throwaway email - which will contribute to their mail bounces after some time.

__________

[1] ".al" is a ccTLD for Albania which is not a country of my citizenship or residence. I've picked the domain name as hack - because my first name is Aleksei and my first and middle names form "A.L." initials as well. That, and because all relevant .name domains were already taken.

Might sound strange but yes, me@<my-last-name>.al is being clever. You found a nice short clean email by buying a domain from Albania and setting up a me@ address. That's clever.

Think about it this way: either you can get some big brand .com email with no special username and never have an issue, or you can flail around 5% of the time and yell at the clouds.

Should everyone accept your email? Of course! I'm just saying you live in real life, and in real life people suck at building email forms. The problems you run into are on you.

> Should everyone accept your email? Of course! I'm just saying you live in real life, and in real life people suck at building email forms. The problems you run into are on you.

No, the problems they run into are caused by (at best) mediocre developers. They’re entirely to blame. We have specs and standards for a reason.

I honestly don't understand what you're trying to say. What's actionable about your view? You going to call up every business that doesn't accept your email and tell them their programmers suck? Businesses like this are never going away. It's a losing battle.

Instead you can just get a big name .com email and call it a day. Live your life without trying to make some statement about email standards.

> You going to call up every business that doesn't accept your email and tell them their programmers suck?

No, because it's not 1993, but I absolutely do use the contact forms or bug reporter for any website that doesn't accept my email. Most of them fix it, because it's objectively a bug caused by their non-compliant code.

I completely agree with the pragmatic response, and not only encourage it, but do this myself too. It is absolutely the correct advice in the situation.

However. I completely disagree with the conclusion “The problems you run into are on you.”

I didn’t create the problem by having the audacity to be from a different country.

We should totally shame developers/businesses who don't accept valid emails, just as we should continue shaming those with insane password policies or insecure practices.

This conversation reminds me of the 0.00001% of people that browse the internet with JS disabled and then complain about how so many sites don't work for them.

If you aren’t accepting very normal email addresses at perfectly valid TLDs, then you are a bad programmer. At least import a list of the new TLDs every ten years.

Of course they're a bad programmer. But we live in real life, where bad programmers exist.

Get a big brand .com email and you'll never run into an issue.

>> Don't get clever, just follow the spec.

I'd suggest being clever is wasting countless hours to handle your edge case. Or writing your own email validation in the first place.

> wasting countless hours

Isn't email validation a solved problem in that there are services or ready software which provide RFC-compliant validation? If some company is wasting countless hours to do something because of Not Invented Here syndrome, isn't that the same as some company deciding to write cryptography algorithms on their own and reaping what they sow?

> about 5% of ecommerce shops refuse to accept it

That's surprising to me because there is nothing particularly weird about your email address. What exactly do they complain about?

I would assume because it's only 2-chars (me) and they're filtering anything <3 as invalid.

Yeah, that's what I would guess as well. But there's a big difference between "follow the [ridiculously complicated] spec to the letter" and "don't do obviously stupid things like filter out email addresses with short names". The latter is good advice, the former not so much IMHO.

For a couple glorious years I had a 2-letter email address at a single-letter .com domain. It was rejected a surprisingly small number of times.

Ah, that's a good assumption. My initial assumption was some sites have a very dumb whitelist of valid email domains. This seems more reasonable (although, also dumb).

Quotes included or not?

Not. Obviously, or the rejection ratio would be a lot higher than 5%.

Your money is likely a minuscule part of the revenue and supporting your email would likely cost more. This was the point, that it is probably clever to choose a validation that covers 99.99% of customer emails rather than cover the whole spec.

If you can show that "just follow the spec" ends up opening up more opportunity than it closes off, then you can convince people. However, when gmail, outlook, etc. do not allow these zany e-mail addresses, you're going to have a hella hard time convincing me of this unless you are in the 1% of spenders.

Do GMail et al actually prevent you from sending to and receiving from these zany addresses? Or merely prevent you from creating one @gmail.com?

Creating one. But when you consider just how many customers are using gmail and outlook addresses, and not to mention, GSuite/fastmail/etc. addresses under custom domains, it makes more sense why rejecting @[email protected] is worth more than allowing some crazy e-mail feature that is effectively not used.

The routing features are obsolete; they go back to the days when lots of email users weren't on the Internet directly and had to use relays. They are still in the spec, yes.

I assume it comes from similar lineage as UUCP paths. Either way, email standards are a bit ridiculous. It needs the kind of rehaul that occurred with HTML5 of looking at what email implementations actually do and pushing them in one direction. I suspect that is not happening ever, so failing that there will probably always be things in the spec that just simply don’t work across everything anymore.