should preserve case in emails. #1350

callahad opened this Issue Mar 29, 2012 · 13 comments


None yet

8 participants

Mozilla member

We're currently downcasing email addresses, but doing it too late in the auth cycle. This means that a user can first assert, but will subsequently assert

Try it yourself!

  1. Log into as Note the "Yo,!" text.
  2. Type in your favorite beer and hit enter to save.
  3. Log out of and back into, choosing the same identity.
  4. Note that it's now "Yo,!", and that your favorite beer appears to be gone!

(It's not really gone; it's just stored under, which you can't assert again until you sign out of

So, that sucks, what do we do?

RFC 2821 explicitly states that "the local-part of a mailbox MUST BE treated as case sensitive," but discourages hosts from actually creating case-sensitive mailboxes. It'd probably be best to take a similar approach and preserve the case that the user initially gives us, but allow them to log into in a case-insensitive manner.

For a concrete example, say:

  1. A user verifies with
  2. We store in a case-preserving manner and assert to RPs.
  3. The user logs out of
  4. The user attempts to log in to as
  5. We do a case-insensitive lookup, find the account, authenticate the user against that, and assert to RPs.

Thus, the user always asserts the same casing, but can log in to without worrying about case.

Doesn't that break the RFC?

This deviates from the RFC for the sake of easing a common use case. We're letting users elect to present themselves with whatever casing they want (since it might be important), but assuming that no two people will have email addresses that differ only by case. This lets us automatically correct for typos when a user is logging into

We can further tweak this solution if it becomes problematic down the line.

What else should I look at?

This issue might also be relevant for #1104, #1328, and #1294.

Case sensitivity was brought up on the mailing list.

We also talked about this on IRC.


we should close down the other issues we have around email case and point them here

@ozten ozten was assigned Mar 29, 2012

technically you probaly don't want to use email addresses but acct: URIs (basically email addresses but can't necessarily receive email eg exists does not

There might be enough time to wrestle them into having a stricter definition than:

acctURI = "acct:" userpart "@" host
userpart = 1*( unreserved / pct-encoded / sub-delims )


Added the label...


That test case redirects me to /, is that intentional?


@graingert what do you mean?
Clicking the link above redirects you to "/" (whether or not you are already signed into MozTrap)?
Or the steps redirect you to "/"?

I have not seeing any issues.


@jbonacci this: Clicking the link above redirects you to "/" (whether or not you are already signed into MozTrap)?


@graingert - that is odd behavior, and unexpected... and, I can not duplicate it!
@csuciu and @jrgm can you try to duplicate this incorrect redirect?

Mozilla member

If not logged in, I am challenged, and on completion of that, I get redirected to / and that redirects to /runtests

If already logged in, redirects to / and that redirects to /runtests

Mozilla member

This is probably a permissions thing.


ah it should be a 403 not a 302 ?

Mozilla member

Have these been solved?

Mozilla member

Closing as we use the initial email address that the user types as the canonical email address. If the user returns and types in the same email address with different casing, the original email address, with the original casing, will be used instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment