Есть ли способ заставить сервер Exchange устанавливать To: заголовок в сообщении, отправленном получателю скрытой копии? У нас есть административный доступ к серверу. Другие почтовые программы делают это, так что это должно быть возможно.
Пример - если я отправлю электронное письмо на адрес user1@a.com и отправлю его на адрес user2@a.com, user1 увидит свой адрес электронной почты в To: заголовок. User2 не увидит To: заголовок вообще. Я хочу, чтобы user2 увидел To: user2@a.com.
Для справки причина, по которой мне (думаю, мне) это нужно, заключается в том, что мы используем инструмент CRM под названием Insightly. Мы копируем электронные письма клиентов на адреса электронной почты Insightly, относящиеся к конкретному проекту, но Insightly не справится, если мы поместим адрес электронной почты в bcc поле в Outlook. Он справляется, если я отправляю одно и то же электронное письмо из почтового аккаунта на базе Linux, а сравнение заголовков выделяет недостающие To поле как наиболее вероятная проблема.
Очевидно, что я предпочел бы заставить Insightly исправить их программное обеспечение и прочитать что-то вроде Received for заголовок, но их служба поддержки клиентов непреклонна в том, что эта ошибка не исчезнет.
Изменить: немного дополнительных пояснений - когда я отправляю электронную почту через свою личную учетную запись электронной почты (linux webmail), человек, получающий скрытую копию, видит свой собственный адрес в заголовке «Кому». Когда я отправляю электронное письмо через свою рабочую учетную запись (Outlook), человек, получающий скрытую копию, вообще не видит заголовок Кому.
Скрытая копия не должна добавлять поле Кому: в заголовки электронной почты. Если бы это было так, получатели сообщения могли бы видеть, кому было отправлено сообщение, в отличие от того, для чего предназначена скрытая копия. Вместо этого bcc добавляет к заголовку строку Bcc :, которая отключается конечным принимающим почтовым сервером. Заголовок To: никогда не удаляется и передается в почтовый ящик получателя.
Обычно вы добавляете один обычный Кому: от себя или какой-нибудь общедоступный адрес или адрес без ответа. Это адрес, который увидят получатели. Затем вы добавляете свои скрытые копии. Получатель их не видит.
Ян,
Итак, сначала позвольте мне поделиться некоторой историей о том, как Exchange обрабатывает информацию BCC, здесь есть хорошая статья: http://gsexdev.blogspot.com/2011/06/processing-bccs-in-exchange-transport.html
Вы также можете найти информацию о том, как Exchange обрабатывает BCC, здесь: https://superuser.com/questions/476620/finding-bcc-in-internet-mail-headers
Далее, я собираюсь просто скопировать / вставить ответ этого сотрудника MS, поскольку он достаточно хорошо объясняет: http://social.technet.microsoft.com/Forums/exchange/en-US/faa6a8f4-7192-406f-bf7c-f41b52473e37/exchange-or-outlook-rule?forum=exchangesvrsecuremessaging
В поля показанные в пользовательском интерфейсе клиента Outlook не имеют ничего общего с доставкой электронной почты. Они созданы для удобства пользователя. Когда клиент Outlook отправляет сообщение, он составляет сводный список всех получателей, указанных в (Кому, Копия и Скрытая копия). поля отображается в его пользовательском интерфейсе. Используя этот список получателей, Outlook затем отправляет команду RCPT-TO на почтовый сервер для каждого получателя. Как только это будет сделано, Outlook выдаст одну (только одну) команду DATA, которая содержит ваше сообщение (заголовки, пустая строка-разделитель и тело). Почтовый сервер не знает, в каком поле был указан получатель, и ему все равно. В списке команд RCPT-TO, которые он получил, было сказано, кто являются получателями. Получатели никогда не видят исходный список команд RCPT-TO, которые отправитель отправил своему отправляющему почтовому серверу.
Заголовки в сообщении (то, что отправляется во время команды DATA) - это то, что туда помещает Outlook. Почтовые клиенты НЕ должны включать поле Bcc в свой заголовок сообщения, но некоторые устаревшие клиенты это сделали. Outlook должен вставлять только заголовки To и Cc, которые соответствуют значениям, указанным в полях To и Cc в пользовательском интерфейсе. Поскольку поле Bcc никогда не копировалось в заголовок Bcc в сообщении, в заголовках сообщения нет ничего, что указывало бы на получателей Bcc. А поскольку получатели никогда не видят список команд RCPT-TO, отправленных отправителем их почтовому серверу, получатель не может узнать, кому была отправлена скрытая копия.
Даже для старых почтовых клиентов, которые раньше включали заголовок Bcc в сообщение на основе значения поля Bcc в их пользовательском интерфейсе (как, например, возможность сделать это), многие принимающие почтовые хосты будут вырезать этот заголовок. Он не должен был передаваться, поэтому его удаляют, если он присутствует. Вся суть поля Bcc НЕ в том, чтобы создавать заголовок с этим списком получателей.
Итак, перейдем к сути дела. Exchange обрабатывает его не так, как вы привыкли на почтовом сервере Linux.
Но что вы можете сделать, если Insightly не изменит свое программирование?
Вот несколько идей, которые могут сработать:
1) Продолжите идею BCC, но сделайте 2 прыжка. Под этим я подразумеваю создание почтовых ящиков ресурсов или чего-то подобного в Exchange для адресов электронной почты проектов Insightly. Затем выполните скрытую копию этих адресов, и эти почтовые ящики будут автоматически пересылать всю электронную почту на «настоящий» адрес электронной почты проекта Insightly. В этот момент Insightly должен увидеть в нем фактический адрес TO. Не уверен, как он будет обрабатывать FW: info, но стоит попробовать.
2) Рассмотрите возможность простого размещения CC-адреса Insightly. Я понимаю, почему вы хотите сделать BCC, но, может быть, это вариант?
3) То же, что и # 1 выше, но укажите адреса электронной почты на почтовом сервере Linux. Затем пусть этот сервер запускает BCC Insightly после получения BCC от Exchange. Вам нужно будет использовать другой почтовый домен на сервере Linux, и пользователи Outlook будут отправлять BCC по электронной почте в этот домен (например, Project1@insightly.internal). Затем Exchange доставлял почту, предназначенную для внутреннего домена, на сервер Linux. Затем сервер Linux инициирует BCC для Project1@realdomain.com. Обидно и глупо, но тоже должно работать.
Надеюсь, это немного поможет. Это сложная ситуация, и я предполагаю, что из-за этого вы не можете просто отказаться от программного обеспечения CRM.