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: Rupert, 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 Weiß and 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?


The Parameter RFC822StripUnquotedDelimiters=1 definitely IS the solution for your problem.

AND: The problem IS caused by exchange, because it does not follow the RFC and "forgets" the delimiters around the comma separated names. Of course Outlook / Exchange sends a proprietary additional header- field with the "correct" address, so that outlook / exchange recipients can handle these malformed mails, but this is not standard- conform and therefore ignored by the domino server.

After setting the entry in the config- document you have to wait until it got populated to the servers' notes.ini (show config RFC822StripUnquotedDelimitersand) then restart the router task.

IMPORTANT: This setting has to be set on the server that does the mime- conversion. If you have a HUB- / SPOKES infrastructure, then this has to be set on the HUB, it does not help on the SPOKES....

  • Thanks for confirming; the parameter has been set close to a year ago, and we confirmed that it found its way to the "real" Notes.ini. - I edited my post and added some late info just passed by one of "my" admins – Lothar Mueller Mar 28 '14 at 16:53

There's an IBM technote (see here) that implies just the oppposite: that RFC822StripUnquotedDelimters works when the address is charset encoded, but that it didn't work if it was not charset encoded, and that you need to open a PMR with IBM to get a patch to fix that. Sounds to me like either the techote has it backward, or the new fix was integrated into 9.x and it broke the old fix! I think you'll need to call IBM and open a PMR with them to get a fix for the fix for the fix!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.