Я задал этот вопрос в Stackoverflow; Меня попросили повторить это здесь, на serverfault. Имейте в виду, что в первую очередь я разработчик Domino; мои знания об административной стороне Domino и других серверных систем несколько ограничены, так что проявите терпение;)
Прежде всего: задействованное программное обеспечение - это сервер Domino 9.0.1, стандартный клиент Notes 9.0.1, а также сервер Exchange на стороне отправителя (версия на данный момент мне неизвестна)
Имя клиента содержит специальные немецкие символы («ß»), и у него также есть «Доктор». как заголовок. В системе MS Exchange его компании он зарегистрирован на свое полное имя (я буду называть его «доктор Вальтер Вайс»); его письма рассылаются по следующей схеме:
Weiß, Rupert, Dr. <Rupert.Weiss@somecompany.de>
Если наш сервер Domino получает письма от той компании, отправителем которой он является, или от одного из участников в поле COPYTO письма, часть фразы RFC 822 его имени отправляется без кавычек, как показано выше.
Если сейчас я отвечу на эти письма, Notes, очевидно, разделит фразу на три разных имени: Rupert, Dr. <Rupert.Weiss@somecompany.de> и Weißименно в таком порядке. Следующее, что происходит, это то, что мой почтовый клиент, очевидно, теперь ищет имена во всех зарегистрированных адресных книгах, которые могут привести к действительным почтовым адресам для Weiß и Rupert. К сожалению, в одном из справочников есть кто-то, кого зовут Marianne Ruppert, а она раскапывается, разрешая имя Rupert (опять же, имена были изменены, чтобы защитить невиновных, но, пожалуйста, обратите внимание на немного другое написание между фамилией г-жи Рупперт и именем г-на Вайса ...) работа в совершенно другой компании, и, конечно же, время от времени случается такое, что кто-то в нашей компании этого не понимает и отправляет материалы не тому человеку.
Мы попросили Google об этом и нашли несколько подсказок относительно исправлений для сервера Exchange и некоторые флаги, которые можно установить на нашем принимающем сервере Domino (RFC822StripUnquotedDelimiters=1). Флаг на нашей стороне был установлен (Domino directory >> Config settings >> NOTES.INI settings for the receive server), но без какого-либо очевидного эффекта для имен, содержащих специальные символы. И администраторы клиентов не видят в этом свою проблему, поскольку кажется, что мы единственные, кто сообщает об этой проблеме.
Затем я написал некий агент LotusScript типа «До прихода новой почты», который искал имена без кавычек и исправлял их для меня. Это помогло решить проблему уже больше года, и я уже думал о внедрении этого агента во все наши локальные почтовые файлы. Но на прошлой неделе я получил еще несколько писем от нашего клиента, когда меня не было в офисе, и внезапно агент перестал работать, возможно, потому, что я выполнял репликацию на локальную реплику. Для меня это не имеет никакого смысла, но вот что случилось.
Итак, мои вопросы: - это известный сценарий и есть ли какие-то средства от него, желательно прямо на сервере, а не внутри отдельных почтовых файлов? - есть ли хоть какой-то способ предотвратить перерасчет почтового кода, чтобы результаты были написаны не совсем так, как искомые имена? Может быть, мы можем сделать эту службу менее устойчивой к ошибкам?
РЕДАКТИРОВАТЬ:
Я только что услышал от одного из наших администраторов, что упомянутый параметр Notes.ini работает нормально, если получающие имена не содержат специальных символов. Однако, если они это сделают, имена закодированы следующим образом:
CC: =?iso-8859-1?Q?Wei=DF=2C_Rupert=2C_Dr=2E?= <Rupert.Weiss@somecompany.de>
Похоже, в этом случае запятые были слишком хорошо спрятаны, чтобы их можно было правильно распознать?
Параметр RFC822StripUnquotedDelimiters=1 определенно является решением вашей проблемы.
И: Проблема вызвана обменом, потому что он не следует RFC и «забывает» разделители вокруг имен, разделенных запятыми. Конечно, Outlook / Exchange отправляет собственное дополнительное поле заголовка с «правильным» адресом, чтобы получатели Outlook / Exchange могли обрабатывать эти искаженные сообщения, но это не соответствует стандарту и поэтому игнорируется сервером домино.
После установки записи в конфигурационном документе вам нужно подождать, пока она не будет заполнена в файле notes.ini серверов (show config RFC822StripUnquotedDelimitersand), затем перезапустите задачу маршрутизатора.
ВАЖНО: этот параметр должен быть установлен на сервере, который выполняет преобразование mime. Если у вас есть инфраструктура HUB- / SPOKES, то ее нужно настроить на HUB, это не поможет на SPOKES ....
Есть технический комментарий IBM (см. Вот), что подразумевает прямо противоположное: что RFC822StripUnquotedDelimters работает, когда адрес закодирован кодировкой, но что он не работал, если был не кодировка кодировки, и что вам нужно открыть PMR с IBM, чтобы получить исправление, чтобы исправить это. Мне кажется, что либо у techote это наоборот, либо новое исправление было интегрировано в 9.x, и оно сломало старое исправление! Я думаю, вам нужно позвонить в IBM и открыть с ними PMR, чтобы получить исправление для исправления для исправления!