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

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

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

 

Работа с 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 .

.

Что такое хостинговая компания (хостинг, хостинг-оператор, 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.RBLDNS.RU достаточно прописать его в соответствующих настройках вашего почтового сервера.

ВНИМАНИЕ:

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

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

 SPAM-GROUP-2

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

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

.

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

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

# nslookup -type=mx domain.name

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

# nslookup -type=txt domain.name

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

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

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

.

.

Go to top