Comments 7
В ваших примерах почта отправляется на адреса, за почту которых данный smtp сервер ответственен: “интерес для нас представляет отправка писем внутри корпоративного контура”. Почему вы называете это недостатком, smtp relay и вообще говорите об этом как о чём-то плохом? А как ещё людям почту слать?
Корпоративный пользователь выполняет взаимодействие с сервером из внутренней сети и, вероятнее всего, с использованием доменной авторизации в корпоративных сервисах .
Внешний пользователь подключается из сети Интернет без предварительной проверки подлинности . Очевидно, что внутреннему пользователю такой сценарий не подходит - это две разные сущности.
Если внимательно изучить скриншоты, представленные выше, сформируется понимание, что большинство корректно настроенных серверов контролируют попытки неавторизованных рассылок на этапе указания адресов (сообщения типа Relay access denied, spam spoofing и тд), в том числе не единичны случаи принудительной потери соединения с сервером при попытке подключения.
Бесконтрольная отправка почтовой корреспонденции внутри корпоративного контура внешним неавторизованным пользователем посредством подключения к почтовому серверу - очевидный недостаток. Суть проблемы не в том, как сервер маршрутизирует почту внутри домена, а в том, что в этот процесс может вмешаться внешний персонаж, не имеющий никакого отношения к корпоративной сети.
В рамках статьи приведены меры, позволяющие устранить недостаток, в том числе, не нарушающие его работоспособность (например, аутентификация).
Вы это мне отвечали? Вы не ответили на вопрос: где на ваших скриншотах что-то плохое? Я вижу какие-то диалоги smtp, но не вижу в них никаких “недостатков”
Как раз аутентификация на 25 порту нарушит работоспособность доставки со сторонних серверов :)
А вот проверка IP отправителя (по reverse DNS, соответствию тому, что указано в HELO/EHLO, наличию в DNSBL), проверка адреса из MAIL FROM на соответствие SPF, проверка DKIM - это всё как раз помешает внешнему отправителю (по определению неаутентифицированному) выдать себя за кого-то другого.
Нарушение работоспособности по причине принудительной аутентификации - частная история, такое действительно случается. В остальном вы совершенно правы. И по-хорошему, проверка SPF и DKIM должна быть настроена админами ресурса по дефолту чуть ли не при первом старте.
Главное, найти ту тонкую грань, чтобы не переусердствовать. Ибо если письма не доходят до Яндекса или Гугла - это проблема отправителя, а если они не доходят до корпоративного почтового сервера - это проблема админа этого сервера :)
Невалидный DKIM до сих пор сплошь и рядом встречается во вполне благонадёжных и ожидаемых получателями письмах (посылаю лучи ненависти админам серверов отправителей оных, но это факт). SPF - если там в конце soft fail "~all", а не hard fail "-all", то мы его по стандарту должны принимать всё равно, а этот soft fail повально у всех. В DNSBL пачками заносят совершенно невинные адреса. И т.п.
SMTP как открытая дверь для фишинга. Популярный недостаток почтовых серверов и меры предосторожности