SPF is merely one component in a balanced anti-spam strategy. It may help some; it may hurt others. SPF tries to break as few eggs as it can by providing a range of conformance levels. Many people believe that SPF is a strong solution because it helps many while hurting few.

The Traveling Mailman Problem.

(From John Levine:) The social problem with designated sender is that there are plenty of perfectly legitimate reasons for mail from a domain to originate someplace other than its home network. Lots of people maintain accounts at Yahoo or other free mail providers, but send mail with their Yahoo address from their home ISP using the ISP's mail server.

SPF solves the problem by allowing ISPs to make exceptions on a per-user basis using the Exists mechanism.

ISPs can solve the problem by offering SASL. Users can log in to the home mail server even when they're travelling. All modern MUAs support SASL authentication, and all up-to-date ISPs support it on the server end.

What about in a cybercafe?

Forwarding and Return-Path.

(From John Levine:) Many others use forwarding services such as pobox.com, which would all be unable to function with designated sender, since mail forwarded by such services correctly retains the original sender's address, not the forwarding service's.

The envelope sender address is also commonly referred to as a return-path: if the mail is undeliverable, it's returned to the envelope sender address. So there are actually two issues here.

First, if customers really want to use their Pobox address in their envelope "from", they will have to send it through Pobox. Will users do this? Yes. Will Pobox let them? Yes. Customers are welcome to send mail through our authenticated sasl.smtp.pobox.com server.

ISPs who set up this kind of architecture will be responsible for rate-limiting outbound mail to ensure their customers aren't inadvertently sending spam. All ISPs should be doing this by now anyway.

Second, to handle bounces, I propose a rewriting scheme as follows:

  joe@aol.com -> meng@pobox.com -> mengwong@seas.upenn.edu

  joe@aol.com -> meng@pobox.com
    from = joe@aol.com
    rcpt = meng@pobox.com

  meng@pobox.com -> mengwong@seas.upenn.edu
    from = bounce=joe#aol.com=meng@pobox.com
    rcpt = meng@seas.upenn.edu

If seas.upenn.edu refuses the message, the bounce goes back to pobox.com, which decodes the specially formatted localpart and reinjects a bounce message to joe@aol.com for meng@pobox.com including the original bounce as an attachment.

If the message is forwarded multiple times, the localpart can be escaped and/or extended as necessary.

If there is a standard for bounce "layering", each layer of forwarding adds one email address.

  joe@aol.com -> meng1@pobox.com -> meng2@bigfoot.com -> meng3@myrealbox.com

  from = bounce=joe#aol.com=meng1#pobox.com=meng2#bigfoot.com@bouncer.bigfoot.com
  rcpt = meng@myrealbox.com

SRS is one such proposed standard.

It's interesting to note that this is a degenerate version of source routing which was deprecated years ago.

Conscientious Objectors.

(From John Levine:) And finally, this won't really block any significant amount of spam, since there will always be some domains who out of political principle, malice, or incompetence designate the entire Internet as their valid sender ranges, and spammers can just use those.

Domains that refuse to publish SPF or publish global-allow SPF out of political principle, malice, or incompetence will simply have to accept the penalty of a higher spam score. My fifty megs of spam a month outweighs your one curmudgeonly tirade.

Domains who do this are the same domains who run open relays. They have deliberately chosen to go against the flow, and I can deliberately choose not to accept mail from them. I respect toad.com for taking a principled stand, and I hope they will publish an SPF "allow" record for the same reason they're an open relay.

Just because a thing has always been that way doesn't mean it has any inherent merit. If SPF had been part of SMTP and DNS from the very beginning, the position of these conscientious objectors would suddenly just look like sloth.

What do the customers want? They want to communicate with their friends and family; and they want to not get spam. They do not particularly care if a few eggs are broken along the way.

Throwaway Domains

(From John Levine:) Or spammers can register throwaway domains of their own, since burning an $8 domain for a 10 million message spam run isn't much of a deterrent.

Throwaway domains can be listed in sender blacklists which respond in real time to automated discovery methods.

SPF needs to work in hand with reputation schemes.

There are many possibilities. The reputation scheme most familiar to people is the DNSBL, which blacklists IP addresses. RHSBLs are the analogue for domain names. A number of them are listed at the bottom of Blacklists Compared.

    % dnsip yahoo.com.spamdomains.blackholes.easynet.nl

    % dnsip amazingoffersdirect.net.spamdomains.blackholes.easynet.nl
    127.0.0.2
    %

Greylisting is another approach. It is elegantly simple, but it has three disadvantages.

1. People don't like to have to wait for real mail. After a while your users will say, "why is mail from my mom always getting delayed by an hour?" and you'll have to whitelist all your users' moms.
2. You need to do custom whitelisting for entire domains, because Yahoo Groups does not respect transient failure errors --- it treats them as permanent.
3. It is trivial for spammers to get around greylisting, because spammers don't actually queue messages; everything's just an entry in a database. Spammers aren't stupid. They can just repeat the run. Until they figure this out, greylisting will work.

Some suggest that reputation schemes would eventually be a lot like credit rating agencies: they don't say "yes, approve this loan"; instead they tell you what an individual's credit risk is, and it's up to the bank to decide.

Similarly a reputation service would provide a spam vs total ratio: (numbers are made up)

   domain: yahoo.com
   born:   199501
   total:  4.3E12 messages
   spam:   1.2E3 messages
   ratio:  2.8E-10

   domain: superspammer.net
   born:   200303
   total:  6.3E7 messages
   spam:   3.4E7 messages
   ratio:  0.53

Of course those numbers would have to be based on SPF-verified domains. There would be three types of domains--- SPF, "best-guess-match", and non-SPF publishers. "Best-guess-match" means the domain would have passed SPF tests if it had declared "a mx ptr" mechanisms. But that's a small detail.

Any major ISP could track these stats pretty easily and build their own reputation system. Or non-ISP organizations like Cloudmark could too. I expect The Internet will come up with a good, free one that's built right into MTAs like Postfix and Sendmail.

The algo would work something like this:

If the sender domain is known to the reputation system, we can make the decision based on local policy. (Local to the domain, or even to the individual user.)

If we don't have a lot of data on the sender domain, (eg. maybe the domain hasn't been around very long) we can do greylisting for the first pass; if our reputation service has good response times, we can expect it to have an answer ready the second time the sender tries. Or we can accept the mail but content-filter it, then report the results to a reputation system.

Obviously we need to introduce expiry and all that other stuff, but that's the basic idea.

And it would become an accepted social standard that if your domain hasn't been on the Internet very long, you wouldn't expect your mail to get through to people right away.

There's lots of research going on in the reputation systems space. It doesn't seem to be a fundamentally hard problem.

Other Objections

This section provides a list of web pages that comment on or oppose SPF.

• SPF is harmful. Adopt it.