RFC5321 s2.4:

   The local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve the case
   of mailbox local-parts.  In particular, for some hosts, the user
   "smith" is different from the user "Smith".

   However, exploiting the case sensitivity of mailbox local-parts impedes
   interoperability and is discouraged.

And when that happens, trying to patiently pull a "well, technically" and explain to them about RFC this and the specs say that is a way to lose users.

(I actually have extremely strong feelings about email, email addresses and the whole associated mess of specs, but had to tone it down for this article since it was mostly about the various traps you can wander into from naïvely thinking that you can just read a spec or implement something obvious and get away with it)

Not in my experience. Showing compassion and agreeing with them that what happened is terrible and you wish things were different but you didn't call these shots back in the days and if they want improvement you can both go together and complain to google, the service which is actually broken.

Most people just want to be listened to. If you can do that, you'll earn a loyal fan, even if you don't do exactly what they tell you to when agitated. Some will even appreciate learning more about the email systems after the fact. They may even get the feeling you went above and beyond by offering to help them with matters outside of your site.

Many people, even after being listened to, and even after having things patiently explained to them, still continue to enter someone else's email address into forms which will send sensitive information to that email address, and complain that they never got their important email, or that some "hacker" has "hacked" "their" email, etc.

In a perfect world this would not happen. We don't live in a perfect world and are unlikely to live in a perfect world any time soon, so we should not be asking "how can we be pedantic and tell users it's their fault for not reading the RFCs", we should be asking "how can we protect users from their ignorance of the RFCs".

(when I wrote this article, I did not expect that this would be the single most controversial line in it from HN's perspective, but I guess by this point I should have anticipated it)

Has it? In my experience, even if people know dots and the part after the + don't matter for their Gmail account (and most don't) they know it doesn't matter to Gmail, a peculiarity they can use to create multiple accounts on a single website without creating new email accounts.

(This is different from case insensitivity, which the majority of popular email providers seem to implement.)

On the one hand, that's a (presumably extremely) rare corner case - on the other hand, some applications must handle those corner cases.

Do you want to run a support system where when you ask for people's username or email address, you also have to ask them for their casing (and in the case that their problem is that they didn't know it mattered, they may not know what they signed up for)?

I worked at an ISP for many years. Even though it was all backed by Linux, usernames (which included email addresses) were considered case insensitive for the purpose of the service (all usernames were lowercase). It solves so many problems and the downsides are so small all the sane email providers did it.

The flip side of this is that it was a simpler time. Usernames and email addresses were ASCII, not Unicode. These days with Unicode, you can't even be sure that uppercasing and then lowercasing an already lowercased string yields the same characters.