Для меня загадка почему развертывание даже примитивной конфигурации почтового сервера для многих системных администраторов является столь серьезной проблемой. Тем не менее, это так. Мне бы никогда не пришло в голову писать об этом целую статью, но судя по неиссякаемому количеству вопросов, это сделать все же необходимо. Больше всего сложностей вызывают базовые DNS-записи для почтового сервера, о них и поговорим.
Хочется задать вопросы или поделиться знаниями? Приходи в наш закрытый Telegram-чат.
Содержание
Базовые DNS-записи для почтового сервера
В статье рассмотрены базовые записи, которые либо необходимы, либо крайне желательны для нормального функционирования почтового сервера.
Рекомендую к прочтению перечень статей ниже:
Ну а теперь начнем разбираться что нужно сделать перед созданием записей.
Покупка доменного имени
Начать необходимо с покупки доменного имени. Это не так сложно, как кажется и не так дорого. Новый домен в .ru-зоне может стоить не больше 100-200 рублей.
Как только домен куплен, можно приступать к созданию записей. У всех регистраторов разные админки, но зная теорию, в специфике добавления записей разобраться проще простого.
Хочу сразу предупредить, что распространение только что созданных записей занимает некоторое время, обычно это от 15 минут и до нескольких часов (или в теории даже суток, но мне такое не встречалось).
A
Первым делом создайте основную A-запись, которая будет указывать на внешний адрес вашего почтового сервера. Допустимы любые варианты, но обычно выбирают что-то похожее на mail.domain.tld или mx1.domain.tld. Если вы используете собственный DNS-сервер bind, то A-запись внутри зоны может выглядеть так:
|
1 |
mail IN A 1.2.3.4 |
На эту запись в последствии будет указывать MX.
MX
Эта запись переводится как mail-exchanger и, собственно, она и является основной для почтовых серверов. Таких записей может быть несколько и каждая из них обязательно имеет значение приоритета – чем оно меньше, тем приоритет выше. Для чего это используется? Главным образом для определения очередности обращения к MX-записям, если их несколько.
Часто встречается, что несколько MX-записей для одного и того же домена имеют одинаковый приоритет. В этом случае входящий трафик будет равномерно балансироваться между серверами.
Если углубляться в архитектуру почтовых решений, то очень часто запись MX указывает на mail-relay или сервер антиспама (spamassasin, например, или Exchange Server Edge), а не на конечный почтовый сервер, сохраняющий входящие/исходящие письма. Это вполне разумный подход, когда отдельный сервер выступает в качестве пограничного шлюза, а другой – с критически важными данными для бизнеса – своеобразным бэкэндом. Я скажу больше – это даже best practice.
Сколько MX надо для счастья
Сообразительному читателю может прийти в голову очень интересная мысль: “А что лучше – две записи MX или одна запись MX, но ссылающаяся на две одинаковые A-записи?”. Визуально это выглядит вот так:
В случае b. получается своеобразный Round Robin. Но, если отбросить нюансы, вариант a. аналогичен! Ведь одинаковый приоритет MX-записей обеспечивает такую же функцию.
Тем не менее, и в этом случае у многих возникают сомнения. Главным образом они обуславливаются мнением, что в случае b., если отправляющий сервер в первой попытке отправки попадет на неработающий сервер, то он отложит отправку и попробует в следующий раз, спустя таймаут. Но это в корне неверно – он попробует отправить на второй сервер из выдачи RR сразу же. Это демонстрирует наглядный эксперимент.
Когда на запросы отвечают оба сервера из варианта b., мы видим следующую запись в smtp-сессии при попытке отправки на них письма (Queued mail for delivery – письмо принято к доставке):
|
1 |
Feb 14 13:57:37 mail postfix/smtp[62657]: ACF0D140073: to=<vasilev@domain.tld>, relay=mail.domain.tld[1.1.1.2]:25, delay=1.7, delays=0.17/0/0.09/1.5, dsn=2.6.0, status=sent (250 2.6.0 <bd5bbc4f-95d7-4261-a991-cc4756bfa9a7@getmailbird.com> [InternalId=133384504345527, Hostname=EXCH01.sc.local] Queued mail for delivery |
Если же по каким-то причинам один из серверов отключился и отправляющая сторона попала в первую попытку на него, сразу же пойдет вторая попытка отправить почту на второй сервер из выдачи (после Connection timed out в первый раз идет удачная вторая попытка):
|
1 2 3 |
Feb 14 14:02:16 mail postfix/smtp[62676]: connect to mail.domain.tld[1.1.1.2]:25: Connection timed out Feb 14 14:02:17 mail postfix/smtp[62676]: 35E8F140073: to=<vasilev@domain.tld>, relay=mail.domain.tld[1.1.1.1]:25, delay=31, delays=0.15/0/30/0.7, dsn=2.6.0, status=sent (250 2.6.0 <dc5f628f-eac0-44d0-954f-395004205ed5@getmailbird.com> [InternalId=139818365354012, Hostname=EXCH02.sc.local] Queued mail for delivery |
А теперь вернемся от теории к практике и посмотрим как же обстоят дела у крупных публичных почтовых сервисов:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# dig -t MX mail.ru +short 10 mxs.mail.ru. # dig -t A mxs.mail.ru +short 94.100.180.104 94.100.180.31 # # # dig -t MX yandex.ru +short 10 mx.yandex.ru. # dig -t A mx.yandex.ru +short 213.180.204.89 77.88.21.89 213.180.193.89 87.250.250.89 93.158.134.89 |
Mail и Yandex используют для своих сервисов именно вариант с RR для A-записей, а вот Google – нет:
|
1 2 3 4 5 6 |
# dig -t MX gmail.com +short 5 gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. |
Поэтому именно вам решать какой вариант выбрать.
PTR
С PTR нет такого пространства для творчества, как в случае с MX и от этого только легче. PTR-запись принадлежит обратной зоне и призвана сопоставить ip-адрес с DNS-именем (то есть, адрес должен разрешаться в имя).
В самом идеальном случае должно происходить “круговое” разрешение записей. Что это такое, легко понять на примере: из MX получаем A-запись, из A-записи получаем ip-адрес, от этого адреса берем PTR-запись, которая в идеале должна разрешиться в A-запись, на которую указывала MX изначально. И так по кругу:
Но в реальности это явно избыточный перфекционизм. К тому же, что вы будете делать, если ваш сервер будет обслуживать несколько доменов одновременно (а ведь это очень частая ситуация)?
Ради интереса давайте проверим тех же публичных провайдеров:
|
1 2 3 4 5 6 7 |
# dig -t MX mail.ru +short 10 mxs.mail.ru. # dig -t A mxs.mail.ru +short 94.100.180.104 94.100.180.31 # dig -x 94.100.180.104 +short mxs.mail.ru. |
Но! ведь этот же сервер обслуживает и другие домены mail.ru, например list.ru, bk.ru:
|
1 2 |
# dig -t MX bk.ru +short 10 mxs.mail.ru. |
Ну и, разумеется, их адреса будут иметь PTR абсолютно не связанную с именем, например, bk.ru. Таким образом, по сути жесткое соответствие не обязательно и вы можете использовать PTR с любым вашим доменным именем. Главное, чтобы запись существовала, ведь очень много серверов проверяют наличие PTR и, если её нет, резко повышают спам-рейтинг ваших сообщений.
И, самое главное, PTR-запись создается на стороне владельца ip-адреса. То есть, если адреса вам предоставляет интернет-провайдер, запрашивать создание записи вы должны именно у него (в админке или через менеджера).
TXT
TXT – обычная текстовая запись. Она применяется достаточно широко – от подтверждения владения доменом и до использования самыми разными механизмами фильтрации нежелательных/вредоносных сообщений (DKIM, DMARC).
В контексте изучения базовых записей DNS, TXT нас интересует прежде всего с точки зрения использования SPF (Sender Policy Framework).
Назначение SPF очень простое – определить список серверов, которые имеют право отправлять почту от указанных доменов. Не вникая в особенности самого расширения, вы можете легко сгенерировать подходящую SPF для вашего домена, в этом вам помогут многочисленные онлайн-генераторы 2.
Ваша запись может иметь следующий вид:
|
1 |
bq-srv.ru. IN TXT "v=spf1 ip4:1.2.3.4 ~all" |
Ничего сложного. Не так ли? На стороне почтового сервера ничего делать не нужно, в этом ещё один плюс SPF.
Никогда не игнорируйте возможность создания записи, даже если имеете дело с тестовой инфраструктурой. Например вот что может вам ответить принимающий сервер, если засомневается в вашей “чистоте” как отправителя:
|
1 |
Jul 16 14:42:34 mail postfix/smtp[14695]: 00A377F4F2: to=<e.s.vasilyev@mail.ru>, relay=mxs.mail.ru[94.100.180.31]:25, delay=3.3, delays=0.01/0/0.57/2.7, dsn=4.0.0, status=deferred (host mxs.mail.ru[94.100.180.31] said: 451 Try again later. Error code: 418106970B47EED089DB5EEB95505C509875822F02009150C1E1D56D6E102E7A. (in reply to end of DATA command)) |
Это кусок лога SMTP-сессии с сервером Mail.ru. Абсолютно неинформативная ошибка и ответ – 451 Try again later – могут легко ввести в ступор, а безрезультатная гуглежка заставит сильно приуныть. Тем не менее, после создания SPF все стало хорошо и статус вновь отправляемых сообщений изменился на Queued mail for delivery.
В качестве напутствия
На этом, кажется, у меня все. На своем опыте хочу порекомендовать вам всегда проверять блэклисты на предмет наличия в них ваших доменов и ip-адресов, особенно тех, которые вы арендуете где-то на стороне (например аренда выделенных серверов). Кто знает, может быть этот адрес висел на сервере, который занимался рассылкой спама. Тут вам никакие SPF и PTR не помогу.
Также никогда не бойтесь писать вашим коллегам-админам почтовых серверов из других компаний, на адреса которых почему-то не доходят ваши сообщения. И наоборот – всячески помогайте обратившимся к вам админам со стороны. Совместный траблшутинг проблемы сделает опытнее вас обоих.
