Планирование / очередь больших писем в Exchange 2010, отложить до задержки

Мой вызов

У нас есть серверы Exchange на разных сайтах, но также и на кораблях. Корабли подключены к нашей сети через спутниковую связь, когда находятся в море, но переключаются на мосты WiFi, когда в порту.

Из-за высокой задержки (500+ мс) и нередких выпадений (например, когда корабли поворачиваются), попытка отправить любое электронное письмо размером более нескольких мегабайт в море может привести к сбою и повторной попытке до предела Был достигнут. Результат: электронная почта не доставляется, и каждая попытка потребляет ценную полосу пропускания по спутниковой ссылке.

Одно из "решений" - ограничить максимальный размер электронной почты, скажем, 5 МБ, но это вряд ли удобно для пользователя и является ненужным ограничением в порту.

Приблизительное представление

Что я предпочел бы сделать, так это поставить в очередь все электронные письма, размер которых превышает установленный лимит, для последующей доставки в море, при этом отправляя все небольшие электронные письма немедленно. Тогда я подумал, что буду регулярно пинговать транспортный сервер-концентратор в нашем центре обработки данных. Когда задержка становится меньше ~400 мс, я начинаю обрабатывать большую очередь сообщений электронной почты. Когда задержка превышает 400 мс, я закрываю дыру и позволяю электронной почте снова стоять в очереди.

Теперь, с Exchange 2003 я не сильно испачкал свои руки. В то время вы могли запланировать большие электронные письма для последующей доставки, поэтому моя идея заключалась в том, чтобы сделать что-то подобное в Exchange 2010, а затем написать сценарий для переключения доставки. график больших писем между "всегда" и "никогда".

препятствие

Создать такой сценарий не должно быть слишком сложно, но потом я прочитал, что функция, на которую я полагаюсь, была удалена в Exchange 2007:

Эта функция присутствовала в Exchange 2003, но была удалена для Exchange 2007. Она была установлена ​​на соединителе SMTP с "использованием разных сроков доставки для сообщений большего размера".

TechCenter: можно ли запланировать доставку электронной почты в зависимости от размера в Exchange?

Вопросы

Это правда? - Эта функция больше не присутствует в Exchange 2010 или просто превращена в нечто подобное, что я могу использовать для достижения своей цели? Если да, то?

Есть ли другой способ отложить доставку больших писем на определенные серверы Exchange? Это может быть основано на расписании или, возможно, даже на определенных действиях - я вполне уверен, что будет какой-то способ инициировать доставку с помощью сценария, мне просто нужны большие электронные письма в отдельной очереди на кораблях.

Ваши мысли по этому поводу будут высоко оценены!:-)

Edit # 1: уточненная грубая идея

Я наткнулся на два PowerShell CmdLets, которые, я думаю, могут приблизить меня к моей цели:

• Suspend-Message
• Resume-Message

Я поэкспериментировал с Get-Message, чтобы посмотреть, с какими сообщениями будут работать команды, приведенные выше.

Наиболее важно, что эти команды принимают фильтр размера сообщения. Эта команда выведет список сообщений в очереди на текущем сервере размером более 5 МБ (5 242 880 байт):

get-message -Filter {Size -gt 5242880}

Похоже на то Get-Message возвращает только сообщения из различных удаленных очередей доставки. Но отображаются ли сообщения, поступающие на сервер, хотя бы кратко, в очередь, с которой будет возиться Get/Suspend/Resume-Message?

Если нет, решение может быть таким простым, как запланированный сценарий каждые несколько минут, в соответствии с (в псевдокоде):

if ping_rtt > 400 Then
    Suspend-Message -Filter {Size -gt 5242880}
Else
    Resume-Message
EndIf

Проблемы / дополнительные вопросы:

В основном неактуальные сейчас - см. Правку № 2.

Будет Get-Message возвращать только сообщения из удаленных очередей доставки - никогда сообщения для внутрисерверной доставки? Если нет, то соответствует ли идентификационное имя очередей удаленной доставки определенному шаблону, который я могу использовать для фильтрации?

Может ли / должно ли это быть выполнено с помощью специального агента транспорта (как предложено @longneck) или приемника событий (если эта концепция все еще существует в Exchange 2010)?

Скажем, я запускаю скрипт каждые 5 минут, это все еще означает, что отправка больших сообщений может потенциально вызвать проблемы на срок до 5 минут, прежде чем будет приостановлено. Мы были бы лучше, чем сейчас, но это не оптимально. Я мог бы увеличить частоту до каждой минуты, но это было бы не самым элегантным решением.

Даже если я проверяю только время прохождения туда-обратно каждые 5 минут (для экономии спутникового трафика), какой механизм Exchange мне нужно настроить, чтобы сравнивать с последним записанным RTT, каждый раз при отправке сообщения, отправляемого на удаленную доставку очереди, а затем предпринять уместные действия?

Редактировать № 2: Предлагаемые решения

Позвольте мне кратко изложить предлагаемые решения, а также их плюсы и минусы, как я вижу это:

Таможенный транспортный агент

концепция

• Периодически контролировать задержку, классифицировать как высокий или низкий (порог: 400 мс?)
• Через пользовательский агент транспорта приостановить / возобновить все электронные письма, размер которых превышает установленный порог, при изменении классификации задержки
• Через пользовательский TA сразу же помещайте впоследствии отправленные большие сообщения в режим "приостановки", если задержка высока

Сильные стороны

• Большие сообщения никогда не доставляются при высокой задержке

Недостатки

• Нет навыков разработки, чтобы сделать это собственными силами (обратите внимание на себя: исходный код должен принадлежать моей компании в рамках контракта с внешним разработчиком)
• Стороннее программное обеспечение, связанное с Exchange, может вызвать проблемы при исправлении или обновлении
• Требуется какое-то соглашение о поддержке, если что-то пойдет не так (см. Выше)

Умеренные большие сообщения

концепция

• Периодически контролировать задержку, классифицировать как высокий или низкий (порог: 400 мс?)
• На основе классификации задержек настройте правила транспорта Exchange с помощью сценариев, чтобы все сообщения передавались или пересылали большие сообщения модератору.
• Утверждать сообщения в очереди модератора, когда судно находится в порту, возможно, человеком

Сильные стороны

• Большие сообщения никогда не доставляются при высокой задержке
• Сообщения приостанавливаются с использованием собственных собственных правил транспорта Exchange

Недостатки

• Судя по всему, сообщения не могут быть утверждены программно при низкой задержке, поэтому при каждом заходе судна в порт требуется вмешательство человека.
• Возможно проблемы с конфиденциальностью, если модерация не обрабатывается программно

Вопросы

• Могут ли сообщения быть одобрены программно из почтового ящика модератора? Как?

Запланированные команды PowerShell

концепция

• Периодически контролировать задержку, классифицировать как высокий или низкий (порог: 400 мс?)
• Пока задержка высока, часто (каждую минуту?) Приостанавливают любые большие сообщения (Suspend-Message -Filter {Size -gt 5242880})
• Когда задержка снизится до минимума, возобновите все сообщения (Resume-Message)

Сильные стороны

• Очень просто реализовать

Недостатки

• Не самое элегантное решение
• Доставка каждого нового большого сообщения может быть предпринята до тех пор, пока интервал между Suspend-Message команды, возможно, все еще тратят некоторую пропускную способность и создают заторы (хотя очень кратко по сравнению с тем, чтобы ничего не делать)

Вопросы

• Любые идеи о том, как предотвратить попытки доставки больших сообщений, между Suspend-Message команды?
• Будет Get-Message возвращать только сообщения из удаленных очередей доставки - никогда сообщения для внутрисерверной доставки? Если нет, то соответствует ли идентификационное имя очередей удаленной доставки определенному шаблону, который я могу использовать для фильтрации?

Правка № 3: путь вперед

После представления предложенных решений в моей команде (включая прокси-сервер SMTP, который я не смог включить в правку № 2) и основываясь на своем собственном интуитивном ощущении, мы решили использовать собственный транспортный агент Exchange.

Я нахожусь в контакте с несколькими консалтинговыми компаниями, которые ответят мне, как это решит проблему и сколько это будет стоить.

Если у вас есть опыт работы с задачами программирования на аутсорсинге, не стесняйтесь оставлять отзывы на мой связанный с этим вопрос о переполнении стека, потому что я этого не делаю.