это В статье Википедии описывается, как проверка SMTP MFROM могут возникнуть проблемы, если BATV включен.
Серверы, которые отклоняют все сообщения о недоставке (вопреки RFC). Чтобы обойти эту проблему, postfix, например, использует либо локальный адрес почтмейстера, либо адрес «double-bounce» в части MAIL FROM выноски. Однако этот обходной путь потерпит неудачу, если для уменьшения обратного рассеяния используется проверка тега адреса возврата. [3] Проверка обратного вызова все еще может работать, если отклонение всех отказов происходит на этапе DATA вместо более раннего этапа MAIL FROM, в то время как отклонение недействительных адресов электронной почты остается на этапе RCPT TO вместо того, чтобы также перемещаться на этап DATA.1[2]
Решение - проверить адрес в «Данных». Поскольку Данные не проверены (при условии, что DKIM не используется), нельзя ли это подделать, и разве это не слабый обходной путь?
Давайте разделим его по утверждениям
Серверы, которые отклоняют все сообщения о недоставке (вопреки RFC).
Да, этот неправильно настроенный сервер отклоняет все письма с отправителем <>.
Чтобы обойти эту проблему, postfix, например, использует либо локальный адрес почтмейстера, либо адрес «double-bounce» в части MAIL FROM выноски.
Да, этот обходной путь предотвратит отклонение неправильно настроенного удаленного сервера электронной почты с отправителем <>.
Однако этот обходной путь не сработает, если для уменьшения обратного рассеяния используется проверка тега адреса возврата.
BATV был методом проверка письма о недоставке, чтобы предотвратить обратное рассеяние. Это работает перепишите исходного отправителя на какой-нибудь криптографический токен. Программа проверки BATV проверяет адрес получателя электронного письма только в том случае, если для отправителя установлено значение <>. Если некоторые MTA использовали postmaster @ address для выполнения проверки обратного вызова, система не будет передавать электронное письмо в средство проверки BATV (потому что это не возврат), а отклоняет их, потому что получатель не существует (только программа проверки BATV может проверить, соответствует ли получатель его криптографическому токену).
Проверка обратного вызова все еще может работать, если отклонение всех отказов происходит на этапе DATA вместо более раннего этапа MAIL FROM, в то время как отклонение недействительных адресов электронной почты остается на этапе RCPT TO вместо того, чтобы также перемещаться на этап DATA.
Примечание: это утверждение не имеет отношения к BATV. Он решил первую проблему (серверы, которые отклоняют все сообщения о недоставке (вопреки RFC)).
Итак, у нас есть два процесса отказа, потому что 1) получателя не существует или 2) это адрес возврата (обозначается <>). После того, как клиент (проверяющий) выдал RCPT TO, сервер выполнит проверки, чтобы убедиться, что адрес получателя существует. Если получатель существует, сервер ответит кодом 2XX OK.
Из-за этого проверяющий будет считать, что адрес в порядке и он отключится. Тем не менее, реальное письмо о недоставке перейдет в стадию ДАННЫХ (заголовок / тело письма еще не отправлено ...), на этом этапе сервер отклонит его из-за недоставленного письма.
Решение - проверить адрес в «Данных». Поскольку Данные не проверены (при условии, что DKIM не используется), нельзя ли это подделать, и разве это не слабый обходной путь?
Нет, он не проверяет адрес в ДАННЫХ (возможно, вы имеете в виду адрес в заголовке электронного письма). Фактически, заголовок не был отправлен, но сервер его уже отклонил.
Вот иллюстрация, объясняющая, где происходит отказ. В первоисточник
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA
S: MAIL FROM:<Smith@USC-ISIF.ARPA>
R: 250 OK
S: RCPT TO:<Jones@BBN-UNIX.ARPA>
R: 250 OK <--- "non existed address" rejection occurs here
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF> <--- "bounce" rejection occurs here
S: Blah blah blah... <--- email header and body
S: ...etc. etc. etc.
S: .
R: 250 OK
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel