Марк АвриловОпубликовано обновлено 7 мин чтения
Анатомия почтовика:
что внутри корпоративной почты
«Почта не работает», и сисадмин уже знает, что впереди долгий вечер. За каждым письмом стоит цепочка программ, и сломаться может любое звено.
Ниже карта этой цепочки: что крутится на сервере, когда вы жмёте «Отправить», и где искать поломку по симптому.
Что такое почтовый сервер
Почтовый сервер (mail server) это программа или набор программ, которые принимают, хранят, пересылают и отдают электронную почту. Письмо с ivan@firma.ru на olga@partner.com проходит минимум через два таких сервера, один у отправителя и один у получателя.
Монолитом почтовый сервер почти никогда не бывает. Одна программа передаёт письма между серверами, другая раскладывает их по ящикам, третья отдаёт их почтовому клиенту, и у каждой свой протокол. Классическое деление на MTA, MDA и MUA пригодится, когда будете читать логи или разбирать ошибку доставки.
MUA: почтовый клиент
Outlook, Thunderbird, Apple Mail, Gmail в браузере или на телефоне. В MUA вы набираете текст и жмёте «Отправить». Частью сервера клиент формально не считается, хотя люди работают с почтой именно через него.
В организации клиент стоит стандартизировать: поддерживать одно приложение проще, чем зоопарк из пяти. Outlook удобен в экосистеме Microsoft, Thunderbird бесплатный и гибкий.
SMTP · порт 587 или 465
Клиент сдаёт письмо серверу с логином и паролем. На 587 шифрование включается командой STARTTLS, на 465 соединение шифруется сразу.
MTA: Mail Transfer Agent
Postfix · Exim · Sendmail · Microsoft Exchange
Ядро почтового сервера и его курьер. MTA принимает письмо от клиента или от другого MTA, по MX-записям домена получателя находит, куда его нести, и передаёт дальше. Между собой серверы тоже говорят по SMTP, но на порту 25.
Если доставить письмо сразу не вышло, оно ждёт в очереди MTA, и сервер повторяет попытки. Не справляется MTA с потоком, очередь растёт, и письма приходят с опозданием.
Криво настроенный MTA первым попадает под подозрение, когда письма тормозят или не уходят вовсе.
DNS-записи
- MX называет сервер, который принимает почту домена. Если MX нет, отправитель по RFC 5321 попробует A-запись самого домена; чтобы отказаться от почты совсем, публикуют null MX.
- A связывает имя сервера из MX с IP-адресом.
- PTR работает наоборот, от IP к имени. У отправляющего сервера её требуют Gmail и Yahoo, подробнее в статье об обратном DNS.
- SPF перечисляет серверы, которым можно слать от имени домена.
- DKIM публикует ключ для проверки подписи: сервер подписывает письмо, получатель сверяет, что подписанные части не меняли.
- DMARC говорит, что делать с письмами, которые не прошли SPF и DKIM, и куда слать отчёты о тех, кто пишет от вашего имени.
MX и A отвечают за то, чтобы почта доходила. SPF, DKIM и DMARC защищают домен от подделки.
TLS-шифрование
Без TLS письмо идёт по сети открытым текстом, как открытка, и прочитать его можно на любом участке между серверами. TLS шифрует каждый такой участок.
Google требует TLS от всех, кто шлёт на Gmail. А получатель в Gmail увидит у незашифрованного письма красный открытый замок.
Антиспам-фильтры
SpamAssassin · Rspamd · встроенные фильтры Google/Microsoft
Фильтр взвешивает десятки признаков: репутацию отправителя, результаты SPF, DKIM и DMARC, ссылки, вложения, текст. Хороший ловит и спам, и фишинг, а фишинг для корпоративного ящика опаснее.
Перегнуть легко. Письмо клиента в папке «Спам» может стоить сделки, поэтому порог подбирают, а не выкручивают на максимум. В крупных компаниях фильтрацию часто выносят на отдельный шлюз перед основным сервером.
MDA: Mail Delivery Agent
Dovecot · Cyrus · Procmail
Письмо добралось до сервера получателя, и MTA отдаёт его MDA. Тот кладёт сообщение в конкретный ящик, в формате Maildir, mbox или в базу. По дороге срабатывают правила: раскладка по папкам, пользовательские фильтры на языке Sieve, проверка квоты.
Ящик переполнен, и письмо вернётся отправителю с ошибкой. Следите за квотами, иначе коллеги будут молча терять входящие.
📨
IMAP
Письма живут на сервере, клиенты синхронизируются. Ноутбук, телефон, планшет видят одни и те же «Входящие».Стандарт для бизнеса.
📥
POP3
Скачивает письма на устройство и обычно удаляет их с сервера. Олдскул, но живёт там, где устройство одно, а места на сервере мало.
🌐
Webmail
Roundcube, SOGo или веб-версии Gmail и Outlook. Открыл браузер и работаешь. Хорош как запасной вход.
Путь письма от отправителя до получателя
Иван из firma.ru пишет Ольге из partner.com. По шагам это выглядит так.
- Thunderbird Ивана подключается к smtp.firma.ru по порту 587, проходит авторизацию и сдаёт письмо.
- MTA firma.ru спрашивает у DNS MX-запись partner.com и получает mx.partner.com.
- MTA firma.ru открывает SMTP-соединение с mx.partner.com на порту 25 и передаёт письмо.
- MTA partner.com проверяет SPF, DKIM и DMARC, прогоняет письмо через антиспам и отдаёт его MDA.
- MDA кладёт письмо в ящик Ольги.
- Outlook Ольги забирает его с сервера по IMAP.
Проверить, что первые шаги на вашей стороне в порядке, можно проверкой MX-записей и проверкой SMTP-сервера.
Типы почтовых серверов
В небольшой компании одна машина делает всё сразу. Когда почты становится больше, роли разносят.
- Входящий сервер принимает почту домена, на него указывает MX. Он проверяет аутентификацию, фильтрует спам и доставляет письма в ящики.
- Исходящий сервер отправляет почту наружу. Это может быть свой Postfix на VPS или облачный сервис вроде Amazon SES и SendGrid.
- Relay стоит посередине: принимает письмо от одного MTA и передаёт другому. В корпоративных сетях через него часто пропускают всю исходящую почту, чтобы фильтровать её в одном месте.
- Почтовый шлюз (email gateway) ставят перед основным сервером ради безопасности: антиспам, антивирус, защита от утечек (DLP).
Где чаще всего рвётся цепочка
Схема полезна тем, что по симптому сразу видно звено. «Письма не уходят» и «письма уходят, но не доходят» это разные поломки в разных местах, и чинят их по-разному.
Если ваш клиент вообще не смог отправить письмо, проблема на участке клиент → MTA. Закрыт порт 587 или 465, неверный пароль, клиент не умеет STARTTLS, которого требует сервер. Всё это видно в логе вашего почтового сервера, и получатель о такой поломке даже не узнает.
Письмо ушло, а получатель его не видит? Тогда участок другой, DNS и антиспам. Здесь работают SPF, DKIM и DMARC, здесь же принимается решение, «Входящие» или «Спам». Смотрят это не в логах, а в заголовке Authentication-Results самого письма и в агрегированных отчётах DMARC. Сюда же относятся чёрные списки: если с IP сервера шёл спам, адрес попадает в DNSBL, и письма с него отклоняются или уходят в спам. Адрес можно проверить по чёрным спискам.
Третий случай, когда сервер получателя письмо принял, а в ящик оно не попало. Значит, сработал MDA или правило фильтрации, настроенное на стороне получателя. Отправитель тут бессилен: в его логах доставка выглядит успешной, потому что формально она такой и была.
Почему собственный сервер обходится дороже, чем кажется
Поднять Postfix можно за вечер. Дальше начинается то, что в смету обычно не закладывают: прогрев IP-адреса, регистрация в постмастер-кабинетах, обратная DNS-запись, слежение за чёрными списками, обработка отказов, ротация ключей DKIM. По отдельности каждый пункт несложен, вместе они складываются в постоянную работу.
Поэтому часто делают так: транзакционные и маркетинговые письма отдают сервису рассылок с прогретой инфраструктурой, а собственный сервер оставляют для внутренней переписки, где объёмы малы.
Почтовый сервер и проверка адресов
Проверяя адрес, валидатор говорит напрямую с MTA получателя. Он подключается по SMTP и спрашивает, примет ли сервер письмо для user@domain.com, а код ответа (250, 550, 450 и другие) говорит, есть ли такой ящик.
Честно отвечают не все. Сервер catch-all принимает любой адрес домена, и согласие ничего не доказывает, поэтому uChecker ставит таким адресам статус unknown. Переполненный ящик письмо отклонит, и адрес получает статус bad. Сервер с грейлистингом сначала отвечает временным отказом, и проверка повторяется позже, а если отказ направлен на IP проверяющего, а не на адрес, пробуют с другого IP. Получается не один SMTP-запрос, а разговор, в котором приходится учитывать повадки конкретного сервера.
Валидация адресов: деталь, о которой забывают
Вся эта машинерия работает вхолостую, если письма уходят на несуществующие адреса. Каждый жёсткий отказ портит репутацию отправителя, а сервер, который регулярно шлёт в пустоту, рискует оказаться в чёрном списке.
uChecker проверяет адрес до отправки: синтаксис, MX домена и ответ почтового сервера получателя. Каждый адрес получает статус good, bad или unknown. Через API проверку можно встроить в форму или запускать перед рассылкой.
Проверить базу →Источники
Марк Аврилов · Автор материала
Опубликовано Обновлено