Sender authentication part 16: SenderID vs SPF

SPF and SenderID are similar to each other in the way they act, but the differences between them are in what they are designed to target (at least how I see it).

Both OpenSPF and Wikipedia say that SenderID and SPF are designed to address different problems.  SPF is designed to work with SMTP while SenderID is designed to protect the content of a message.  I think it’s a stretch to claim that it’s like comparing apples to oranges; let me explain myself.

SenderID can be implemented to work just like SPF, but also introduces (and recommends) features to protect the content of the message.  It does this by examining the message headers and extracting the Purported Responsible Address (PRA).  None of these message headers are required by the SMTP protocol, they are extra headers that can be found in RFC 2822.  Anyways, these message headers are basically part of the message content and are used to display information to the end user.  The From: address is the one that the end-user sees and is part of the content of the message.  Because most users will assume that the From: address is the one that sent the message (especially for phishing), SenderID can be used to protect against forged email addresses that are displayed to the end-user (the one that the sender wants the receiver to think the message came from).  In other words, it protects against forged content.

SPF, on the other hand, can also work against forged Return-Paths (also known as envelope senders).  It’s basically a connection-level protocol that protects against spoofing the envelope sender for a domain.  While this can work in the case that a spammer spoofs a bank (phishing), SPF is not explicitly protecting the content because it can do all of its checking before it even receives the message content.

Both protocols protect against forged senders, but one does the work at the connection level while one does it at the content level.  SPF protects against bounced messages and SenderID does not, but that doesn’t mean that SenderID couldn’t be implemented to do the same thing.  There are, of course, some parts that do not carry over between SenderID and SPF but to say that comparing the two is comparing two completely different things is inaccurate.  I think that there is too much overlap.

Comments (1)

  1. Frank says:

    Hi, you write "I think that there is too much overlap." There is indeed much overlap, the complete syntax, the DNS and error handling, last but not least one co-author of both RFC 4406 and 4408.

    As far as all three spf2.0/mfrom combinations mean the same as v=spf1 there is even too much overlap. But ignoring the overlap the remaining differences between PRA and SPF are significant:

    SPF can be checked before the SMTP DATA, without ever looking in the actual message. PRA needs the DATA to get at the message header.

    An SPF PASS from an unknown stranger is likely a spammer, but at least a later bounce cannot hit an innocent bystander. A PRA PASS from an unknown stranger is likely a spammer, and it doesn’t help for anything (arranging a PASS is cheap for the bad guys, for SPF and PRA alike).

    Senders, especially forwarders, trying to get SPF right, can focus on the MAIL FROM in the envelope, they don’t need to touch the message. Senders including forwarders and mailing lists trying to get PRA right have to touch the message, that could be a legal issue between users and providers, it could also affect signatures covering the header.

    Historically, why PRA and MAIL FROM can be different is at least as old as RFC 822, while the forwarding problem hitting both SPF and SenderID is "only" as old as RFC 1123. For what’s it worth SPF can claim that’s a bug, but justifying PRA historically would be hard.

Skip to main content