Page MenuHomePhabricator

The migration script shouldn't be case-sensitive when processing email addresses
Closed, DeclinedPublic

Description

I haven't verified, but yes I do believe the email comparisons are case sensitive, but only if someone used case in the original system. We could look at changing it but it hasn't been a problem thus far.

Two cases have been reported (T75818 and T76169) and we still have thousands of potential users to go through the migration script. Considering that the fix is probably simple, we should consider investing some time on it.

Event Timeline

Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil added projects: Phabricator, RT-Migration.
Qgil changed Security from none to None.
Qgil added a subscriber: Qgil.
Qgil renamed this task from The migration scrip shouldn't be case-sensitive when processing email addresses to The migration script shouldn't be case-sensitive when processing email addresses.Nov 28 2014, 7:45 AM

(While it's kind of insane and not actually common in practice, as far as I know, the domain name is case insensitive, but technically the name part is case sensitive. For example: Bob@example.com and Bob@EXAMPLE.COM are equivalent. But Bob@example.com and bob@example.com could theoretically be different.)

Interesting...

http://www.faqs.org/rfcs/rfc2821.html

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. Mailbox domains are not case sensitive.

Despite of this, several articles state that ISPs are ignoring this, and they are treating the whole email address as not case sensitive.

FWIW I went with case sensitivity (I see it as honoring whatever the user set as their actual email in the source system) to avoid any confusion about history claiming and imposter scenario's. Granted, Phabricator does not seem to respect the case sensitive nature of the local part at the moment anyway, but I don't want to have to keep track of that in case they decide to change it as it would cause large issues if abused. I'm not really against changing this necessarily, but the benefit is small and user's are responsible for their own case choices. I would vote for some text in the claiming history wiki portion and more wait and see.

Qgil claimed this task.

Decision: the script will keep respecting case-sensitiveness. Users hitting this problem only need to use the same case in Phabricator that they used in Bugzilla.

There's an issue with the 'add the right case' option: phabricator does not allow adding the same e-mail address with a different case, and it's impossible to remove the 'primary' mail address. I feel asking people to first add and confirm a second mail address, then to remove and re-add their bugzilla address might be a bit much to ask.

Can we maybe check how many e-mails are case-duplicates in the bugzilla database, and adapt the conversion script if there are none...?

I understand your point, but in this case out of 650+ users there have been two cases where they resolved it themselves fairly painlessly.

It isn't just about seed emails from bz and case, it's also about not being able to control email providers. If your email is @someweirdprovider.com and they use case sensitivity anyone with an address there would be vulnerable.

Hopefully it remains a very small minority for whom fixup is not a big thing.

Thanks for that clarification. I had not considered that situation, and if it's not a UX problem for those two users, I think the conclusion WONTFIX is the right one.

http://www.faqs.org/rfcs/rfc2821.html

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. Mailbox domains are not case sensitive.

The purpose here is to avoid a situation when SMTP knows only about FooBar and, when queried for foobar, refuses to acknowledge that it exists.

  • Where a user signed up as FooBar@example.com, mind the case.
  • When you have two entries, foobar@example.com and FooBar@example.com, treating them as identical sounds fine to me, per "Phabricator does not seem to respect the case sensitive nature of the local part at the moment anyway".
    • "I don't want to have to keep track of that in case they decide to change it" -- they are not stupid. If they do change it, they will make it configurable.

I don't want to have to keep track of that in case they decide to change it as it would cause large issues if abused

What large issues?

Discussing this feels moot nowadays.
Migration happened three months ago and if someone feels like fixing the migration script (that we do not need anymore) for whatever reasons, the code is there.

If there are cases of unclaimed BZ contributions in Wikimedia Phab due to having set an email address with a different case, bring them up in dedicated tasks (has happened two or three times so far and we have >1500 accounts here). Thanks.

Migration happened three months ago and if someone feels like fixing the migration script (that we do not need anymore) for whatever reasons, the code is there.

  1. Where?
  2. If I fix it, would you be able to re-run it?

Thanks.

10808

Migration happened three months ago and if someone feels like fixing the migration script (that we do not need anymore) for whatever reasons, the code is there.

  1. Where?
  2. If I fix it, would you be able to re-run it?

Thanks.

code: https://github.com/wikimedia/phabricator-tools
and probably not: https://phabricator.wikimedia.org/T76191#802442

If a Wikimedia Phabricator account is affected by this (different capitalization of email address), here are the steps (as I understand them) how account owners can fix their Phabricator account email address (taken from T85137#966940), as editing the primary address is not possible in the web interface:

  • Have some other (additional) email address that you have access to
  • Add that additional email address to your Phabricator account
  • Verify that additional email address
  • Temporarily make that additional email address the primary address
  • Remove the first email address which has 'wrong' capitalization
  • Add the first email address again with 'correct' capitalization
  • Verify that first email address again
  • Make that first email address your primary one in the Phabricator account settings
  • Optionally, remove your additional email address from that account
  • Wait for 24 hours so your Bugzilla contributions are picked up.