Хранение электронных писем в другом месте, когда Exchange Server понижается
Пакет находится в squeeze/sid, просто установите libapache2-mod-xsendfile после добавления любого repo к Вашему/etc/apt/sources.list.
Я не знаю, почему это не было включено прежде. Не в конюшне по крайней мере, так очень я знаю.
Править:
У меня нет разряда для редактирования других пользовательских сообщений, но здесь идет Sam.
Если Вы хотите использовать dpkg-i для установки пакета, необходимо будет загрузить отдельный пакет, выбрать архитектуру и загрузку.
пример:
dpkg -i libapache2-mod-xsendfile_0.9-2_i386.deb
Я предлагаю добавить, сжимают или sid к/etc/apt/sources.list и затем используют склонный (загрузит, установит и удовлетворит любые зависимости для пакета):
apt-get install libapache2-mod-xsendfile
Если Вы хотите использовать способное прикрепление, используют что-то вроде этого в Вашем/etc/apt/preferences
Package: *
Pin: release a=stable
Pin-Priority: 700
Package: *
Pin: release a=testing
Pin-Priority: 650
Package: *
Pin: release a=unstable
Pin-Priority: 600
Это заставит стабильный быть более высокого приоритета, чем тестирование (сжимает) и нестабильный (sid) и таким образом использует стабильный в качестве значения по умолчанию при загрузке пакетов способными инструментами.
Вы могли установить любое количество механизмов обработки отказа, но во всей действительности, 99% всех почтовых серверов просто поставят электронную почту в очередь (обычно максимум для 48 часов) и продолжат повторять отправку электронного письма, пока Ваш сервер не будет доступен снова.
RFC 5321 объясняет подробно, как отправка и получение электронных писем работают.
Две важных вещи в нем я упомяну здесь
1) Почта, которая не может быть поставлена по любой (временной) причине, ДОЛЖНА быть поставлена в очередь и повторена в более позднее время. Здесь цитата
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. It MAY
be appropriate to set a shorter maximum number of retries for non-
delivery notifications and equivalent error messages than for
standard messages. The parameters to the retry algorithm MUST be
configurable.
2) Почта, которая не может быть поставлена вообще, ДОЛЖНА быть обозначена к отправителю. Здесь цитата:
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path).
Таким образом, если все почтовые серверы будут действовать соответственно к стандарту то не будет никакой почтовой потери вообще. Но сказано, что существует несколько почтовых серверов, которые не следуют правилам. В этом случае это не должна быть Ваша обязанность принять их письма во всех случаях только потому, что у них есть дрянные серверы.
Я рекомендовал бы иметь "холодно-резервный" почтовый сервер, который Вы загружаете только в случае долгого времени простоя Exchange.
Как длинный сервер не снижается слишком долго на больше, чем (два или три дня), почти вся Ваша почта прибудет. Почтовые работы на основе промежуточной буферизации и вышестоящих серверах будут периодически повторять. Я верю стандартным состояниям, которые они должны повторить в течение четырех дней или около этого.
Хорошие новости являются большей частью спама, поставляется серверами, которые пробуют только однажды, таким образом, Вы не должны будете фильтровать огромное отставание спама.
Установите хорошую систему предупреждения и UPS, и необходимо быть хороши для большинства случаев. Мое соединение с моим ISP понизилось во время шторма, в то время как я был на каникулах, и я смог разрешить ситуацию через несколько дней.
На самом деле я дважды испытал случай, когда, когда сервер выходит из строя, почта не задерживается и не доставляется. Ситуация использует Exchange 2003, Интернет отключился, маршрутизатор, используемый между сервером Exchange и Интернетом, был UPNP, для его настройки использовался мастер.
После того, как Интернет был снова подключен к сети, менее чем через 12 часов с момента его отключения сервер обмена все еще не мог подключиться к Интернету, пользователю пришлось снова запустить IECW на сервере, чтобы все заработало, ни одно из электронных писем во время простоя когда-либо снова появлялся.
Это казалось единичным инцидентом, пока он не повторился месяц спустя. Тот же сценарий, тот же сервер, тот же маршрутизатор. Не уверен, виноват ли маршрутизатор или сервер, но с тех пор вручную настроили маршрутизатор, чтобы, надеюсь, предотвратить это в будущем.
Так что решение для резервного копирования может оказаться не таким уж плохим.