Does this impact usernames as well?

Does this impact usernames as well?

Technically yes, but they are not formally defined as case-insensitive so the impact is not as high because the username's usage is internal only.

I did some research on the e-mail address specification, which is driven by several internet standards, mainly RFC 2322, section 3.4.1 and RFC 5321 section 2.4 as well as some others with regards to the domain part. Reading those, it does in fact not state anywhere that an e-mail addresses is case insensitive, only the domain part is... The local part is domain-dependent, and defined as follows

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.

So it's effectively only a recommandation to treat an e-mail as case-insensitive, even though in practice this is effectively mostly the case; it's also considered best practice to only use lowercase characters.

I'm not saying we should not do this, but if so we need to have a clear understanding that this is making an assumption that could cause issues for some (admittedly) rare corner cases (case-sensitive domain with 2 mailboxes differing only by case). In any case, the e-mail address MUST be stored exactly as entered by the user and not converted to lowercase or whatnot.

Hi @dregad,

I didn't think the issue would deepen so much and see it more and more as a bug sitting between keyboard and monitor. In my case exactly what you quoted from the RFC happened.... I created the local part of the email address in lower case when creating the account for a user without consulting him, even though the user himself uses a case sensitive notation.

Since the second account was created by the email reporting plugin, I also think it is far too difficult to intervene in this automated process to request an admin assessment when potential duplicates are detected.

I think I will pay very close attention to the spelling in the short term and try to prevent such cases in the future through process adjustments. I may ask new users to send an email right away as an account request to the monitored address - so that I don't create accounts manually anymore. Or I will completely stop automatic creation and instead prefer to create uniform accounts via LDAP and no longer use the email address for identification.

What do you think about this? Is there actually anything else here that MantisBT could do better? I'm not sure anymore and would also agree if the tick is closed. Thank you for your effort and the friendly and open communication.

Many greetings, Matthias

I created the local part of the email address in lower case when creating the account for a user without consulting him, even though the user himself uses a case sensitive notation.

Which should not be a problem, unless your mail infrastructure were case-sensitive in which case your user created as user.name@domain.com would NOT receive e-mails addressed to him at User.Name@domain.com.

Of course, this is independent and out of control of MantisBT.

What we can do to improve this situation is to make the assumption that the vast majority of mail infrastructure out there is NOT using case-sensitive local part, and accept both user.name@domain.com and User.Name@domain.com (as well as other variations on case) as one and the same account when checking for uniqueness. I believe this would solve your (and most people's) problem.

Besides verifying the uniqueness of an email address. What is the plan around functions like user_get_id_by_email?
They also don't take into account case sensitive databases. Which can make finding a user based on an email address more problematic.

What is the plan around functions like user_get_id_by_email?
They also don't take into account case sensitive databases

I identified this problem also, and I intend to tackle it at the same time.

As a side note, user_get_id_by_email() is actually problematic when email_ensure_unique is OFF, because the DB could return multiple users but the function will just return one, exactly which one is not determined. IMO an error should be thrown in this case.

PR https://github.com/mantisbt/mantisbt/pull/1899

@dregad target version is set to 2.25.8, shouldn't it be 2.26.0?

The 2.25.8 target is intentional actually.

I really should have submitted things as 2 separate PR's.

@atrol following your remark I opened a separate PR (https://github.com/mantisbt/mantisbt/pull/1899) targeting master-2.25 with the fix for this issue.