Как правильно поменять IP-адрес почтового сервера

В первые дни нового года одна известная организация, обменивающаяся почтой с финансовыми учреждениями, показала увлекательный спектакль. Завязка была такой: по какой-то причине им нужно было поменять IP-адрес почтового сервера или сам сервер. Ну, мало ли что, бывает.

Что они сделали? Они изменили MX-запись, прописав туда новый адрес, и немедленно стали отправлять с него почту. Как на это реагировали почтовые серверы контрагентов?  Очень просто, в большинстве случаев (кроме тех, когда людей устраивает спам) посылали его куда-то подальше.

В какой-то момент известная организация, судя по всему, подумала: «Ой, а что это мы делаем? DNS-ы же еще не разошлись, почта не уходит». И что они сделали дальше? Совершенно верно, попробовали отправлять со старого адреса. И тут, конечно, стало еще забавнее, потому что DNS-ы как раз разошлись и теперь уже почта не принималась со старого адреса.

Какую отсюда можно извлечь мораль? Все очевидно: решив поменять адрес почтового обменника, добавьте еще одну MX-запись (приоритет выбирайте сами) и подождите два-три дня, чтобы она разошлась по интернету. Лишняя запись, вообще говоря, никому еще не мешала. А после этого делайте все, что хотите: убивайте старую, оставляйте ее, используйте обе — работать будет.

Как правильно поменять IP-адрес почтового сервера: 7 комментариев

  1. Андрей Иванов

    Хотел просто сказать спасибо за статью.

  2. Илья Пантелеев

    Прикольно.

    Только если уважаемый автор объяснит мне кое-что: где в RFC он нашел что почта должна отсылаться с MX-записи домена?! Лично изучив многие RFC по SMTP я нашел только рекомендации по борьбе со спамом в которых сказано, что почта должна отправлятся с IP адреса, который обратно разрешается в dns-запись из этого домена. Нигде не сказано, что почта должна отправляться с MX-записей. Так что те домены которые не принимают эту почту — просто нарушают RFC. Интересно как обмениваться почтой с доменами, которые не следуют стандартам?! В принципе вполне есть простое описание такому подходу, представьте себе что у меня большой почтовый домен на 10к адресатов и два широких канала связи. Еще условие — поток писем в мой домен больше чем исходящий. Скажем я хочу обеспечить балансировку нагрузки — один канал — используется для серфинга пользователей в Интернет(входящий траффик намного больше исходящего) + отправка почты на внешние адреса, а второй — под ВПН-каналы с представительствами для отправки изменений в общей БД компании(исходящий больше входящего). Куда мне удобней принимать письма? Ясно дело на второй канал, а отправлять удобнее с первого. Так что все это полная чушь... Единственно что угнетает, это то что администраторам таких больших систем приходится тратить массу времени, обзванивая других администраторов и доказывать им что они не знают RFC и должны принять их почту. (источник rfc2505. Строка: In the memo we sometimes use the term «host name» or «domain name» which should be interpreted as a Fully Qualified Domain Name, FQDN. By this we mean the name returned from the DNS in response to a PTR query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a name, or we mean a name with a DNS A or MX record associated to it.)

  3. Дмитрий Огарков Автор записи

    Спасибо за комментарий, и вы совершенно правы, что в RFC нет такого требования, о котором вы говорите. Здесь имеет место молчаливое соглашение (или корпоративная солидарность администраторов — называйте как хотите), вызванное понятными причинами — древностью протокола SMTP и необходимостью защиты от спама (едва ли много лет назад можно было предположить, что проблема станет такой острой). Кстати, корпоративная почта, за которую я сейчас отвечаю, много лет работала так, что HELO сервера не совпадало с MX, и один раз мне даже довелось объяснять людям примерно то же самое, что написали вы. Но когда мы модернизировали систему, в том числе включили в нее обменник на Postfix'е, почту стали отправлять строго с наших MX-записей, и время на лишние разговоры больше не стало тратиться. И да, я сам тоже проверяю MX при приеме почты — несогласных с этим стало совсем мало.

  4. Илья Пантелеев

    Я бы назвал это не солидарностью администраторов, я бы назвал это нарушением стандартов. Давно уже придумана системы защиты от спама подобного рода — SPF. Препятствием на пути её развития как раз и стоят так называемые «корпоративно солидарные администраторы». У них нет систем с поддержкой SPF и поэтому они считают, что имеют полное право фильтровать на основе MX-записей. Касательно всего остального — меня пугает что Вы так легко отказываетесь от стандартов. «Корпоративная солидарность» — есть не что иное как попустительство невежества. Во всей этой истории меня расстраивает только то, что в основном так поступают администраторы Lunix-based почтовых систем. Люди, которых я всегда ценил за четкое требование стандартам и нормам для обеспечения совместимости... А технологий защиты от спама великое множество(я промолчу про GreyListing и прочее) и фильтруя сообщения таким образом Вы в первую очередь создаете трудности своим коллегам.

  5. Дмитрий Огарков Автор записи

    Илья, вы правы. Если бы все использовали SPF, если бы на это можно было положиться абсолютно, то и разговаривать было бы не о чем. Я использую SPF, и Петя использует, а вот Вася, допустим, нет — вот и думаем дальше.

    Я сошлюсь, впрочем, на практику: я жестко фильтрую корпоративную почту, в том числе проверяю всякие HELO и MX уже пару лет, кажется. Через Postfix проходит в среднем 1% писем, дальше стоит более тонкий фильтр. Разумеется, если бы нужная почта не приходила, мне уже настучали бы по голове. Но за все время таких случаев было, может быть, два или три. Тогда сервер заносится в белый список, и все. По моим критериям это лучше, чем жалобы пользователей на спам. Грейлистинг же для нас неприемлем просто потому, что почта нужна быстро.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *