我在 Stackoverflow 上问了这个问题；他们让我在 serverfault 上重复一遍。请注意，我主要是一名 Domino 开发人员；我对 Domino 和其他服务器系统的管理方面的了解有限，所以请耐心等待 ;)
首先：涉及的软件是Domino 9.0.1服务器，Notes 9.0.1标准客户端，以及发送方的Exchange服务器（目前版本未知）
一位客户的姓名包含特殊德语字符（“ß”），并且他的头衔为“博士”。在他公司的 MS Exchange 系统中，他以全名注册（我将称他为“Walter Weiß 博士”）；他的邮件使用以下模式发送：
Weiß, Rupert, Dr. <[email protected]>
如果我们的 Domino 服务器收到来自他作为发件人的公司或邮件的 COPYTO 字段中的成员之一的邮件，那么他的名字的 RFC 822 短语部分将不带引号发送，如上所示。
如果我现在回复这些邮件，Notes 显然会将短语拆分为三个不同的名称：Rupert、和，顺序完全相同。接下来发生的事情是，我的邮件客户端显然正在所有注册的地址簿中搜索可能导致和 的有效邮件地址的名称。不幸的是，在其中一个目录中有一个叫 的人，她被挖掘出来解析这个名字（再次，名字已被更改以保护无辜者，但请注意 Ruppert 女士的姓氏和 Weiß 先生的名字的拼写略有不同......）在完全不同的公司工作，当然，我们公司时常有人没有意识到这一点，并将东西发送给错误的人。Dr. <[email protected]>WeißWeißRupertMarianne RuppertRupert
我们向 Google 寻求帮助，找到了一些有关 Exchange 服务器补丁的提示，以及可以在我们的接收 Domino 服务器 ( RFC822StripUnquotedDelimiters=1) 上设置的一些标志。我们这边的标志已经设置（Domino 目录 >> 配置设置 >> 接收服务器的 NOTES.INI 设置），但对于包含特殊字符的名称没有任何明显的影响。而且客户的管理员并不认为这是他们的问题，因为我们似乎是唯一报告该问题的人。
接下来，我编写了一些 LotusScript 代理，类型为“新邮件到达之前”，查找未加引号的名称并帮我修复它们。这似乎解决了一年多以来的问题，我已经考虑将该代理实施到我们所有的本地邮件文件中。但是上周，我在外出时收到了客户发来的更多邮件，代理突然不再工作了，可能是因为我正在复制到本地副本。这对我来说毫无意义，但事实就是如此。
所以我的问题是： - 这是一个已知的情况吗？是否有一些补救措施，最好是在服务器上而不是在单个邮件文件中？ - 是否有至少某种方法可以防止邮件的重新计算代码得出与查找的名称拼写不完全相同的结果？我们能否让这项服务对拼写错误的容忍度更低一些？
编辑：
我刚从我们的一位管理员那里听说，如果接收名称不包含特殊字符，上述 Notes.ini 参数似乎可以正常工作。但如果包含特殊字符，则名称的编码如下：
CC: =?iso-8859-1?Q?Wei=DF=2C_Rupert=2C_Dr=2E?= <[email protected]>
看起来好像在这种情况下逗号隐藏得太好而无法正确识别？
答案1
该参数RFC822StripUnquotedDelimiters=1肯定能解决您的问题。
并且：问题是由 Exchange 引起的，因为它不遵循 RFC 并且“忘记”了逗号分隔名称周围的分隔符。当然，Outlook/Exchange 会发送一个带有“正确”地址的专有附加标头字段，以便 Outlook/Exchange 收件人可以处理这些格式错误的邮件，但这不符合标准，因此被 Domino 服务器忽略。
在配置文档中设置条目后，您必须等到它填充到服务器的 notes.ini ( show config RFC822StripUnquotedDelimitersand) 中，然后重新启动路由器任务。
重要提示：必须在执行 mime 转换的服务器上设置此设置。如果您有 HUB-/SPOKES 基础设施，则必须在 HUB 上设置，这对 SPOKES 没有帮助……
答案2
IBM 有一份技术说明（参见这里）意味着相反的情况：当地址是字符集编码时，RFC822StripUnquotedDelimters 可以工作，但如果是不是字符集编码，您需要向 IBM 提交 PMR 以获取补丁来修复该问题。在我看来，要么是技术员搞错了，要么是新修复程序已集成到 9.x 中，并破坏了旧修复程序！我认为您需要致电 IBM 并向他们提交 PMR 以获取修复程序！