By default i believe MantisBT preferres UTF8 which defaults to utf8_general_ci as the charset for the database on standard MySQL database installations.
I tested on my installation and it catches higher and lower case as insensitive.
MantisBT does not seem to ever convert to lower case for this. So EmailReporting does not either.

What charset is your database your using? In particular for the email field in the user table?

Hello, thank you very much for looking at my request. It is a PostgreSQL database with Characterset de_DE.UTF-8. Do you think that the behavior could be a difference in the data type definition of the column? I had not thought that far. I have just looked into the schema with SquirrelSQL. The field username in the table mantis_user_table is of type varchar. In PostgreSQL this type is case sensitive. However, there is another type "citext" available which is a case insensitive text. However not in PostgreSQL core but as extension. If it is the case that the behavior is different in other databases, would a "tolower" in the EmailReporting plugin be something you could support?

It seems PostgreSQL is case sensitive at all times in its standard version without extensions.

Please check whether or not you can create a new user through MantisBT with varying cases in the email address. If that's possible you could report this as a bug to MantisBT and they could fix it systemwide.
EmailReporting will always try to emulate MantisBT behavior. We could make a setting to fix this though.
You could also write a small plugin for MantisBT yourself which processes the data and get the desired result that way.

Hello, sorry to have kept you waiting. I found the time to run the test today and you guessed correctly - I can use the same email address when creating an account in MantisBT several times if I vary the case accordingly. Since I have not been using MantisBT for a long time and am just getting used to it, I was quite surprised that the full-text search of the ticket filter seems to be case-sensitive as well. I will do some more research on this at the next opportunity. Shall we move the ticket for the current case to MantisBT until then? I agree that under the given conditions or with the findings, this one is more likely to be located there. Best regards, Matthias

Moved. Please update the issue information accordingly.

Hey guys,

Sorry about the ping-pong with this issue, but considering that the original report is clearly about the Email Reporting plugin, I would prefer if this was kept in your project (feel free to resolve it as not fixable if you want).

Please open a separate issue one to track the case sensitivity problem, we can then link it back to this.

That being said, please note that MantisBT does not enforce an e-mail address to be unique, there could be multiple user accounts with the same e-mail.

@dregad I think MantisBT tries to enforce this based on the $g_email_ensure_unique setting which by default is turned on. MantisBT does not take into account a case sensitive database during the enforcement.

We'll close the issue here and @mpeterma will create a new issue at his leisure.

based on the $g_email_ensure_unique setting which by default is turned on

You're right I forgot about this setting - I've used a tracker where this is actually OFF for a long time and it sometimes makes me confuse the real default values of some

We'll close the issue here and @mpeterma will create a new issue at his leisure.

OK, great.

I created 0032451 to track the issue in MantisBT core api.

I've used a tracker where this is actually OFF for a long time and it sometimes makes me confuse the real default values of some

As a side note, there is one good reason to have it set to OFF, if you are using a system that started with version < 1.3.0-rc.2, see 0020647

Hello everyone, I have followed the discussion closely and am glad that the topic has now landed in the right channel. Thank you and many greetings, Matthias