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
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.
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!).