Znuny and ((OTRS)) Community Edition

I am using this as the regular expression to check the TO field:
(?!helpdeskaddress@mydomain)|(.*@.*@)

Any ideas on how to make this case-insensitive (I'm not sure what Perl accepts as flags)?

Thanks for the info - I will look into that during the week. In terms of the response I presume it will use "PostMaster::PreFilterModule::NewTicketReject::Body" etc for the message that goes back to the sender? I have also found that some customers are including other people in the TO fiel...

We have a number of customers that are cc'ing our helpdesk address in their emails. They often cc other people as well and we end up with tons of new tickets created if they reply to the original email. I would like a way to: 1. Reject any emails that are cc'd (or bcc'd) to our helpdesk address. 2. ...

I gave up on getting this to work and eventually spent a few hours migrating from MSSQL to MySQL (and all the headache involved with it). It was well worth the effort; Things that used to take around 10 sec are now a few ms. My current setup is IIS7.5 + PerlEx + MySQL... and performance is excellent!

I typed too soon - I cannot reply to tickets now - get database errors.
I have reverted to the ODBC DSN for now.

Thanks for the this info - But that example DSN would be to connect to an Access database. This is my connection DSN (SQL running on port 1433): $Self->{'DatabaseDSN'} = "DBI:ADO:Provider=sqloledb;driver={SQL Server Native Client 10.0};Server=$Self->{DatabaseHost},1433;database=$Self->{Database...

Looks like DBI:ADO has some issues with some characters.
We have some tickets that cannot load (customer names contain é).

If we change back to DBI:ODBC then the tickets load.

Does anyone have a suggestion of how to fix?

Ok - Looks like ADO does not work well with unicode strings. We have some tickets that include these that don't load anymore. :( One was sent by a customer with the chacter é in their name. If I change the DSN back to use DBI:ODBC then it works (but is slow again). Does anyone have any thoughts on h...

We rolled out OTRS at our office in November 2012; and as a MS based company we decided to go the IIS + MS-SQL route. Unfortunately performance was dismal... Clicking on anything took around 10 seconds to load. We are running multiple OTRS instances on the same IIS instance (to different MS-SQL data...