Как гарантировать, что входящие электронные письма не будут потеряны при переходе на новый сервер?

2620
IMB

Я планирую перенести некоторые учетные записи WHM / cpanel на новый сервер, у меня сложилось впечатление, что во время перехода некоторые электронные письма могут попасть на старый сервер, даже если файлы уже были скопированы на новый сервер.

Можно ли предотвратить это, чтобы все входящие электронные письма во время перехода не потерялись?

2
Много ли аккаунтов электронной почты мигрирует? Вы меняете хостинг-провайдеров? Ваши нынешние хостинг-провайдеры предоставляют ваш DNS? Paul 11 лет назад 0
@Paul Да, довольно много почтовых аккаунтов. Да, смена провайдеров. Да, текущий обрабатывает DNS, у меня есть root-доступ, если это имеет значение. IMB 11 лет назад 0
У вас есть root-доступ к текущему серверу? Так вы можете закрыть exim? Paul 11 лет назад 0
@Paul Да, у меня есть root, поэтому я могу закрыть exim. * момент лампочки * Итак, я думаю, все, что мне нужно сделать, это: 1. Выключить exim 2. Переместить файлы 3. Обновить DNS, чтобы указать на новый сервер 4. Включить exim на новом сервере. Это оно? IMB 11 лет назад 0
Я бы рассчитал смену DNS на вечер пятницы, чтобы у него было время на обновление, прежде чем большинство людей начнут использовать его снова. Austin ''Danger'' Powers 11 лет назад 0

2 ответа на вопрос

5
Paul

Хорошо, это довольно просто из ваших комментариев.

  1. Измените ваши записи A и MX для TTL почтового сервера на что-то маленькое - 60 секунд
  2. Подождите, пока не истечет текущий TTL, и поэтому все используют новый 60-секундный TTL
  3. Выключение exim
  4. Полное резервное копирование на текущем сервере, полное восстановление на новом сервере
  5. Измените записи DNS и восстановите TTL до разумного значения

Поскольку вы сократили TTL, ваше окно простоя занимает много времени, так как вам требуется резервное копирование / восстановление файлов и изменение DNS.

Кроме того, когда старый сервер просто больше не принимает новые сообщения (не работает; не отклоняется с ошибкой), я предполагаю, что здравомыслящие отправители электронной почты в какой-то момент будут запрашивать новые настройки DNS? (Это, безусловно, может задержать электронную почту, если TTL не был изменен, но не должен доставлять почту на старый сервер.) Arjan 11 лет назад 0
@Arjan Да, поиск DNS не зависит от попытки отправки почтового сервера. ОС делает это. Поэтому, если почтовый сервер попытается отправить, он выполнит поиск и получит старый IP-адрес, а затем не доставит, потому что exim не работает. Поскольку TTL для записи составляет всего 60 секунд, то через час (или независимо от того, как настроена повторная попытка) ему придется выполнить новый поиск DNS - если это происходит после изменения DNS и запуска нового сервера, он доставит к новому exim. Paul 11 лет назад 0
0
Zac B

Другой метод (если какое-либо время простоя вообще неприемлемо для вас) - это использовать Postfix или аналогичный в качестве ретранслятора с задержкой.

Вы можете запустить сервер как ретранслятор, а затем настроить пороговое значение сканирования на очень высокое (и продолжать расширять его, если у вас увеличивается окно обслуживания, что они часто делают: p). В качестве альтернативы, вы можете блокировать брандмауэр любыми попытками исходящей ретрансляции / отправки таким образом, чтобы Postfix (или что-то еще) требовало сообщений.

В отношении сети / DNS вы должны настроить сервер ретрансляции / задержки, как упомянуто выше, указать на него свою старую запись MX (с сокращением TTL, как упомянуто @Paul), провести техническое обслуживание, указать запись MX туда, где она должна перейдите, измените relayhost в Postfix так, чтобы он указывал на эту запись (это может раздражать, потому что он думает, что указывает на себя, и в этом случае вам понадобится второй временный MX), и позвольте ему обрабатывать очередь.

Это было немного фрагментировано как объяснение. Для получения дополнительной информации, проверьте этот вопрос ServerFault и это с практическими рекомендациями . Это должно привести вас на правильный путь.

Опять же, если для вас приемлемо небольшое время простоя, решение @ Paul гораздо проще.