I asked this question at Stackoverflow; I was asked to repeat it here at serverfault. Please be aware that primarily I'm a Domino developer; my knowledge regarding the administrational side of Domino and other server systems is somewhat limited, so please be patient ;)
First of all: involved software is Domino 9.0.1 server, Notes 9.0.1 Standard Client, as well as an Exchange server at the sender's side (version is currently unknown to me)
A customer's name contains special German characters ("ß"), and he's also carrying a "Dr." as a title. In his company's MS Exchange system he is registered with his full name (I'll call him "Dr. Walter Weiß"); his mails are sent out using the following pattern:
Weiß, Rupert, Dr. <Rupert.Weiss@somecompany.de>
If our Domino server receives mails from that company where he is the sender, or one of the members in the mail's COPYTO field his name's RFC 822 phrase part is sent without quotes around it, as shown above.
If now I reply to those mails Notes obviously splits the phrase into three different names:
Dr. <Rupert.Weiss@somecompany.de> and
Weiß, in exactly that order. Next thing that happens is, that my mail client obviously is now searching for names in all registered address books that might lead to valid mail addresses for
Rupert. Unfortunately, in one of the directories there is someone called
Marianne Ruppert, and she is dug up resolving the name
Rupert (again, names have been changed to protect the innocent, but please note the slightly different spelling between Ms. Ruppert's last and Mr. Weiß's first names...) working at a completely different company, and of course it happens every so often that someone at our company doesn't realize this and sends stuff to the wrong person.
We asked Google for this and found some hints regarding patches for the Exchange server and some flag that can be set at our receiving Domino server (
RFC822StripUnquotedDelimiters=1). The flag on our side has been set (Domino directory >> Config settings >> NOTES.INI settings for the receiving server) but without any obvious effect for names containing special characters. And the customer's admins don't see this as their problem since we seem to be the only ones reporting that problem.
Next thing I wrote some LotusScript agent of type "Before new mail arrives" looking for unquoted names and repairing them for me. This appeared to solve the problem for over a year now and I already thought of implementing that agent into all our local mail files. But then last week I received some more mails by our customer while I was out of office, and all of a sudden the agent didn't work anymore, maybe because I was replicating to a local replica. Doesn't make any sense to me, but that's what happened.
So my questions are: - is this a known scenario, and are there some remedies against it, preferably right at the server and not inside the individual mail files? - is there at least some way to prevent the mail's recalculating code to come up with results that are spelled not exactly as the names that are looked up? Can we make this service less tolerant against misspelling, maybe?
I just heard from one of our admins that the mentioned Notes.ini parameter appears to be working fine if the receiving names aren't containing special characters. If they do however the names are encoded like this:
CC: =?iso-8859-1?Q?Wei=DF=2C_Rupert=2C_Dr=2E?= <Rupert.Weiss@somecompany.de>
Looks as if in that case the commas were too well hidden to be recognized correctly?