我仍然不明白接收 MTA 如何验证转发 MTA。
我想象一封电子邮件由域 A 的 MTA A转发到域 B 的 MTA B。
MTA A应采取的步骤:
- 在DNS中查找域B的MX记录。
- 连接(验证 X.509 以确保真实性)并转发消息。
但是现在,MTA B会做什么?由于它不想被垃圾邮件骚扰,而且很可能启用了用户身份验证,所以我看到这里有 2 个选项:
- MTA B还会立即检查 MTA A的 MX 记录,以确保它正在与已注册的邮件服务器进行通信。
- MTA B仅依赖黑名单、白名单
当我尝试连接本地主机时,我遇到了“声誉不佳”的问题。
我在 RFC 中找不到任何关于此问题的信息,也没有找到我的关键词问题,除了此条目。然而,后者只回答如何查找并连接 MTA,但不知道使用什么机制进行身份验证。
如有任何提示我将不胜感激:)
答案1
在我看来,经典的检查是:
- 一旦知道传入连接的 IP 地址:对 IP 地址进行反向 DNS 查找 - 如果失败,则它可能不是配置良好的合法 MTA。
- 反向查找完成后:对反向查找返回的名称进行正向 DNS 查找 - 如果结果 IP 与连接 IP 不匹配,则它可能不是配置良好的合法 MTA。
- 当连接方发送初始
HELO
/EHLO
消息时:HELO/EHLO 中声明的 FQDN 是否与 DNS 查找报告的实际 FQDN 匹配?如果不匹配,则可以对连接进行一些怀疑,尽管可能不会直接终止连接。如果连接声明“内部”域名但来自“外部”IP 地址,则应强制执行身份验证要求:这可能是试图欺骗旧的/配置不当的邮件服务器,或者只是移动电子邮件客户端。 当连接方发送以下
MAIL FROM:
行时:声明的源 FQDN 是否在该邮件服务器负责的域内?如果是,则这可能是外发邮件。在当今的网络中,连接方此时应该已经启用加密(STARTTLS)并成功通过身份验证 - 如果没有,则可以立即终止连接。(受信任的内部网络中不支持身份验证的客户端可能会被明确列入白名单以跳过加密+身份验证要求。)如果声明的
MAIL FROM:
地址不在该邮件服务器负责的域内,则这应该是传入邮件 - 该RCPT TO:
地址是否在该邮件服务器应该处理邮件的域内?如果不是,则这是中继滥用尝试 -> 终止连接。
经过这些检查后,连接可能足够合法,DATA
可以被接受,并且更复杂的 SPF/DKIM/DMARC 和黑名单检查开始。不同组织的 MTA 之间没有通用的 SMTP 身份验证。
还有一个灰名单选项:如果这是来自之前未知的源地址的第一次连接,则可以使用“暂时失败”错误代码直接拒绝邮件尝试。合法服务器将等待一段时间,然后再进行一次尝试。如果从第一次尝试开始已经过了指定的最短时间,则接收 MTA 现在将正常处理传入的电子邮件,并且如果电子邮件通过了所有其他检查,则将接受来自同一来源的进一步连接,而无需最初的延迟。