Клиент использует функцию «отложенной доставки» в Outlook / Exchange. По какой-то причине эта функция сохраняет исходное время создания сообщения (то есть, когда пользователь нажимает кнопку «отправить») в качестве заголовка RFC-822 Date :, поэтому даже если доставка сообщения действительно «отложена», заголовки по-прежнему несут доказательства того, что он был составлен незадолго до доставки. Мой клиент хотел бы вместо этого установить в заголовке Date: время, когда сообщение действительно покидает организацию Exchange, чтобы оно выглядело так, как будто оно было составлено и отправлено недавно.
Идея решить эту проблему состоит в том, чтобы установить заголовки Date: во всей исходящей SMTP-почте на текущее время сервера в среде Exchange 2007.
Я знаю, что могу настроить new-Transportrule с параметром -Action, установленным на Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SetHeaderAction, и определить замену «Date» другим значением. Однако я не вижу способа использовать там динамическое возвращаемое значение такой функции, как Get-Date - в лучшем случае результат Get-Date преобразуется в статическое значение, которое оно имеет при выполнении командлета new-Transportrule.
Лямбда-выражение / закрытие будет выполнять требуемую функцию (т.е. не вставлять статическое значение, а указатель на функцию и повторно оценивать выражение при каждом запуске), но, как я понимаю, Powershell не поддерживает их.
Уродливым обходным решением было бы очень частое переопределение (например, раз в минуту) правила транспорта с обновленным текущим временем, но я бы хотел избежать этого, если доступно более элегантное решение.
Есть идеи по этому поводу?
это является на самом деле это функция MUA (Outlook поддерживает это из коробки), но поддержка сервера, конечно, является дополнительным преимуществом, поскольку почта будет отправляться, даже когда клиент не работает. Также существует проблема: MUA устанавливает заголовок «Date:» при передаче сообщения на сервер, и сервер не изменяет его после выхода из очереди ожидания. Раньше было две функции в Outlook, которые выполняли аналогичную функцию - одно называлось «Отложенная доставка», другое - «Отложенная подача». Очевидно, последнее - это то, что здесь нужно, но оно было удалено в Outlook 2000 и никогда не было повторно введено - возможно, потому, что команда Outlook пыталась поучиться у Apple.
Настройте клиент Outlook так, чтобы он не отправлял сразу при подключении. Они составляют сообщение и нажимают «Отправить», как обычно. Сообщение находится в их почтовом ящике. Когда они «на самом деле» хотят отправить сообщение, просто откройте его в папке «Исходящие» и нажмите «Отправить» еще раз, это пометит время сообщения повторно. Затем выполните отправку / получение в Outlook. Никаких свидетельств оригинальной даты / времени композиции в заголовке не видно. В качестве альтернативы (и, вероятно, лучшее решение) просто составьте и сохраните сообщение в черновиках, а затем отправьте его, когда вы действительно хотите его отправить ...
Я знаю, что это не решение, как вы описываете, которое вы хотите на уровне сервера глобально для всех сообщений, а скорее обходной путь для клиента. Очень раздражает, если таких сообщений много, но пара в неделю / месяц для них не так уж и плохо. Странное требование от клиента ... «Отправьте сообщение, но НЕ НАСТОЯТЕЛЬНО отправляйте его, пока я не скажу ...» Если вы не хотите отправлять сообщение, НЕ нажимайте кнопку «Отправить» ...
Другая возможность - даже не использовать Outlook для отправки сообщения, составить сообщение в блокноте, сохранить его как файл eml в поддерживаемом формате и написать сценарий, чтобы поместить его в Подбирать папку на сервере Exchange в соответствующий день / время для доставки.
Я знаю, что это не ответ на ваш вопрос. И я не жду голосов "за", но не "против".
Отложенная доставка - это неправильно спроектированная функция. Это избавляет людей от размышлений. Они могут нажать «Отправить», а затем подумать и сказать: «О, я хочу отменить« Отправить »». Но это должно быть «Подумать», а затем «Отправить» или «Отменить». Та же проблема возникает с проблемой «Корзина». Кто-то изобрел эту ужасную особенность, и теперь вы можете видеть ее повсюду. И люди больше не думают. Сначала удалите, а потом подумайте, почему удаление было ошибкой. Сейчас все жалуются, почему для всего нет корзины. (Выйти замуж за кого-нибудь, а потом спросить, где кнопка отмены).
Но есть еще одна психологическая проблема, связанная с этой особенностью. В настоящее время все думают, что электронная почта - это средство мгновенного общения (это не так!). При нажатии кнопки отправки письмо должно прийти получателю. Поскольку это верно для большинства писем, по крайней мере, в течение нескольких секунд, все, что вызывает задержку, является неудобством. Отсроченная доставка на стороне клиента и серые списки на стороне получателя создают такие неудобства.
Я не знаю ни одного почтового сервера, который бы включал эту функцию прямо из коробки. Наверное, потому, что в этом нет необходимости. На мой взгляд это не часть MTA. Это должна быть работа MUA. Перед тем как (вновь созданные) письма будут доставлены на хост-ретранслятор, клиент должен предложить диалоговое окно подтверждения: «Вы действительно хотите отправить это письмо? Пожалуйста, просмотрите, прежде чем нажимать« да ». [ДА] [[НЕТ]]« Возможно, даже с КАПЧА.
Сказав это, вы должны подумать об изменении Outlook вместо Exchange для этого.
Я не могу проверить это сейчас, но помню, что на последнем месте, где я работал, мы работали с Exchange 2007 и Outlook 2010. Мы фактически столкнулись с другой связанной проблемой, потому что пользователи ноутбуков с Outlook в кэшированном режиме использовали эту функцию и сообщения не были доставлены, если клиент не был запущен и подключен к VPN или в офисе. Мы проследили это до того, что если клиент работает в режиме кэширования, то поведение похоже на отложенную отправку; сообщение находится в папке «Исходящие» на клиенте, а не на сервере. В результате клиент должен быть открыт для отправки в нужное время, а метка времени - это время отправки.
Если я правильно помню и это поведение не изменилось, это может сработать.