☰

有人可以解释一下启用 BATV 时的 SMTP 回调以及何时发出验证吗？

tag-icon • tag-icon smtp spam
有人可以解释一下启用 BATV 时的 SMTP 回调以及何时发出验证吗？

这维基百科文章介绍了 SMTP 验证方法如果启用 BATV，MFROM 可能会出现问题。

拒绝所有退回邮件的服务器（与 RFC 相反）。为了解决这个问题，例如，postfix 在 MAIL FROM 部分的调出部分使用本地邮局局长地址或“双退回”地址。但是，如果使用退回地址标签验证来减少反向散射，则此解决方法将失败。[3] 如果拒绝所有退回发生在 DATA 阶段而不是早期的 MAIL FROM 阶段，则回调验证仍然可以工作，而拒绝无效电子邮件地址仍留在 RCPT TO 阶段，而不是也移至 DATA 阶段。1[2]

解决方法是验证“数据”中的地址。由于数据未经验证（假设未使用 DKIM），因此这不会被欺骗，这难道不是一个弱的解决方法吗？

答案1

让我们按语句拆分

拒绝所有退回邮件的服务器（与 RFC 相反）。

是的，这个配置错误的服务器拒绝所有发件人为 <> 的电子邮件。

为了解决这个问题，例如，postfix 在标注的 MAIL FROM 部分中使用本地邮政局长地址或“双反弹”地址。

是的，此解决方法将防止错误配置的远程服务器拒绝发件人为<>的电子邮件。

然而，如果使用反弹地址标签验证来减少反向散射，这种解决方法将会失败。

BATV 是技术验证退回电子邮件以防止反向散射. 它的工作原理是将原始发送者重写为一些加密令牌。如果发件人设置为<>，BATV 检查器只会检查电子邮件的收件人地址。如果某些 MTA 使用 postmaster@ 地址执行回调验证，系统不会将电子邮件传递给 BATV 检查器（因为它不是退回的），而是拒绝它们，因为收件人不存在（只有 BATV 检查器可以验证收件人是否匹配其加密令牌）。

如果拒绝所有退回邮件发生在 DATA 阶段而不是早期的 MAIL FROM 阶段，则回调验证仍然可以工作，而拒绝无效的电子邮件地址仍留在 RCPT TO 阶段，而不是也移至 DATA 阶段。

注意：此声明与 BATV 无关。它解决了第一个问题（服务器拒绝所有退回邮件（违反 RFC））。

因此，我们这里有两个拒绝过程，因为1）收件人不存在或者2）它是反弹地址（通过<>标识）客户端（验证者）发出 RCPT TO 后，服务器会进行检查，以验证收件人地址是否存在。如果收件人存在，服务器将回复代码 2XX OK。

因此，验证者将假定该地址没有问题，并且它将断开连接然而真正的退信邮件会进入DATA阶段（邮件头/邮件主体还未发送...），此阶段服务器会因为退信而拒绝该邮件。

解决方法是验证“数据”中的地址。由于数据未经验证（假设未使用 DKIM），因此这不会被欺骗，这难道不是一个弱的解决方法吗？

不，它不验证数据中的地址（也许你指的是电子邮件标头中的地址）。事实上，标头尚未发送，但服务器已拒绝它。

此处的图示解释了拒绝发生的位置。原始来源

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

相关内容