Sender Policy Framework -- Opinions?

Hey Hey,

A client that I do some consulting work for recently approached me asking abput SPF (Sender Policy Framework)...

I ran a search and there's brief mention of it in some threads but I didn't spot a major discussion on it (although I'm sure as soon as I post this, there will be one in related threads..)..

I've never used it, nor have I seen it before... but it seems a little sketchy to me. There's no mention of what SPF does if there's no "reverse MX" entry in DNS and with the way some of his clients are, this isn't something we want to be finding out while in production.

They claim that they're saving you from a "bad name" but in reality anyone that's worth listening to is going to take one look at the IP Address and realize that it didn't actually come from you... I've also seen a bunch of sites that are Anti SPF...

I can see upsides and downsides and I'm curious as to who is using it and who refuses to and what their opinions of it are. The site looks like one of those catch your eye, unload a lot of BS sites so I'm really confused as to what to recommend.

I'll be out of town until Sunday night but I'll check in then. Thanks in Advance.

Peace,
HT

HT:

SPF is cool. A simple text record in DNS allows you to tell other mail servers which IP addresses are allowed to send mail on behalf of your domain name. The record also gives information about whether these IP's are "fixed in stone" or whether others might, (mobile users using other ISP but sending under their work email for example).

On the receiving end you need something to query the SPF record. I use GFI MailEssentials but there are a few others out there. You set up your rule as to high, medium or low and whether to flag, redirect or delete. To start with I set mine at medium which says "If the remote domain says that the addresses are fixed and the email came from elsewhere fail the mail", known as a "hard fail". Setting it to high brings in the "soft fails" which is the same as the hard fail except the remote server doesn't fix the IP's in stone.

My experince with it over the last 8 months? I like it. I have it soft fail and redirect everything. I get maybe 1 FP in a thousand, but your mileage may vary, and it blocks about 15-20% of all the blocked spam to my domain. Most of the big players such as AOL, MSN etc. have SPF records so it does pretty well. If it were mandated then we could catch much more by taking the stance that if there is no SPF record then fail the mail but that will take some time to accomplish. It would, however, eliminate the temporary and plainly forged domain names some spammers use.

Hi HTRegz I did have a quick look at this a little while back.

I could be wrong, but it struck me as one of those "nice theory but won't work in practice" things.

Take this machine for example, it can spew out spam at 2.2Mbps. That goes to my ISP who are registered as a bona fide mail sender (for example)..................that is going to get through as far as I understand things (OK I can be a bit thick at times, so please explain if I am wrong)

Now, there are millions of mail servers in the World that are not registered, and messages from them might represent serious business opportunities for your organisation, but this system will drop them?

Also, just because a server is registered it does not mean that it is not "owned" and sending spam?

Thus far I have tended to favour software that requires a human confirmation before sending e-mail. That is damn difficult to circumvent?

Just my £0.02 :)

We tested it for about a month. Our results weren't quite as good as ol' Tiger's and we found that the effectiveness we expected was not there. Now, we're a bunch of high expectation *****s over here so what may not work for us may work for others. To quantify this, we still saw a majority of the SPAM traffic come through and we had about 10 to 12 false positive hits in about 500 messages. We average about 100,000 emails a day so we're talkin 2,000 + false positives a day. No go in our shop.

Again, the idea is great but as Tiger points out, this would be much better if total adoption were achieved. This may come in the form of SDNS in the near future. For those who aren't in the know, take a peak at this:

http://www.bovine.net/~jlawson/hmc/dns/security.html

or this:

http://www.faqs.org/rfcs/rfc2065.html

We've moved on to other solutions in the mean time and we're battling in the trenches everyday just like the rest of you.

--TH13

Heya. I found this thread while looking for some other SPF info, and just thought I'd add my thoughts.

I think it's best if you first understand exactly what SPF does. It compares the purported sender of an email (the "from" address) with a list of allowed servers for that domain. If you get an email from [email protected], it checks with aol.com to see if the server that the message came from is an allowed server.

That's all it does. When an email says it's from a certain domain, it checks to see if it really came from a mail server for that domain. Without actually adding SPF or anything else, you can actually do a really basic check like this. Simply look up the MX record(s) for the domain, and compare that to the server that sent the email. The Sender Verification Extension for Thunderbird actually does this for domains that don't have SPF records. Some pre-SPF spam filters do this as well.

There are no downsides to implementing SPF, other than a few DNS queries. Well, that and making sure that you have the correct SPF entry to cover all your servers.

However, there are also no real benefits to you from implementing SPF for your domain (which is probably part of the reason it isn't more widely used). Adding SPF to your domain benefits people who receive mail from your domain (or mail that claims to be from your domain). When eBay or OnlineBank_01 add SPF records, that makes it very easy to tell that the phishing email from dsl1-2-3-4.dynamic.bigisp.com isn't actually from eBay.com or OnlineBank_01.com.

It doesn't really add anything new for geeks, who can pull the IP from the headers and figure out if it came from a legitimate server or not. It does let the sending domain specify a little better what is and isn't allowed, but that's about it. However, standardizing the SPF format allows a user to see (via a program on the mail server or in their email client) whether or not the email came from a valid IP, without having to know what an IP, MX, or email header is.

They're working on getting their own DNS record type, but for now it works just fine using a TXT record. That means that anyone with access to their domain's DNS can implement it. It doesn't require any major changes to any part of the email system. I've heard of two ways to "hack" SPF. The first is using two domains which include each other. When the recipient tries to check the SPF, it goes into a loop. That's easily fixed with some sanity checking and/or a simple timeout on the check to prevent a total DoS. The other involves DNS poisoning to return a different record. That's pretty involved for simply forging an email...

The SPF site has a script that will even accept the parameters to tell you about why an SPF decision was reached. http://spf.pobox.com/why.html?sender...recvdomain.com That can easily be included in any sort of bounce message to explain to the end user why an email was rejected. They don't have to try to get in touch with the domain's admin and figure out why it was blocked and how to go about fixing it. It's all pretty much self-explanatory.

invisibill.net really doesn't get forged that much. For me, universal adoption would mostly stop all the replies I get to viruses that "I sent". Since all the emails "from me" would be coming from sources that are not in my SPF record, it would be known immediately that they're not really from me.

It doesn't stop lookalike domains (paypa1.com, etc.) from creating SPF records that allow every single IP address. It doesn't do anything if the receiver doesn't actually check their incoming emails against SPF records. It doesn't really help you at all, unless spoofs using your domain are a big deal. It's mostly to help people receiving mail from your domain verify that it came from an allowed server.

Quote:

---

Originally posted here by nihil
Hi HTRegz I did have a quick look at this a little while back.

I could be wrong, but it struck me as one of those "nice theory but won't work in practice" things.

Take this machine for example, it can spew out spam at 2.2Mbps. That goes to my ISP who are registered as a bona fide mail sender (for example)..................that is going to get through as far as I understand things (OK I can be a bit thick at times, so please explain if I am wrong)

Now, there are millions of mail servers in the World that are not registered, and messages from them might represent serious business opportunities for your organisation, but this system will drop them?

Also, just because a server is registered it does not mean that it is not "owned" and sending spam?

Thus far I have tended to favour software that requires a human confirmation before sending e-mail. That is damn difficult to circumvent?

Just my £0.02 :)

---

SPF doesn't require you to register your server with some organization or anything. You simply have to specify what servers are allowed to send mail for your domain, in the domain's DNS records. The options available for the SPF record seem to work pretty well. One command can include all the domain's MXes, and there is a command to include other domains as well (you could include remailercompany.com if they send out all your newsletters for you).

In your example, your PC is sending mail through your ISP's mail server. If the "from" address is [email protected], then yes, all that mail coming from mail.myisp.net would pass SPF. SPF is doing exactly what it's supposed to - it's verifying that all this [email protected] mail is really coming from myisp.net. However, if it said it was from [email protected], it would look at aol.com's SPF record, and see that it's not coming from a valid AOL server. All of that would fail SPF.

However, most spamming is not done through the ISP's mail server, but from an SMTP server running on a zombie PC. In this case, even mail from [email protected] should be rejected. dsl1-2-3-4.dynamic.myisp.net should not be allowed in myisp.net's SPF record, because it's not really a valid myisp.net mail server.

There are several things to take into consideration when dealing with failed or unsupported SPF tests. The client does the checks, and determines exactly how failed tests are handled. Depending on how opposed to spam and forgeries you are, you could delete all mail that fails SPF. You could move the message to a different folder. You could simply specify the results in a header, and not affect message delivery at all. Since it's client-side, you have the final say in how it's handled, just like you can control what your own installation of SpamAssassin does with messages marked as spam.

In addition to that, SPF has a few different results. You can specify that anything not specifically allowed is forged and should be discarded (-all). You can say that all valid senders should be in the SPF record, but it's possible that something valid could come from somewhere else (~all). Or you could say that everything else may or may not be good (?all). As the system and programs develop further, you could do more complex things on the receiving end. Delete all the -all stuff automatically, move the ~all stuff to a different folder, and just put a header on ?all messages. However, all the processing is still done by the receiver, so you still have the final say over it. You could just as easily delete all fails, or allow all fails. SPF records may provide you with more info, but it's still up to you what you want to do with it.

Like I mentioned before, it won't stop servers with valid SPF (0wned servers or ones specifically set up with SPF to spam) from spamming you. It's not supposed to. SPF is only supposed to verify that a message came from a server for the domain that it says it's from. But since most spam is forged, SPF can stop a lot of spam. Again repeating what I said before, it should stop almost every single virus spam too, since Joe Random's IP address (the virus-infested PC) isn't going to be on your SPF record. Every single message from his PC that says it's from your email address will fail SPF.