Now that we’ve moved our way through the workings of SPF, let’s take a look at Microsoft’s own branded technology, SenderID (I don’t mean that Microsoft invented it since it derives from an earlier standard, only that Microsoft advocates the use of it). From Microsoft’s website:
The Sender ID Framework is an e-mail authentication technology protocol that helps address the problem of spoofing and phishing by verifying the domain name from which e-mail messages are sent.
Well, that’s a worthy goal. Spoofing and phishing are serious problems in the antispam world.
Sender ID validates the origin of e-mail messages by verifying the IP address of the sender against the alleged owner of the sending domain.
This sounds a heck of a lot like SPF. SPF works by validating the origin of email messages by verifying IP address of the sender against the authorized IPs that are allowed to send mail from the domain. SPF does this by examining the SPF records of the domain in the envelope sender. SenderID does this too, but it can implemented to work on either the envelope sender or another address in the message headers.
SenderID introduces the concept of a Purported Responsible Address (PRA). Acquisition of the PRA is described in RFC 4407. Briefly, PRA is obtained by examining the message headers and extracting one of the following fields:
- Look for the first non-empty Resent-Sender header. If it exists, use the domain in this field. If not, proceed to step 2.
- Look for the first non-empty Resent-From header. If it exists, use the domain in this field. If not, proceed to step 3.
- Look for the Sender header. If it exists, use the domain in this field. If not, proceed to step 4.
- Look for the From header (not to be confused with the MAIL FROM, or envelope header). If it exists, use the domain in this field. If not, the message is malformed and we cannot extract a PRA.
Most of the time, the PRA will turn out to be the email address in the From: field that shows up in your email client. It’s also the one that is most useful to the end user most of the time because that’s the one they actually see. Anyhow, a SenderID check would extract the domain from the PRA and perform an SPF check on it by looking at the domain’s SPF record and then performing the same actions as a regular SPF check (Hard Fail, Soft Fail, etc).
However, things are a bit more complicated than this. Not only does SenderID introduce the concept of PRA, it also introduces new syntax for SPF Records.
SPF records begin with a version identifier and may also include a scope: r
record = version terms *SP
version = “v=spf1” | ( “spf2.” ver-minor scope)
ver-minor = 1*DIGIT
scope = “/”
scope-id *( “,” scope-id ) scope-id = “mfrom” / “pra” / name
The rest of the syntax is the same as SPF. A domain that includes SenderID-compliant records could use the following syntax:
spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all
This defines an SPF record that can be used for either MAIL FROM or PRA checks. If the IP is in the domain’s mx record or is 192.168.0.100, return a Pass. Otherwise, return a Hard Fail. Note that the + signs are included but not necessary.
spf2.0/pra +mx +ip4:192.168.0.100 ~all
This defines an SPF record that can be used only for PRA checks. If the IP is in the domain’s mx record or is 192.168.0.100, return a Pass. Otherwise, return a Soft Fail.
spf2.0/mfrom +mx +ip4:192.168.0.100 ?all
This defines an SPF record that can be used only for MAIL FROM checks. If the IP is in the domain’s mx record or is 192.168.0.100, return a Pass. Otherwise, return a Neutral.
The question natually arises: how do we know whether to extract and check the domain in the PRA or the domain in the MAIL FROM? The answer is: it depends on how you want to implement it.
Suppose you are running an email service, perhaps a hosted service that exchanges email, and you want to implement SenderID on the PRA only. That means you will extract the domain in the PRA and skip the domain in the envelope sender (the MAIL FROM). You lookup the domain’s SPF record and it says the following:
spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all
First, we see that this domain supports SenderID. Second, the record indicates that the SPF record can be used to verify either the domain in the MAIL FROM or the domain in the PRA. If the transmitting IP is 192.168.0.100 or is the reverse DNS of the domain’s mx record, then we have a SenderID pass. Otherwise return a Hard Fail.
From the example above, suppose that the SPF record instead said the following:
spf2.0/mfrom +mx +ip4:192.168.0.100 -all
This record only specifies the IPs in the MAIL FROM domain that are authorized to send mail. It says nothing about which IPs in the PRA are permitted. Therefore, since we are checking the domain from the PRA, the result of this SenderID check is a None.
So, SenderID allows the implementor the flexibility to protect either the envelope sender or sender in the message headers (usually the From: address). However, the standard does not specify which one should be checked so it is up to the user to decide how to do it.
In my next post, I will examine the way that SenderID records treat SPF records and why there is some controversy surrounding it.