Технические рекомендации

FAQ – Технические рекомендации

Раздел на стадии разработки.

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

Как правильно настроить домен для приема и отправки E-Mail корреспонденции? (click to show/hide)

Работа с E-Mail корреспонденцией может быть разделена на два этапа:

Прием корреспонденции.
Отправка корреспонденции.

Для надежной работы каждого из этапов необходимо выполнить следующие настройки:

Настройки для приема электронной корреспонденции:

Требуется:

Почтовый сервер, на котором в списке обслуживаемых им доменов указан ваш домен.
Публикация в DNS-зоне вашего домена «MX» записи, которая ссылается на ваш почтовый сервер.

Что нужно помнить:

При создании «MX» записи указывается имя сервера, а не его IP адрес.
Создав запись типа «MX», необходимо прописать для имени сервера запись типа «A».

В файле зоны домена это выглядит так:

@ IN MX 10 mail

mail IN A 5.6.7.8

Имя сервера лучше всего выбирать « говорящее» о функционале сервера, например: MX.domain.name. Т.е. любое имя указывающее на его прямое отношении к обработке электронной корреспонденции. Наиболее часто употребляемые имена: MX, Mail, EMail, SMTP, Relay и т.п.
Каждой «MX» записи задается уровень предпочтения (приоритета). Это числовое значение в диапазоне от 1 до 255. При этом приоритет сервера тем выше чем меньше число. Часто используется стандартная градация:

10 — Очень высокий.

20 — Высокий.

30 — Нормальный.

40 — Низкий.

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

Получить список почтовых серверах домена можно командой:

# nslookup -type=mx domain.name

Настройки для отправки электронной корреспонденции:

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

Требуется:

На вашем почтовом сервере должна быть отключена неавторизованная пересылка корреспонденции (Free Relay). В противном случае, рано или поздно, на вашем сервере «поселятся» спамеры и сервер будет внесен в «черные списки» многих почтовых систем или сервисов RBL/DNSBL.
Настроить для IP-адреса почтового сервера разрешение обратного запроса DNS (Reverse Resolving). Проверка этого соответствия является базовой защитой от спама.

Настройка и проверка обратной зоны (Reverse Resolving):

Для каждого хоста должна быть настроена «PTR» запись, которая возвращает имя хоста, для этого имени должна существовать «A» запись в DNS-зоне домена, которая возвращает IP-адрес хоста. Тем самым подтверждается принадлежность хоста к домену.

Обратный резолв (Reverse Resolving):

# nslookup -type=ptr 1.2.3.4

Non-authoritative answer:

4.3.2.1.in-addr.arpa name = web-mail.domain-mail.com.

Прямой резолв (Resolve):

# nslookup -type=a web-mail.domain-mail.com.

Non-authoritative answer:

Name: web-mail.domain-mail.com.

Address: 1.2.3.4

Что нужно помнить:

Имя, возвращаемое при обратном резолве (Reverse Resolving), должно полностью совпадать с именем почтового сервера, заявленным в соответствующей «MX» записи домена и записи «A» для имени.
ОШИБОЧНО указывать в зоне обратного резолва для IP-адреса сервера несколько имен, например: MX.domain.name и GW.domain.name. В результате сервер может не всегда проходить проверку обратным резолвом. Причина этого явления кроется в технологии работы DNS-сервера, который выдает имена в виде списка, с непредсказуемой последовательностью следования имен, а проверяющая сторона зачастую берет первое имя из списка в ответе.
Кто и на каких DNS прописывает обратный резолв?

Возможны два варианта:

- Если вы пользуетесь адресами, предоставленными вам провайдером (HSP/ISP), то вопрос следует адресовать ему. Некоторые провайдеры предоставляют возможность задать имена для выданных клиенту IP-адресов через соответствующий сервис в «Личном кабинете». Если провайдер не предоставляет возможность смены PTR записи (например: BEELINE.RU), способ обхода читаем дальше.
- Если ваша организация приобрела свою AS (автономную систему) с пулом адресов, то для выполнения обратного резолва необходимо в реквизитах, передаваемых регистратору AS, указать список DNS-серверов на которых будет размещаться соответствующая [.IN-ADDR.ARPA] зона.

Как делегировать полномочия на отправку корреспонденции от имени вашего домена или что такое SPF и зачем он нужен?

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

Хост должен пройти проверку обратной зоны. Необходимо связать IP-адрес этого хоста с вашим доменом, настроив для него прямой и обратный резолв в DNS.
Даже если хост доказал свою причастность к вашему домену, он должен быть уполномочен отправлять электронную корреспонденцию. Эти права должны быть прописаны в почтовой политике домена, SPF-записи домена.

Для управления правами на отправку электронной корреспонденции от имени домена используется технология SPF (Sender Policy Framework). Более подробно о технологии SPF можно узнать на сайте http://www.openspf.org/. Большинство современных MTA поддерживают работу с SPF и предоставляют инструментарий для ее тонкой настройки. Про синтаксис SPF можно почитать на том же ресурсе по ссылке http://www.openspf.org/SPF_Record_Syntax.

SPF запись в зоне DNS имеет тип «TXT» и формат:

@ IN ТXT «v=spf1 mx -all»

или

@ IN ТXT «v=spf1 a mx -all»

или

@ IN ТXT «v=spf1 +a +mx -all»

где:

«v=spf1» — версия формата SPF-записи, для правильного распознавания записи сервером.

«mx» или «+mx» — тэг, рекомендующий принимать корреспонденцию с почтовых серверов домена. Т.е. с адресов, которые проверяющая сторона получает в два этапа: запрос списка имен почтовых серверов, и далее запрос списка IP-адресов для каждого почтового сервера.

«a» или «+a» — тэг, рекомендующий принимать корреспонденцию со всех IP-адресов, для которых имеется запись типа «A» в DNS-зоне домена.

ВНИМАНИЕ: Тэг «a» или «+a» имеет смысл, если IP-адрес сервера, с которого осуществляется отправка корреспонденции, может пройти проверку обратной зоны.

«-all» — тэг политики относительно всех остальных отправителей корреспонденции, от имени вашего домена.

Может иметь значения:

«+all» — принимать корреспонденцию (НЕ РЕКОМЕНДУЕТСЯ).

«-all» — не принимать корреспонденцию (РЕКОМЕНДУЕТСЯ).

«~all» — прием корреспонденции на усмотрение принимающей стороны.

Предоставить серверу полномочия на отправку корреспонденции от имени вашего домена, даже если он не может пройти проверку по тэгам «+a» и «+mx», можно при помощи тэга:

«ip4:<ip4-address>» — единичный доверенный IP-адрес.

или

«ip4:<ip4-network>/<prefix-length>» — доверенная сеть.

Так для домена с доверенным единичным адресом [1.2.3.4] и доверенной сетью [3.4.5.0/24], SPF запись будет иметь вид:

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 a mx -all»

или

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 +a +mx -all»

ВНИМАНИЕ:

- - Последовательность указания тэгов, не имеет значения.
  - Все тэги должны быть разделены пробелом.
  - Не допускается писать сеть в виде [3.4.5.*] и т.п. вариации. Т.е. в формате тэга «ip4:» не допускаются иные символы кроме [0-9/.].
  - Не рекомендуется писать сеть в формате [3.4.5.1/24]. При указании сети необходимо указывать <сетевой адрес>/<маска>, а не <любой адрес сети>/<маска>. Если имеете затруднения в расчете масок сетевых адресов, то можете воспользоваться IP-калькулятором, например: http://jodies.de/ipcalc.
  - Не допускается указывать в списке доверенных хостов и сетей неподконтрольные вам системы. Так же не нужно писать диапазоны вида: «ip4:128.0.0.0/1» или все сети вашего провайдера с «запасиком» и т.п. «упрощения» . Помните, что сети по маске [/16] и меньше, редко когда задают даже крупные почтовые хостинги и порталы.
  - Не рекомендуется интернет-провайдерам указывать, в списке доверенных сетей, сети, выделенные клиентам для статического и тем более динамического распределения. Эти диапазоны с большой вероятностью попадают в блокируемые диапазоны, что может привести к блокировке всего домена.

Использование других SPF тэгов и их расширений, например: [a/<prefix-length>], [a:<domain>], [a:<domain>/<prefix-length>], [ptr], [exists] и [exp] оставляем на усмотрение администраторов. Тэги [include] и [redirect] следует использовать с осторожностью, особенно, если вы включаете как доверенные, SPF-записи чужих доменов.

ВНИМАНИЕ: При использовании тегов «a» и «ptr» необходимо продублировать адреса хостов и сетей в тэгах «ip4:».

Окончательные настройки DNS зоны домена в части почтовой системы должны иметь вид:

@ IN MX 10 mail

mail IN A 5.6.7.8

@ IN ТXT «v=spf1 mx -all»

или если необходимо указать доверенные адреса и сети:

@ IN MX 10 mail

mail IN A 5.6.7.8

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 mx -all»

Частный случай, когда изменение PTR-записи невозможно:

- Если IP-адрес не проходит проверку обратным резолвом:

# nslookup 33.44.55.66
Non-authoritative answer:
66.55.44.33.in-addr.arpa name = id-host-1234567.hsp-domain.problem.

# nslookup id-host-1234567.hsp-domain.problem
** server can't find id-host-1234567.hsp-domain.problem: NXDOMAIN

Действия:

- - Настраиваем DNS-зону домена стандартным образом.

@ IN MX 10 mail

mail IN A 33.44.55.66

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 mx -all»

- - ВАЖНО: Запрашиваем обновление информации по домену через Сервис.
  - Надеемся, что вашему серверу не откажут в приеме корреспонденции, по причине непрохождения проверки обратным резолвом.

Рекомендация: не использовать площадки таких провайдеров для размещения почтовых сервисов.

- Если IP-адрес проходит проверку обратным резолвом:

# nslookup 33.44.55.66
Non-authoritative answer:
66.55.44.33.in-addr.arpa name = id-host-1234567.hsp-domain.problem.

# nslookup id-host-1234567.hsp-domain.problem
Non-authoritative answer:
Name: id-host-1234567.hsp-domain.problem
Address: 33.44.55.66

Действия:

- - Настраиваем DNS-зону домена с указанием реального имени хоста в альтернативной MX-записи:

@ IN MX 10 mail

@ IN MX 90 id-host-1234567.hsp-domain.problem

mail IN A 33.44.55.66

@ IN ТXT «v=spf1 ip4:1.2.3.4 ip4:3.4.5.0/24 mx -all»

- - ВАЖНО: Запрашиваем обновление информации по домену через Сервис.

На этом настройку домена для приема/отправки электронной корреспонденции можно считать завершенной.

Для примера можно посмотреть, как академически грамотно, с точки зрения почтовых систем, настроены следующие домены:YANDEX.RU, GMAIL.COM .

Как организовать работу почтовой системы хостинговой компании. Как обеспечить отправку e-mail сообщения с WEB-сайта или иного сервиса на хостинге. (click to show/hide)

Что такое хостинговая компания (хостинг, хостинг-оператор, HSP (Hosting Service Provider))?

Хостинговая компания — компания, занимающаяся предоставлением услуг по размещению оборудования, хранению и обработке данных, размещению и выполнению прикладного ПО (WEB-сайты и т.п.) заказчика на своей технической площадке.

Самый распространенный перечень услуг хостинговой компании:

Регистрация доменов.
Предоставление услуг Primary/Secondary DNS — размещения DNS-зоны домена.
Почтовый хостинг — прием, пересылка, хранение, предоставление авторизованного доступа к хранимой электронной корреспонденции заказчика.
WEB-хостинг — размещения сайтов.
VDS/VPS хостинг — создание и использование виртуальных серверов.
Предоставление в аренду своего оборудования, чаще всего физических серверов.
Колокация (Colocation) — физическое размещение оборудования заказчика на площадке хостинга и его подключение к средствам коммуникаций.
Предоставление технических средств и условий для создания облачных решений (Cloud-hosting).

ВНИМАНИЕ: несмотря на достаточно большой перечень услуг, все они носят технический характер. В обязанности хостинговой компании не входит обеспечение грамотной настройки и сопровождение инфраструктуры заказчика услуг. За исключением случаев, когда эта услуга предоставляется отдельно на платной основе и приобретена заказчиком.

Из перечня видно, что к электронной почте имеет прямое отношение только одна услуга — Почтовый хостинг.

Оптимальным решением для Почтового хостинга можно считать «Универсальную архитектуру почтовой системы», смотрим Архитектура.

Почтовый хостинг.

Формально почтовый хостинг можно разделить на две группы:

Простой — хостинг обслуживающий один или несколько доменов, принадлежащих хостинговой компании. К этой группе можно отнести большинство бесплатных почтовых систем.
Мульти-доменный — хостинг обрабатывает электронную почту не только своего домена(ов), но так же почту доменов заказчиков.

Неважно, к какой группе относится Почтовый хостинг, он должен обеспечивать: прием, отправку/пересылку и хранение корреспонденции заказчика, а так же предоставлять к ней авторизованный доступ.

Хранение корреспонденции и авторизованный доступ к ней, это целиком зона ответственности хостинговой компании.

Надежность приема и доставки электронной корреспонденции зависит от правильности настройки: DNS-зоны домена хостинговой компании, DNS-зоны домена заказчика, а так же от настроек DNS-зон почтовых систем с которыми происходит взаимодействие.

Что должно быть заявлено в DNS-зоне любого домена в части электронной почты:

MX-сервера для приема входящей корреспонденции домена и отправки исходящей корреспонденции домена.
Если используются SMTP/Relay сервера для пересылки исходящей корреспонденции непосредственно на MX-сервер домена получателя, минуя MX-сервер домена отправителя, то их IP-адреса или доменные имена должны быть указаны в SPF-записи почтовой политики домена.
Если используется WEB-Mail фронт, предоставляющий пользователям доступ к их корреспонденции, а так же отправку e-mail при помощи WEB-интерфейса непосредственно на MX сервер домена получателя, минуя MX-сервер домена отправителя, то IP-адреса или доменные имена этого фронта должны быть указаны в SPF-записи почтовой политики домена.

ВАЖНО: Хостинговая компания, предоставляя услугу мультидоменного почтового хостинга, должна максимально ответственно подойти к настройке SPF-записи почтовой политики домена, при настройке DNS-зоны. Крайне необходимо указать не только MX-сервера для входящей почты, но и список IP-адресов/сетей [ip4:2.3.4.5] и/или доменных имен [a:web123.hsp-mail.name] всех доверенных relay-серверов, с которых может отправляться электронная корреспонденция заказчика. Почему?

При настройке своего домена, заказчик указывает в качестве MX-серверов своего домена MX-сервера хостинга.
При настройке SPF-записи почтовой политики своего домена, заказчик, помимо своих доверенных хостов, должен задать делегирование домену хостинга полномочий на отправку электронной корреспонденции от имени его домена. Это действие выполняется полем [include:] в SPF-записи. И обычно имеет вид:

@ IN TXT «v=spf1 ip4:3.4.5.6 include:HSP-Mail.name mx -all»

Если Хостинг ограничится упрощенной записью SPF, вида:

@ IN TXT «v=spf1 a mx ~all»

При наследовании такой политики, гарантированы сбои анализа и суммировании политик. По причине неопределенности, неочевидно, что подразумевается под полем «a» - домен хостинга или домен заказчика. Так же очень часто указывается не стартовая SPF-запись, а поле вида [include:spf.hsp-mail.name].

ВНИМАНИЕ: все хосты, указанные как MX-сервера или доверенные отправители в SPF-записи домена, должны проходить проверку обратной зоны (Reverse Resolving).

ВНИМАНИЕ: указывать в SPF-записях доменов хостинга диапазоны адресов предназначенные для виртуального вебхостинга или других сервисов предоставляемых заказчикам услуг — нельзя.

Причины такого подхода очевидны:

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

Следовательно, нет возможности поручится за благонадежность этих ресурсов. Чаще всего, эти ресурсы связаны с другими доменами или вовсе не связаны с каким либо доменом, например, тестовые ресурсы.

Как отправлять электронную корреспонденцию с вебсайта, VDS/VPS и ресурсов на площадке хостинговой компании?

В такой ситуации можно рекомендовать:

Авторизованную отправку электронной корреспонденции через SMTP/Relay сервер любого домена, в котором, у заказчика ресурса есть учетная запись.
Если ресурс (вебсервер, VDS/VPS и т.п.) полностью под контролем заказчика, то его можно прописать в DNS-зоне домена заказчика ресурса в полях MX/SPF как уполномоченный получатель/отправитель.
IP-адрес ресурса отправителя (WEB/VDS/VPS) можно прописать в локальный whitelist сервера SMTP/Relay администрируемого заказчиком ресурса. Будьте осторожны, если речь идет о вебсайте на виртуальном хостинге, на одном IP-адресе может размещаться множество сайтов.

Напоминаем, SMTP/Relay сервер не занимается получением входящей почты домена, проверку подключений на RBL/DNSBL сервисах не выполняет, и должен предоставлять Relay услугу только авторизованным клиентам.

Как начать использовать RBL? (click to show/hide)

Что бы начать использование сервиса RBL.RBLDNS.RU достаточно прописать его в соответствующих настройках вашего почтового сервера.

ВНИМАНИЕ:

Что бы избежать потери важной корреспонденции, необходимо:

На начальном этапе использования RBL, избегать использования политики REJECT (отказ от приема) корреспонденции от неблагонадежных хостов. Рекомендуется использовать маркировку сомнительной корреспонденции или ее пересылку в специальный почтовый ящик. Обращаем ваше внимание, что "разбор вручную" не является трудоемкой задачей, т.к. при получении сотен типовых сообщений, они легко группируются по теме и другим признакам. Внимание уделяется только письмам, которые выпадают из общей массы.

SPAM-GROUP-2

На последнем этапе, когда в течение продолжительного времени (2-3 месяца) проблем в пересылке корреспонденции выявлено не будет, можно перейти к отказу от приема корреспонденции с хостов из нашего RBL.

При ошибочной блокировке хоста, необходимо запросить автоматизированную систему управления RBL об обновлении информации о блокированном домене в разделе Сервис. Если домен настроен в соответствии с нашими рекомендациями, то он будет исключен из списка блокировки в течении 1-3 часов.

Как посмотреть настройки почтовой системы домена? (click to show/hide)

При поиске и устранении проблем в доставке электронной корреспонденции необходимо уметь определять настройки почтовой системы в DNS, как своей, так и чужой.

Получение списка почтовых серверов домена:

# nslookup -type=mx domain.name

Получение SPF записи(ей) для домена:

# nslookup -type=txt domain.name

Выбираются строки данных начинающиеся с префикса: [v=spf1].

Для полей полученных в тегах [include] и [redirect]запрос повторяется индивидуально:

# nslookup -type=txt spf.domain-include.name