У большинства текущих MTA есть возможность использования Sendercallouts — это когда к вашему SMTP серверу подключаются, а вы проверяете адрес отправителя указанный во время SMTP-сессии, попыткой подключения к удаленному серверу и пытаетесь отправить на этот адрес почту, чтобы узнать существует ли такой адрес.
С виду очень удобная вещь особенно если ее применять после всех остальных проверок, чтобы снизить нагрузку. Работает она очень просто наш сервер получая соединение от сервера и доходя до стадии RCTP TO:<our_user@domain.tld> открывает соединение до example.com и пытаеться отправить письмо, если после команды RCPT TO:<someone@example.com> ответ 250 OK, наш сервер закрывает соединение на удаленый сервер и разрешает передачу тела письма. И это работает отлично до тех пор пока вы не встретите рассылки от роботов у которых обратные адреса не существуют. Это решается обязательной поддержкой whitelisting'а. В реальной жизни всем известно, что адрес отправителя можно подделать. Если будет произведена DDOS атака на ваш SMTP сервер, ваш сервер в суматохе начнет проверять кучи отправителей стуча удаленные серверы большим кол-вом запросов и скорее всего вас на них в итоге забанят.
Хуже когда на обоих серверах стоят SAV и они скорее всего попадут в бесконечный цикл проверки своих адресов. Первый вышлет емайл, второй ответит 451 Unverified и попробует подключиться к первому на что ему тот ответит тоже 451 Unverified ну и так до бесконечности. Конечно при определенной конфигурации этого можно избежать, но мы же незнаем какая конфигурация у удаленного сервера.
Поэтому для проверок отправителя существует команда VRFY, которая описана в RFC2821. Раньше она была почти везде включена и спамеры хорошо ей пользовались для поиска рабочих емайлов методом перебора используя словарь. Тогда ее стали везде выключить, чтобы уменишть поток спама на существующие адреса, а как итоге через 10к лет снова пытались к ней вернуться используя SAV. Почти во всех MTA реализована VRFY команда, но она не имеет никакой защиты.
Допустим сейчас в Postfix можно сделать кучу проверок до того как мы вышлем 250 OK на команду RCTP TO:<user@example.com>, но эти ограничения нельзя использовать для VRFY комманды, но конечно она не аунтефицирует отправителя. Для аунтефикации отправителя сейчас можно использовать DomainKeys Identified Mail.
С виду очень удобная вещь особенно если ее применять после всех остальных проверок, чтобы снизить нагрузку. Работает она очень просто наш сервер получая соединение от сервера и доходя до стадии RCTP TO:<our_user@domain.tld> открывает соединение до example.com и пытаеться отправить письмо, если после команды RCPT TO:<someone@example.com> ответ 250 OK, наш сервер закрывает соединение на удаленый сервер и разрешает передачу тела письма. И это работает отлично до тех пор пока вы не встретите рассылки от роботов у которых обратные адреса не существуют. Это решается обязательной поддержкой whitelisting'а. В реальной жизни всем известно, что адрес отправителя можно подделать. Если будет произведена DDOS атака на ваш SMTP сервер, ваш сервер в суматохе начнет проверять кучи отправителей стуча удаленные серверы большим кол-вом запросов и скорее всего вас на них в итоге забанят.
Хуже когда на обоих серверах стоят SAV и они скорее всего попадут в бесконечный цикл проверки своих адресов. Первый вышлет емайл, второй ответит 451 Unverified и попробует подключиться к первому на что ему тот ответит тоже 451 Unverified ну и так до бесконечности. Конечно при определенной конфигурации этого можно избежать, но мы же незнаем какая конфигурация у удаленного сервера.
Поэтому для проверок отправителя существует команда VRFY, которая описана в RFC2821. Раньше она была почти везде включена и спамеры хорошо ей пользовались для поиска рабочих емайлов методом перебора используя словарь. Тогда ее стали везде выключить, чтобы уменишть поток спама на существующие адреса, а как итоге через 10к лет снова пытались к ней вернуться используя SAV. Почти во всех MTA реализована VRFY команда, но она не имеет никакой защиты.
Допустим сейчас в Postfix можно сделать кучу проверок до того как мы вышлем 250 OK на команду RCTP TO:<user@example.com>, но эти ограничения нельзя использовать для VRFY комманды, но конечно она не аунтефицирует отправителя. Для аунтефикации отправителя сейчас можно использовать DomainKeys Identified Mail.