Hacker News Reader

Comment by inopinatus | Hacker News Reader

The local part (left of the @) of email addresses is case sensitive by definition and this should not be controversial.

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".

Even though it goes on to say:

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

This doesn't prohibit a local delivery agent (such as Gmail) consolidating multiple variants into one mailbox, but everything up until that point must refrain from making assumptions.

View on HN

That's definitely controversial, and in my experience, just plain wrong. Many, many users sign up to a service with john.doe@example.com and get confused when they later try to log in with John.Doe@example.com. we had to add a fix for this in our django user model a couple years back. We havent had any complaints with the new, case insensitive system. IMHO this sort of this should be upstreamed but it seems Django have decided to stick with the spec in spite of usability.

As you clarify later, both case-sensitive and case-insensitive are wrong. What you generally want is case-preserving: store the original case, but allow case-insensitive matches to select it.

This is an especially common problem when entering email addresses on mobile. Often autocorrect will capitalize the first letter. I always make sure it’s lowercase when registering, but I can see how this could easily lead to confusion.

Web pages (and apps) that don't indicate the input box is actually an email address so auto-correct won't capitalize for you are a serious peev of mine.

Oh also, we used a CITEXT field for storing email addresses. Store the case the user registers with, and use that for sending comms etc, but uniquify and match (on login etc) in a case insensitive way.

I ran into this problem as well and in the end added a separate field for the normalized (lowercase) form with a uniqueness check on that. Users would still be presented the original case and it would be preserved when sending e-mails but for identification/uniqueness purposes e-mails were considered case insensitive.

Right, something like "email_lc", and "username_lc". This would be your unique index.

Reply on news.ycombinator.com