如果传入邮件的RFC 822短语包含特殊字符，则不会将其引入引号
我在Stackoverflow问这个问题; 我被要求在serverfault重复这个。 请注意，主要是我是Domino开发人员; 我对Domino和其他服务器系统的pipe理方面的知识有限，所以请耐心等待） 首先：涉及的软件是Domino 9.0.1服务器，Notes 9.0.1标准客户端，以及发件人端的Exchange服务器（版本目前未知） 客户的名字包含特殊的德语字符（“ß”），他还带着“Dr.” 作为标题。 在他的公司的MS Exchange系统中，他的名字是全名（我会称他为“Dr. WalterWeiß”）; 他的邮件使用以下模式发送出去： Weiß, Rupert, Dr. <[email protected]> 如果我们的Domino服务器接收到他是发件人的公司的邮件，或者邮件的COPYTO字段中的成员之一，则他的名字的RFC 822短语部分在其周围没有引号发送，如上所示。 如果现在我回复那些邮件，Notes明显地将这个短语分成了三个不同的名字： Rupert ， Dr. <[email protected]>和Weiß 。 接下来发生的事情是，我的邮件客户显然正在search所有注册地址簿中的姓名，这可能会导致Weiß和Rupert有效邮件地址。 不幸的是，在其中一个目录中有一个叫Marianne Ruppert ，她挖出了解决Rupert这个名字的名字（又改了名字来保护无辜者，但是请注意Ruppert女士的上一个和先生之间的略有不同。 Weiß的名字……）在一家完全不同的公司工作，当然这经常发生，我们公司的某些人不知道这一点，并把东西寄给错误的人。 我们询问了Google，并find了有关Exchange服务器补丁的一些提示以及可以在我们的接收Domino服务器上设置的一些标志（ RFC822StripUnquotedDelimiters=1 ）。 已经设置了我们这一面的标志（Domino目录>>configuration设置>>接收服务器的NOTES.INI设置），但对包含特殊字符的名称没有任何明显的影响。 而客户的pipe理员并不认为这是他们的问题，因为我们似乎是唯一报告这个问题的人。 接下来，我写了一些“在新邮件到达之前”types的LotusScript代理，寻找没有引号的名字并为我修复它们。 这似乎解决了一年多的问题，我已经想到将代理实现到我们所有的本地邮件文件中。 但是上个星期，当我不在办公室的时候，我收到了更多的邮件，突然之间代理商再也没有工作，也许是因为我正在复制到本地的副本。 对我来说没有任何意义，但这就是发生的事情。 所以我的问题是： – 这是一个已知的情况，是否有一些补救措施，最好是在服务器上，而不是在个人邮件文件？ – 是否至less有一些方法可以防止邮件的重新计算代码产生与查询的名称不完全一致的结果？ 我们可以让这个服务不太容忍反对拼写错误吗？ 编辑： 我刚刚从我们的pipe理员那里得知，如果接收名称不包含特殊字符，则提到的Notes.ini参数似乎工作正常。 如果他们这样做的名字是这样编码的： CC: =?iso-8859-1?Q?Wei=DF=2C_Rupert=2C_Dr=2E?= <[email protected]> 看起来好像在这种情况下，逗号太隐藏，无法正确识别？