SPF vs Sender ID

tdk

http://www.openspf.org/SPF_vs_Sender_ID

Sender Policy Framework
SPF vs Sender ID

What is SPF?

SPF (defined in RFC 4408) validates the HELO domain and the MAIL FROM address given as part of the SMTP protocol (RFC 2821 – the "envelope" layer). The MAIL FROM address is usually displayed as "Return-Path" if you select the "Show all headers" option in your e-mail client. Domain owners publish records via DNS that describe their policy for which machines are authorized to use their domain in the HELO and MAIL FROM addresses, which are part of the SMTP protocol.
What is Sender ID?

Sender ID (defined in RFC 4406) is a Microsoft protocol derived from SPF (hence the identical syntax), which validates one of the message's address header fields defined by RFC 2822. Which one it validates is selected according to an algorithm called PRA (Purported Responsible Address, RFC 4407). The algorithm aims to select the header field with the e-mail address "responsible" for sending the message.

Since it was derived from SPF, Sender ID can also validate the MAIL FROM. But it defines the new PRA identity to validate, and defines new sender policy record tags that specify whether a policy covers MAIL FROM (called MFROM by Sender ID), PRA, or both.



Is SPF the same thing as Sender ID? Which is better?
Executive summary

SPF and Sender ID are not the same. They differ in what they validate and what "layer" of the e-mail system they are concerned with. Sender ID is not the latest version of SPF – it is a new and independent experiment. The "spf2.0" tag name is a historical accident. Neither is better because they address different problems. There is controversy because Sender ID is incompatible with existing specifications. Microsoft is aware of the problem and representatives of theirs have stated that they have no plans to fix it. There are practical work-arounds for SPF and Sender ID users.
Are SPF and Sender ID the same?

SPF and Sender ID are not the same. Both validate e-mail sender addresses, and both use similar methods to do so. Both publish policy records in DNS. Both use the same syntax for their policy records. So you have some excuse to be confused. They differ in what they validate and what "layer" of the e-mail system they are concerned with.


Is Sender ID "SPF 2.0"?

The tag for SPF records is "v=spf1". It is defined by RFC 4408 to apply to the MAIL FROM and HELO identities only. The tag for Sender ID records can be "spf2.0/pra", "spf2.0/mfrom", or "spf2.0/mfrom,pra", depending on which identities the policy applies to. Nevertheless, Sender ID is not the latest version of SPF — it is a new and independent protocol. The tag name is a historical accident and was assigned by the failed MARID IETF working group.
Which is better?

Neither is better because they address different problems. Comparing them is comparing apples and oranges. SPF can be compared to other SMTP layer protocol proposals like CSV/CSA. Sender ID can be compared to other RFC 2822 layer protocols like DomainKeys IM (DKIM). Nevertheless, the SPF technical community does have its own opinion on the merits of Sender ID.
Why is there controversy about SPF vs Sender ID?

The Sender ID specification contains a recommendation to use SPF's v=spf1 policies — which are originally defined to apply to MAIL FROM and HELO identities only — and apply them to the PRA identity as well. Specifically, it says to consider v=spf1 as equivalent to spf2.0/mfrom,pra. This is technically wrong, as is explained in detail below. Sender ID implementors should correct this and treat v=spf1 records as equivalent to spf2.0/mfrom. Unfortunately this mistake in the Sender ID specification was not corrected prior to its publication despite an appeal from the SPF project.

This creates a very bad situation in that Sender ID implementations that follow the recommendation in the Sender ID specification (RFC 4406, section 3.4) violate the SPF specification (RFC 4408). Since the Sender ID specification defers to the SPF specification for the definition of v=spf1, and because SPF has been in existence (prior to the publication as an IETF RFC) a lot longer than Sender ID, the recommendation in the Sender ID specification should be ignored by implementors.
How will Sender ID implementations violating the SPF specification affect me?

If you have published an v=spf1 policy to protect the use of your domain in the MAIL FROM and HELO addresses, Sender ID implementations that apply your policy to PRA (per RFC 4406) will reject your mail if you use your domain in the "From" (or generally PRA) header field while sending from (MAIL FROM) another system.

Informal surveys have shown that in roughly 80% of e-mail surveyed, MAIL FROM and PRA are the same. However about 20% may be wrongly rejected or flagged by Sender ID implementations. Microsoft is aware of the problem and representatives of theirs have stated that they anticipate the conflict to resolve itself as soon as domain owners are publishing all their v=spf1 policy records with the possible PRA interpretation in mind. Of course this is not going to happen as there are hundreds of thousands of v=spf1 records out there that were published long before Sender ID even existed.
What should I do if my SPF record is misinterpreted?

First, contact the recipient who wrongly rejected your message and explain the problem. Send them here to learn about the issue. If you are peers, you may even be able to convince them to get their Sender ID implementation fixed to respect the original meaning of v=spf1 records.
Domain Owners

Meanwhile, if necessary, as a domain owner you can prevent Sender ID implementations that violate the SPF specification from using your v=spf1 policy for PRA checking by publishing an explicit spf2.0/pra policy. Unless you have researched and developed a PRA policy, you should publish an empty spf2.0/pra record (i.e., "spf2.0/pra"). There is no simple translation from MAIL FROM policy to PRA policy — they are different animals. Luckily, the Sender ID specification forbids implementations to fall back to a v=spf1 record for PRA checking if an (empty or not) spf2.0/pra record exists.
Mail Users

As a user, you can work around the problem by making PRA and MAIL FROM the same. For instance, if you are trying to send mail with your domain in the "From" header field, and Sender ID rejects it (because you are not sending from a system authorized by your v=spf1 policy), you can add a "Sender" header field to your messages (to override the "From" field with regard to PRA) with the domain you are sending from. Of course your mail client has to support this.
MTA Operators

Some people have experimented with working around Sender ID's incompatibility with SPF for mail that passes through their system by adding a "Sender" (or other more obscure) header field with a copy of the MAIL FROM to force the PRA address to match. Use this approach with caution — it has not been fully investigated for unintended consequences.
Sender ID implementors

Ignore the recommendation in the Sender ID specification, section 3.4, to treat v=spf1 equivalently to spf2.0/mfrom,pra. Instead, treat it as spf2.0/mfrom. At the very least, make this configurable in your implementation and make the spf2.0/mfrom interpretation the default.

tl49599419

楼主，能说下怎么设置 SPF 和 senderid 吗？

tdk

如果使用 Sender ID 的话，txt 段就应该是 v=spf2

tdk

另外这个需要邮局支持

alextawang

如果我的邮件服务器win2003 server上安装上DNS服务，自己做一套SPF记录能用吗？我的邮件服务器是托管在IDC机房的具有公网IP的PC服务器

tdk

能在公网上查到解析就行