Как работает электронная почта. База

Исходим из того, что все умные, но многие не знают, как ходит почта и вопросы эти на 99% исходят из базы.

База:

• Для работы почты почтовый сервер должен быть доступен из Internet

• Почта приходит, потому что указаны MX-записи

• Почта уходит, потому что настроена в соответствии с безопасностью SPF, DKIM, DMARC

Разберёмся по порядку, что должно быть настроено, чтобы работала почта.

Определяемся со схемами функционирования почтовой системы

Базовая схема предполагает, что почта проходит через фаервол/роутер, на нём соответственно входящий NAT на TCP 25й порт почтового сервера и разрешающие правила

Более продвинутый вариант предполагает использование нескольких ISP провайдеров, промежуточные Email Security Gateway и набор почтовых серверов за ними

В данном реализации почта будет приходить по нескольким провайдерам одновременно и в случае сбоя у одного, переключаться на второго.

Ну и современная база: почтовый сервис где-то в облаке и «Я всё делаю, как рекомендует Яндекс, Гугл, Мру!» Сюда же можно добавить Email Security GW, как сервис.

Схемы просты и понятны, но сами по себе схемы не объясняют, почему приходит почта.

Настройка DNS

Переходим к следующему шагу: DNS записи

Для того чтобы письмо пришло требуется каким-то образом сообщить, что ваш домен обслуживает данный конкретный сервер. Для этого нужен DNS, а именно: MX записи. Только MX записи отвечают за указание адреса почтового сервера.

example.com.        IN    MX    10 mail.example.com. mail.example.com.   IN    A     9.9.9.9

Указанная выше MX запись по факту сообщает, что для домена example.com почтовым сервером является сервер mail.example.com, а живёт он на IP адресе 9.9.9.9 (об этом нам говорит уже A-запись). Таким образом вся входящая почта для домена example.com будет отправляться на tcp://9.9.9.9:25

Самая объёмная часть. Исходящая почта.

Для того чтобы ваше письмо дошло необходимо пройти довольно большое количество проверок, в базе: PTR, SPF, DKIM, DMARC

По порядку: PTR запись — имя, которое возвращает IP адрес. Сейчас используется всё реже, но в РФ идут своим путём и зачастую требуется.

Проверяем так:  nslookup -type=PTR 9.9.9.9 8.8.8.8, соответственно должно быть mail.example.com. Задаётся у вашего провайдера, у облачников часто нет самостоятельной возможности указать PTR, пишем в саппорт.

Следующая по порядку, но одна из основных по значимости: SPF запись. По факту это текстовая запись в DNS зоне вашего домена, которая сообщает о том, кому можно слать почту от имени вашего домена. И вот здесь случается миллион ошибок.

Вероятно от незнания, но база:

• В рамках одного домена SPF запись может быть только одна. Если их две, то все проверки SPF пойдут на мороз.

• SPF запись не должна быть слишком большой (не более 10 серверов)

• Можно всех обмануть и разрешить отправлять со всех MX и A записей в вашем домене

Часто встречаются такие вот ошибки:

Первое — записи две, второе — они себе противоречат. Вероятнее всего, компания купила домен на timeweb.ru, где в дефолте уже указаны SPF самого timeweb, а затем администратор (вероятно от непонимания) добавил вторую запись с редиректом на mail.ru.

Нет смысла выяснять, что и где работает, но правильная запись, вероятно, должна выглядеть так: v=spf1 include:_spf.timeweb.ru include:_spf.mail.ru ~all

Давайте по-простому опишем, что и как должно выглядеть в SPF записи: v=spf1 a mx include:_spf.mail.ru ip4:9.9.9.9 ~all

• a — все А-записи в вашем домене

• mx — все MX-записи в вашем домене

• include:_spf.mail.ru — все SPF записи mail.ru

• ip4:9.9.9.9 — непосредственно IP адрес

• ~all — не парьтесь, поскольку у вас есть сторонние сервисы, хватит и ~

Одной из самых верных проверок, является проверка DKIM. По своей сути, это подписание писем электронной подписью на уровне сервера. Открытый ключ указываем в своём DNS — по нему проходит проверка, закрытый — на почтовом сервере, им подписываются письма.

Данный механизм прост до безобразия, но нужно помнить, что длина ключа должна быть 2048 бит, а закрытый ключ хранить как зеницу ока.

Есть как онлайн генераторы (не доверяем), встроенные в почтовый сервис, а можно сделать и ручками.

Ну и напоследок: DMARC — политика, определяющая, что делать с письмами от вашего домена в случае, если они не прошли проверки. Такая же текстовая запись в DNS зоне вашего домена. По факты мы сообщаем почтовому серверу получателя.

Вот пример: v=DMARC1; p=none; rua=mailto:reports@example.com; ruf=mailto:forensic@example.com; fo=1

p=none (может быть reject, quarantine) — ничего не делать с письмами, но администратор будет получать отчёты. Рекомендуется использовать только при тестировании/настройке

rua — адрес для агрегированных отчётов

ruf — для детальных

fo=1 (отчёт создаётся если не пройдет проверка или DKIM или SPF). 0 — обе проверки, s — не пройдена проверка SPF, d — DKIM

С базой закончили. В дальнейшем планирую рассказать, как работают всякие вкусные: Dynamic Reputation Lists, Sandbox, White/Black/Gray Lists, Email throttling, URL Defense и т.д. А если меня хватит, то рассмотрим настройку различных почтовых шлюзов/серверов.