Sender ID

操作原理

Sender ID脱胎于SPF，只增加了部分内容。下面讨论两者的差异：

Sender ID试图改进SPF中的主要缺陷：SPF不验证表示发送方的头地址。此类地址通常是显示给用户并作为回复地址，因而，此类报头地址可以与SPF尝试验证的地址不同。也就是说，SPF仅验证了邮件来自（MAIL FROM）地址，也称邮件发送人。

然而，还有许多类似的报头字段包含发送方的信息。因此，在RFC 4407中定义的Sender ID定义了一个“声称负责地址”（Purported Responsible Address，缩写PRA）以及一组启发式规则，用于从的许多典型报头中创建此地址。

在语法上，Sender ID与SPF相差无几，除了v=spf1被替换为下列之一：

• spf2.0/mfrom- 表示同SPF那样验证邮件发送人。

• spf2.0/mfrom,pra或spf2.0/pra,mfrom- 表示验证邮件发送人和声称负责地址。

• spf2.0/pra- 表示只验证声称负责地址。

Sender ID的另一项语法差异是，它提供SPF不支持的定位（positional）修饰符特性。但实际上，到目前为止，还没有任何Sender ID的实现指定定位修饰符。

在实践中， pra（声称负责地址）方案通常只在合法时提供保护，而在垃圾邮件或网络钓鱼的情况下不提供真正的保护。最合法的 pra是熟悉的From:头字段，或者邮件列表中的Sender:头字段。但在网络钓鱼或垃圾邮件中， pra可能基于通常不向用户显示的Resent-*头字段。要成为有效的反钓鱼工具，需要修改MUA（“邮件代理人”或“邮件客户端”）以显示用于Sender ID的pra，或者用于SPF的Return-Path:。

pra尝试抵制的是网络钓鱼问题，而SPF或mfrom尝试解决的是垃圾邮件退回和其他自动回复到伪造的回复地址（Return-Path）的问题。两个不同的问题要使用不同的解决方案。

标准化问题

pra的缺点是，转发器和邮件列表只能通过修改邮件头来支持它，例如插入一个Sender或Resent-Sender。而后者违背RFC 2822并可能与RFC 822不兼容。

在使用SPF时，邮件列表能继续运作。希望支持SPF的转发器只需要修改SMTP MAIL FROM（邮件来自）和RCPT TO（回复至），而不是邮件。这不是新的概念，原始的RFC 821 SMTP转发器始终将其主机名添加到MAIL FROM中的反向路径。

最大的问题是，核心Sender ID规范推荐解释v=spf1策略为如同spf2.0/mfrom,pra而不是spf2.0/mfrom。这在2003年以来发布的所有SPF草案中从未考虑，并且对于未知的大量v=spf1策略、同时有pra和mfrom且不同的许多情况，对pra的评估可能导致错误的结果。此问题是向互联网架构委员会（IAB）呼吁的基础。为响应另一个先前的呼吁，IESG已注明Sender ID不能在IETF标准轨道上继续前进，必须先解决与RFC 2822的不兼容。

知识产权

Sender ID提案也是一个涉及知识产权授权的话题：微软持有Sender ID关键部分的专利，并以不兼容GNU通用公共许可证的条款许可这些专利，这在一些自由软件实现中被认为是有问题的。2006年10月23日，微软将这些专利放置到开放标准承诺下，这与自由和开源许可证兼容，但与GPL许可证3.x版本不兼容。