Кто-то может объяснить Обратные вызовы SMTP, когда BATV включен, и когда выпустить проверку?
Эта статья Wikipedia описывает, как проверка SMTP MFROM может иметь проблемы, если BATV включен.
Серверы, которые отклоняют все письма возврата (вопреки RFCs). Для работы вокруг этой проблемы постфикс, например, использует или локальный адрес администратора почты или адрес "двойного возврата" в ПОЧТЕ ОТ части выноски. Это обходное решение, однако, перестанет работать, если Проверка Тега Адреса Возврата будет использоваться для сокращения обратного рассеяния. [3] проверка Обратного вызова может все еще работать, если отклонение всех возвратов происходит на этапе ДАННЫХ вместо более ранней ПОЧТЫ ОТ этапа, в то время как отклонение недопустимых адресов электронной почты остается при ПРИЕМЕ подготавливать вместо того, чтобы также быть перемещенным в этап 1 [2] ДАННЫХ
Разрешение состоит в том, чтобы проверить адрес в "Данных". Так как Данные не проверяются (предполагающий, что DKIM не используется), разве это не может имитироваться, и разве это не слабое обходное решение?
Давайте разделим его по операторам
Серверы, которые отклоняют все сообщения о недоставке (в отличие от RFC).
Да, этот неправильно настроенный сервер отклоняет все сообщения с отправителем <>.
Чтобы обойти эту проблему, postfix, например, использует либо локальный адрес почтмейстера, либо адрес «double-bounce» в части MAIL FROM выноски.
Да, этот обходной путь предотвратит неверно сконфигурированный удаленный сервер отклонять электронную почту с помощью sender <>.
Этот обходной путь, однако, завершится неудачно, если для уменьшения обратного рассеяния используется проверка тега адреса возврата.
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