Sender authentication part 14: Introduction to SenderID

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:

  1. Look for the first non-empty Resent-Sender header.  If it exists, use the domain in this field.  If not, proceed to step 2.
  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.
  3. Look for the Sender header.  If it exists, use the domain in this field.  If not, proceed to step 4.
  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:

Example 1

spf2.0/mfrom,pra +mx +ip4: -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, return a Pass.  Otherwise, return a Hard Fail.  Note that the + signs are included but not necessary.

Example 2

spf2.0/pra +mx +ip4: ~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, return a Pass.  Otherwise, return a Soft Fail.

Example 3

spf2.0/mfrom +mx +ip4: ?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, 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.

Example 1

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: -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 or is the reverse DNS of the domain’s mx record, then we have a SenderID pass.  Otherwise return a Hard Fail.

Example 2

From the example above, suppose that the SPF record instead said the following:

spf2.0/mfrom +mx +ip4: -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.

Comments (2)

  1. Bob Van Zant says:

    My favorite thing about Sender-ID is that it claims to protect against phishing but in practice it offers no benefits over SPF classic (which also provides little benefit). The reason is quite simple: most MUAs (mail user agent, ex. Outlook, Thunderbird) show the end user the From header, however, Sender-ID gives preference to, among others, the Resent-Sender header.

    This means that an attacker can setup a domain with a proper SPF2 record. He can then send mail from his new domain to a target that looks like so:




    Subject: Your account will be closed in 24 hours

    The Sender-ID check will pass, that message is perfectly legitimate, however, the From: header will be displayed to the end user. This means that the user will think the message truly came from Sender-ID has done nothing to protect the target from this phishing scam. RFC 4407 (Defines PRA) says:

      A message’s PRA will often be extracted from a header field that is

      not normally displayed by existing mail user agent software.  If the

      PRA is used as part of a mechanism to authenticate the message’s

      origin, the message SHOULD NOT be displayed with an indication of its

      authenticity (positive or negative) without the PRA header field also

      being displayed.

    I do not claim that SPF is better than Sender-ID. Instead I claim that Sender-ID offers no benefit over SPF.

  2. Maarten O. says:

    I don’t think it is correct to say that most MUA’s show the From:, and not the Resent-Sender:. If the Sender: header is used, Outlook will show "Sent on behalf of … by …" instead of just the From: address.