Terry Zink's Cyber Security Blog

Discussing Internet security in (mostly) plain English

The problem of backscatter part 10 - Use SPF

The problem of backscatter part 10 - Use SPF

  • Comments 3

Using content analysis is one trick you can use to stop backscatter.  Another is to use SPF records.

SPF records are designed to help combat backscatter on the theory that the recipient mail server will be able to figure out that your server didn't send it.  Here's how it works:

  1. Bob has his own mail server and creates an SPF record for the domain bobsdomain.com:

    v=spf1  ip4:256.18.19.0/24   -all

    Properly interpreted, this means that any message that comes "from" bobsdomain.com must originate from the IP range 256.18.19.0-256.18.19.255.

  2. Jerk Q. Spammer sends a message to my mail-protected-domain, tzink99@example.com and says it is from my other domain, tzink99@example.org; he spoofs the sender.  But, tzink99@example.com doesn't exist.  My mail server can't do the recipient lookup in real time so it has to 250 accept the body contents of the message.

  3. Upon trying to deliver the message, my mail server figures out that tzink99@example.com doesn't exist.  In a normal world, my mail server would send a message back to tzink99@example.org (with null sender <> in the MAIL FROM) with a 5xx level error indicating that the message could not be delivered.

    However, my mail server is smarter than that.  When it accepted the message, it did some spam filtering.  It saw that the sending IP for the message was 288.41.18.19.  It then looked up the SPF record for example.com and saw it was 256.18.19.0/24.  It determines that the sending IP is not in the SPF range for the domain in the MAIL FROM.  My mail server sees that any mail coming from example.org that fails the SPF check has a hard fail, -all.  It assumes that the message is spoofed/forged and decides not to send an NDR back to tzink99@example.org, the purported sender.  Instead, it simply drops the message.  No backscatter is sent back to me thus helping to solve (ie, not contribute to) the problem of backscatter.

So, SPF records are a way of not contributing to the SPF problem, but it is entirely dependent upon the recipient MTA.  The recipient MTA must perform an SPF check on the message and then decide to not take its normal course of action on non-deliverable mail.  Thus, logic must be built into the MTA to do custom actions depending on the authentication results.

Not every MTA will do this.  SPF checks require DNS queries which are somewhat computationally expensive.  It is quicker and easier to simply check to see if the message can be delivered and then take action, rather than check, verify and then take action after that.  Still, using an SPF record with a -all in it means that you have given receiving MTAs the help they need in order to determine whether or not you actually sent the message.  Whether or not they use this information is up to them.

Leave a Comment
  • Please add 4 and 6 and type the answer here:
  • Post
  • PingBack from http://wordnew.acne-reveiw.info/?p=8691

  • Actually you should simply reject the SPF FAIL at your border and be done with it. Figuring out what to do if that was a legit mail (no spam), e.g., forwarded to you by a third party, or if the SPF policy is simply wrong, is the problem of the sender.

    As soon as you accepted an SPF FAIL it is your problem, making the RFC 2821 dilemma painfully obvious: You can't bounce, most likely it is spam, confirmed by the FAIL. But maybe it wasn't, and then discarding a legit mail is "not optimal", putting it mildly.

  • What happens when you don't have a spf record.  The company that has our DNS record doesn't support the spf record.  But I have emails that seem to be bouncing consistently to hotmail.com and msn.com and can't seem to get past this issue.

    What is your suggestion?  Should I just move my domain to another company that supports spf records?

Page 1 of 1 (3 items)