Rt 3.8.4 case sensitivity for e-mail addresses

Hi

We’re having a small issue with e-mail case sensitivity. User
J.Smith@blah.com works as long as the case exactly matches, attempting to
reply to a case as j.smith@blah.com causes the following message:

RT could not load a valid user, and RT’s configuration does not allowfor the
creation of a new user for this email (j.smith@blah.com).

I’ve had a look through the wiki and the mail archives and drawn a blank.
Does anybody know if there is a way to make RT not care about the case of
the mail address

We’re using a MySQL backend and EXIM mta

regards
Garry

Dr Garry Booth
IT Services
Loughborough University

I’ve had a look through the wiki and the mail archives and drawn a blank.
Does anybody know if there is a way to make RT not care about the case of
the mail address
Check again. It’s nothing to do with the email address,
but rather the collation set for your MySQL tables.

Note that even with a case-insensitive collation,
fulltext search is always case-sensitive… :-/

Also, remember, RT creates users automatically, and the lowercase version of the email address doesn’t match an RT user.

Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: 807.766.7331
Email: mike.johnson@normed.ca
Technology assistance: email nosmhelpdesk@normed.ca
Technology Emergency Contact (TEC) Mon-Fri, 8am to 5pm excluding stat holidays:
Off campus toll free 1-800-461-8777, option 8, or locally either
(705)-662-7120 or (807)-766-7500

Jerrad Pierce jpierce@cambridgeenergyalliance.org 18/09/2009 1:05 pm >>>
I’ve had a look through the wiki and the mail archives and drawn a blank.
Does anybody know if there is a way to make RT not care about the case of
the mail address
Check again. It’s nothing to do with the email address,
but rather the collation set for your MySQL tables.

Note that even with a case-insensitive collation,
fulltext search is always case-sensitive… :-/
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com ( http://wiki.bestpractical.com/ )
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com ( http://rtbook.bestpractical.com/ )

Check again. It’s nothing to do with the email address,
but rather the collation set for your MySQL tables.

Note that even with a case-insensitive collation,
fulltext search is always case-sensitive… :-/

Hi Jerrad
Thanks for this, I’ve had a look at the collation on the tables and it is
set to utf8_general_ci, which I thought was case insenstive?

regards

Garry

Well something’s wacky with your installation.
I’ve not made any changes from the defaults in this area,
and just verified that RT did not create a separate user
for a differently cased email address.

Have you checked your logs? Are they set to debug?
The code closest to where your error occurs is:
lib/RT/Interface/Email/Auth/MailFrom.pm

Worse comes to worse, you can make a User_Local
overlay with a CanonicalizeEmailAddress method that
casts to lowercase.

Cambridge Energy Alliance: Save money. Save the planet.

Jerrad Pierce wrote:

Well something’s wacky with your installation.

It was indeed (I work with Garry)…

During the upgrade the application of the sql-queries script to modify
various tables we got a bit of output saying:

“Duplicate entry ‘[chinese chars]’ for key 2”

The script, however, seemed to complete. After a lot of digging on
Friday to compare/contrast charsets, collations and so on I found that
the Users table was mainly using data types of varbinary - it should be
varchar.

Somehow, in the past, a user had been created on submission of a spam
case which had a “nul” character in the email address or name. During
conversion it appeared that the “nul” truncated the data used in the
table’s index, making it use the same first three chars as another entry.

To fix it I had to drop the index, find the duplicates, shred them (so
they were fully removed), recreate the index, then complete the table’s
conversion. Following that we had to reassign cases, transactions and so
on to the right principals and then remove several others. It ended up
being stupidly long-winded, and all because we didn’t fully understand
the original warning message.

We now have no case sensitivity (which is a relief!).

Graeme