本维基百科文章描述了如果启用BATV，MFROM的SMTPvalidation可能会有问题。
拒绝所有退回邮件的服务器（与RFC相反）。 要解决这个问题，例如，postfix在标注的MAIL FROM部分使用本地postmaster地址或者“double-bounce”的地址。 但是，如果使用跳动地址标记validation来减less反向散射，则此解决方法将失败。[3] 如果在DATA阶段而不是在前的MAIL FROM阶段拒绝所有的反弹，而拒绝无效的电子邮件地址仍然在RCPT TO阶段，而不是同时被移到DATA阶段，则callbackvalidation仍然可以工作。 1 [2]
解决scheme是validation“数据”中的地址。 由于数据没有validation（假设DKIM没有被使用），这不能被欺骗，这不是一个弱解决方法吗？
让我们按语句分割
拒绝所有退回邮件的服务器（与RFC相反）。
是的，这个错误configuration的服务器拒绝所有发件人<>的电子邮件。
要解决这个问题，例如，postfix在标注的MAIL FROM部分使用本地postmaster地址或者“double-bounce”的地址。
是的，这个解决方法将防止configuration错误的远程服务器拒绝发件人<>的电子邮件。
但是，如果使用反弹地址标记validation来减less反向散射，则此解决方法将失败。
BATV是validation反弹电子邮件以防止后向散射的技术 。 它的工作原理是将原始发件人重写为某个encryption标记 。 如果发件人设置为<>，BATV检查器只检查电子邮件的收件人地址。 如果某些MTA使用postmaster @地址执行回拨validation，则系统不会将电子邮件传递给BATV检查器（因为它不是弹回），而是因为收件人不存在而拒绝它们（只有BATV检查器可以validation收件人是否匹配其密码令牌）。
如果在DATA阶段而不是在前的MAIL FROM阶段拒绝所有的反弹，而拒绝无效的电子邮件地址仍然在RCPT TO阶段，而不是同时被移到DATA阶段，则callbackvalidation仍然可以工作。
注：本声明与BATV没有关系。 它解决了第一个问题（拒绝所有反弹邮件的服务器（与RFC相反））。
因此，我们在这里有两个拒绝过程，因为1）收件人不存在或2）是退回地址（由<>标识） 。 在客户端（validation者）发出RCPT TO之后，服务器将执行检查以validation收件人地址是否存在。 如果收件人存在，则服务器将回复代码2XX OK。
正因为如此，validation者会认为地址正确，并且会断开连接 。 然而，真正的反弹电子邮件将进入数据阶段（电子邮件标题/正文尚未发送…），在这个阶段，服务器将因为退回电子邮件拒绝它。
解决scheme是validation“数据”中的地址。 由于数据没有validation（假设DKIM没有被使用），这不能被欺骗，这不是一个弱解决方法吗？
不，它不validation数据中的地址（也许你是指邮件头中的地址）。 事实上，标题还没有被发送，但服务器已经拒绝了它。
这里用来解释拒收发生的例子。 原始来源
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready S: HELO USC-ISIF.ARPA R: 250 BBN-UNIX.ARPA S: MAIL FROM:<[email protected]> R: 250 OK S: RCPT TO:<[email protected]> 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