Sender ID
![本页使用了标题或全文手工转换](http://images.weserv.nl/?url=//upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Zh_conversion_icon_m.svg/35px-Zh_conversion_icon_m.svg.png)
![]() | 此条目翻译自其他语言维基百科,需要相关领域的编者协助校对翻译。 |
此条目需要补充更多来源。 (2017年2月16日) |
互联网安全协议 |
---|
密钥管理 |
应用层 |
域名系统 |
网络层 |
Sender ID是曾经加入发件人策略框架(SPF)和Caller ID的前MARID IETF工作组的一项反欺骗协议。 Sender ID主要定义在实验性RFC 4406,而其余部分在RFC 4405、RFC 4407和RFC 4408中定义。
操作原理
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关键部分的专利[1][2],并以不兼容GNU通用公共许可证的条款许可这些专利,这在一些自由软件实现中被认为是有问题的。2006年10月23日,微软将这些专利放置到开放标准承诺下,这与自由和开源许可证兼容,但与GPL许可证3.x版本不兼容。
参见
- Category:电子邮件身份验证
- 电子邮件身份验证 - 概述
- MARID(2004年IETF WG)
- DKIM
- DomainKeys
参考资料
外部链接
- ASF Position Regarding Sender ID(页面存档备份,存于互联网档案馆),Apache软件基金会的声明
- IAB appeal(页面存档备份,存于互联网档案馆) about Sender ID's reuse of v=spf1 for PRA from the SPF project (2006).
- Debian project unable to deploy Sender ID(页面存档备份,存于互联网档案馆),Debian项目的声明
- IETF Decides on SPF / Sender-ID issue,slashdot上的讨论
- Is Sender ID Dead in the Water? - No MARID Working Group Consensus(页面存档备份,存于互联网档案馆),groklaw上的讨论
- MARID Co-Chairs Clarify Consensus Statement(页面存档备份,存于互联网档案馆)
- MARID to close邮件列表话题。
- Sender ID: A Tale of Open Standards and Corporate Greed?(页面存档备份,存于互联网档案馆)
- "SPF: SPF vs Sender ID"