SMTP MTA для аутентификации MTA

Я все еще не понимаю, как принимающий MTA аутентифицирует пересылающий MTA.

Я представляю электронное письмо, которое пересылает MTA домена А._А в MTA домена B_B.

Шаги, которые необходимо предпринять MTA_А:

Найдите MX-запись домена B в DNS.
Подключитесь (проверьте X.509, чтобы убедиться в подлинности) и переслать сообщение.

Но что теперь делает MTA_B делать? Поскольку он не хочет рассылаться спамом и, скорее всего, включил аутентификацию пользователя, я вижу здесь 2 варианта:

MTA_B также сразу проверяет MX запись MTA_А, чтобы убедиться, что он обращается к зарегистрированному почтовому серверу.
MTA_B полагается только на черный, -, добавление в белый список

От моего локального хоста я получаю проблемы с "плохой репутацией" при попытке подключения.

Я не нашел ни информации по этому поводу в RFC, ни вопроса с моими ключевыми словами, кроме эта запись. Тем не менее, последний только отвечает как чтобы найти MTA и подключиться к нему, но не то, какие механизмы используются для аутентификации.

Буду признателен за любые подсказки :)

smtp authentication

В моей голове классические чеки:

как только известен IP-адрес входящего соединения: выполните обратный поиск IP-адреса в DNS - если он не удастся, вероятно, это не правильно настроенный законный MTA.
после завершения обратного поиска: выполните прямой DNS-поиск имени, возвращенного обратным поиском - если полученный IP-адрес не совпадает с подключающимся IP-адресом, вероятно, это не правильно настроенный законный MTA.
поскольку соединяющая сторона отправляет начальный HELO/EHLO сообщение: соответствует ли заявленное полное доменное имя в HELO / EHLO фактическому полному доменному имени, полученному в результате поиска DNS? В противном случае к подключению можно отнестись с некоторым подозрением, хотя его нельзя разорвать полностью. Если в соединении заявлено «внутреннее» доменное имя, но оно исходит от «внешнего» IP-адреса, необходимо выполнить требование аутентификации: это может быть попытка обмануть старые / плохо настроенные почтовые серверы или просто мобильный почтовый клиент.
поскольку соединяющая сторона отправляет MAIL FROM: строка: заявлено ли полное доменное имя источника в домене (ах), за который отвечает этот почтовый сервер? Если да, то это, вероятно, исходящая почта. В современных сетях соединяющаяся сторона должна на этом этапе уже включить шифрование (STARTTLS) и успешно пройти аутентификацию - в противном случае соединение может быть прервано прямо здесь. (Клиенты, не поддерживающие аутентификацию, в доверенных внутренних сетях могут быть явно занесены в белый список, чтобы пропустить требование аутентификации crypto +.)
Если заявленный MAIL FROM: адрес не находится в домене (ах), за который отвечает этот почтовый сервер, это должна быть входящая почта - это RCPT TO: адрес внутри доменов, для которых этот почтовый сервер должен обрабатывать почту? Если нет, то это попытка злоупотребления реле -> разорвать соединение.

После этих проверок соединение, вероятно, будет достаточно законным, чтобы DATA могут быть приняты, и начаты более сложные проверки SPF / DKIM / DMARC и черного списка. Универсальной SMTP-аутентификации между MTA разных организаций не существует.

Также существует опция серого списка: если это первое соединение с ранее неизвестного исходного адреса, попытка рассылки может быть отклонена сразу с кодом ошибки «временный сбой». Законный сервер подождет некоторое время, а затем сделает новую попытку. Если указанный минимальный период времени прошел с первой попытки, принимающий MTA теперь будет обрабатывать входящую электронную почту как обычно, и если электронная почта проходит все другие проверки, дальнейшие соединения из того же источника будут приниматься без начальной задержки.