Sun Java System Messaging Server 6.3 管理指南

15.7 在 SPF 中使用发件人重写方案 (Sender Rewriting Scheme, SRS) 处理转发邮件

如上所述,SPF 是一种尝试通过查找特定的 TXT 记录来防止电子邮件伪造的机制,这些 TXT 记录与邮件 FROM:(信封 from)地址中的域关联。此操作实际上包括几个 DNS 查找操作,最终可生成一个 IP 地址列表,这些地址被授权发送来自域的邮件。将根据此列表检查 SMTP 客户端的 IP 地址,如果没有找到该地址,则邮件可能被认为是伪造邮件。Messaging Server 6.3 版实现了 SPF 支持。

SPF 使提供邮件转发服务的站点面临严重的问题,例如大学站点(为其毕业生转发)或专业机构站点(为其成员转发)。转发者将发出来自任意发件人的邮件,这些发件人可能包括已经实现 SPF 策略的发件人,当然还包括没有列出转发系统(或可以使用其域的地址的系统) IP 地址的发件人。

发件人重写方案(或 SRS)提供了此问题的解决方案。SRS 使用转发者自己的域将原始发件人的地址封装在一个新地址中,从而解决了该问题。转发者自己的域仅在进行 SPF 检查时公开。使用地址时会将邮件(通常是通知)路由给转发者,这样可删除地址封装并将邮件发送到真正的目的地。

当然,地址封装并非全新的技术。与 percent hack 路由和 bang 路径一样,源路由是在 RFC 822 中定义的,并正好提供了此类功能。但是,在目前的 Internet 中,这些机制都存在问题,因为允许使用它们实际上是将您的系统变成了一个开放的中继。

SRS 通过向封装格式添加一个加密的散列函数和一个时间戳来处理此问题。地址只在某个时间段是有效的,过了这段时间就不能再使用了。散列函数防止修改时间戳或封装的地址。

SRS 还提供一个机制处理多次转发,而不会使地址长度过度增长。要使该方案生效,必须在所有实现 SRS 的系统中以相同的方式对 SRS 地址的某些方面进行格式化。

现在在 6.3P1 版本中已经实现了 SRS 支持。添加了以下 MTA 选项:

设置这些选项后,即可启用 SRS 地址解码。编码则有所不同,应仅对您已知与转发活动关联的信封 From: 地址进行编码。SRS 编码由以下六个新的通道关键字控制:addresssrsnoaddresssrsdestinationsrsnodestinationsrssourcesrsnosourcesrs

要进行 SRS 编码,必须符合以下三个条件:

(1) 当前源通道必须用 sourcesrs 标记(nosourcesrs 是默认设置)。

(2) 当前目标通道必须用 destinationsrs 标记(nodestinationsrs 是默认设置)。

(3) 当前地址在重写时必须匹配标记为 addresssrs 的通道( noaddress 是默认设置)。

只有在符合以上所有条件时才能进行编码。最简单的设置是纯转发操作的设置,其中所有的邮件都从 tcp_local 通道进入或发出,并且所有的非本地地址都需要进行 SRS 处理。在这样的设置中,tcp_local 将使用 sourcesrsdestinationsrsaddresssrs 这三个关键字进行标记。

最后,imsimta test -rewrite 得到了增强,可以显示 SRS 编码和解码的结果,而不管输入的地址是什么。 例如,地址 foo@example.com 可能生成类似以下的输出:

SRS encoding = SRS0=dnG=IS=example.com=foo@example.org

如果重写此编码的地址,则生成的输出为:

SRS decoding = foo@example.com

imsimta test -rewrite 还会显示 SRS 解码期间出现的所有错误。