Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Spam The Internet

SPF Design Frozen 105

Posted by timothy from the are-we-acquainted dept.
Eric S. Smith writes "SPF, previously mentioned here, is a step closer to becoming a real, live RFC. We are encouraged to publish SPF records and thus to hasten the beginning of the end for annoying spam forgeries. SPF describes DNS TXT records that define the hosts authorized to send mail on behalf of users in your domain. Sites can then consult your SPF records and reject spam forged to look like it comes from you." (SPF stands for "Sender Permitted From.")
This discussion has been archived. No new comments can be posted.

SPF Design Frozen More

SPF Design Frozen

Comments Filter:

  • Semi offtopic, but... (Score:3, Interesting)

    by Kethinov ( 636034 ) on Tuesday December 16, 2003 @12:41AM (#7731877) Homepage Journal
    I've always wondered how a spam filter system based on authorization might work. Your mail server could automatically send out a verification request to the email address that sent the email, then if the email address exists, an authorization would be sent back to your mail server. All mails that weren't confirmed by a returned authorization could be automatically deleted. This way, you could only get mail from active email addresses. Could cut down on email spoofing because anyone spamming you would have to use a real email address which would allow you to complain to the domain owner. Of course, all mail servers in the world would have to be upgraded to this new protocall for it to work, or everything would be considered spam.

    Does any of this make sense?
    • I was thinking that something like this would be a great idea... sort of an automatic whitelist.

      And then it occured to me that spammers would probably find some devious way to use this feature to generate lists of valid email addresses. Rather than sending a zillion emails based on a dictionary attack, they could send a zillion emails to known good addresses.

      Unless all the email servers in the world worked on the new protocol all the servers with the validation functionality would be MORE vunerable to s

    • Not really. Spammers have already forged my email address in the from line. You can check with my mail server, but my email address exists so it will report good.

      Don't suggest that hashes of emails sent be saved, while it could be done, my ISP for email is from years ago, everything else is done though a different ISP, including sending email. Basicly you can ask my ISP if I sent something, but they have no way of knowing if I did because none of my outgoing email goes though them.

      • Yes, but under the new protocall, it would be impossible to forge an email address because the email address sending the mail would have to be able to recieve mail in order to send or it would be automatically deleted.

        • Instead of impossible, you might more accurately write ineffective only in delivering messages only to servers which perform this check. Spammers don't particularly care about bounces and forged headers now. This scheme would only be effective if almost everyone switched to it.

          • I agree, but if everyone did switch to it, it would virtually stop all spam. Anyone who did spam you could be positively ID'd based on what domain they came form and a complaint could be filed against that domain name. Wouldn't be perfect but it would be a hell of a lot better than the way things are now.

    • Re:Semi offtopic, but... (Score:1, Informative)

      by Anonymous Coward
      SMTP contains a VRFY command to check the validity of an email address. You could connect to the sender's SMTP server and use VRFY to check the validity. Except that the command is often disabled, apparently because spammers used it to collect valid addresses.

      Could cut down on email spoofing because anyone spamming you would have to use a real email address which would allow you to complain to the domain owner.

      It wouldn't cut down on spoofing - a spammer would just need to spoof a valid address, which
      • The whole concept is based on a mechanism deciding whether ip X is or is not permitted to send mail from address Y, so this will indeed cut down on spoofing.
        Read the article ;)
    • Its called Challenge Response, and there is plenty of documentation on why this is a really bad idea.
      Just hunt it down in google
      • And plenty of people who are using it quite happily. See EarthLink's SpamBlocker for a related approach that uses a kind of challenge to help the user populate his whitelist / address book.

        There's always plenty of documentation on why something is a really bad idea. "'Considered Harmful' Considered Harmful". I clean out my spam folder once a week or more, and haven't found fewer than 1000 messages in it, usually 2000, for as long as I can remember. These are desperate times.
    • Are you suggesting this in concert with SPF? If not, then spammers would just forge the mail as being from a valid address.
      What you describe sounds sort of like a challenge-response system (http://tmda.net), but more automated. The trouble with that is the same trouble with VRFY. That is, it can be used to determine whether an address is valid or not for future spam attacks. That's called RCPT harvesting.

      My brother runs thille.com using sendmail and he didn't disable VRFY. Nearly all the accounts on t
    • I've been spoofed a several times (a spammer put MY email address in the reply box of their message.) If anyone replied to the spam message it came to me (along with the 1,000s of auto-replies "message can not be delivered to xxx address" etc.) It was absolutely horrible. If an authorization system was used, spammers may just select an actual address at random from their spam lists and put it in the reply to trick the system. I wish Gonorrhea upon all spammers. -C

  • I like it, but.... (Score:4, Insightful)

    by hawkbug ( 94280 ) <psxNO@SPAMfimble.com> on Tuesday December 16, 2003 @12:47AM (#7731901) Homepage
    This is a great idea. I'm all in favor of it. I would update my companies DNS to this new standard immediately. But, I envision these issues, correct me if I'm wrong:

    1) Increased network traffic at all points - where one mail server gets the email, and the network of the domain being sent from or forged. Imagine how this might increase AOL's or hotmail's network traffic, while they gain nothing from it. Every mail server in the world could be trying to contact their dns servers to check if they allow the mail. I hope you like lag if you use AOL.

    2) Spammers tend to use made up domains anyways. This is bad with this method for several reasons. The first being that you will have delayed email receiving times because your mail server will be trying to contact dns servers that don't exist. The timeout would have to be short for this to work.... then on the other hand, if the timeout is too short, and a busy mail server can't respond in time, the email is rejected, which is just as bad as a real email getting flagged as spam, aka a false positive.

    While I agree in practice with this technology, I'd like to see how people can solve these issues before I would use it at my company.

    • Internet does not work that way (Score:4, Informative)

      by bluGill ( 862 ) on Tuesday December 16, 2003 @01:02AM (#7731973)

      Your points are both invalid.

      1) Most mail servers already to a return DNS lookup on the IP of who the sender is. (The recived from lines in the headers) DNS takes so little bandwidth compared to normal activity (even compared to the payload of the email it is tiny, not consider all the web browsing, DNS is trivial)

      2)DNS works by asking the root servers who owns a domain. The root servers respond either with the DNS for the domain, or with a no such domain. (Ever hear of Verisign's sitefinder? Verisign runs the root servers, and they started saying anything unowned belonged to them) Essentially no overhead is involved in this.

      • "1) Most mail servers already to a return DNS lookup on the IP of who the sender is. (The recived from lines in the headers) DNS takes so little bandwidth compared to normal activity (even compared to the payload of the email it is tiny, not consider all the web browsing, DNS is trivial)"

        I realize dns is not a major network usuage offender, but more traffic is more traffic - I'm not saying it would be enough of a reason to not do it. I'm all about killing spam as soon as possible. If this helps, I'm all
        • Yes, I have heard of Verisigns dirty tactics. What don't understand is how the root servers can return the DNS, when I change ours constantly, and I don't allow domain transfers to root servers... I allow transfers to specific dns server, so do root servers get a transfer by default? I assumed that if a domain name exists, the dns request is passed onto the authorative dns server... is this incorrect?"

          Yes, that is incorrect. The root DNS servers hold the DNS glue records for each registered domain. DN

          • Ok, so what I'm saying is that the MX records will have to get pulled from my dns servers, correct? If so, wouldn't the SPF records also be pulled from my local dns?? If so, then that will equal greater traffic on my network.
            • correct, but that wasn't a response to the increased traffic point. you originally made a point (an incorrect one) about domains that do not exist. you said that, for this to work, a receiving mail server would have to contact a nonexistant domain, and have some sort of timeout after which it decides the domain doesn't exist. you went on to say that the timeout would have to be short to decrease lag in mail delivery, but if a server is overloaded, it may miss the timeout, and a legitimate mail would be d
              • No, I was talking exactly about what I was responding to:

                "Yes, that is incorrect. The root DNS servers hold the DNS glue records for each registered domain. DNS glue records are the NS records created from the DNS server information you specified when you registered the domain. So, you may be changing A, PTR, and CNAME records all you want, but the DNS glue records for your domain don't change unless you make a change with your domain registrar."

                I'm not an idiot - I realize that the root servers registe

            • If your network cannot handle the additional load from this DNS extnetion then you have bigger problems than this extention. DNS is such a tiny amount of traffic, even after this is implimented that it won't appear on your statistics.

              You can't do a DOS attack on DNS with email in this way, because DNS is caching. If someone is spamming your domain all over, DNS servers will remember after the first time what you returned last time and just return the cached result. (Unless you have rediculiously low tim

      • Also don't forget that DNS caches, so SPF data for popular domains would be cached all over the Internet. Your local DNS server would only make one query to the authoritative server every ttl period.

    • Re:I like it, but.... (Score:4, Insightful)

      by eakerin ( 633954 ) on Tuesday December 16, 2003 @01:15AM (#7732037) Homepage
      1) this shouldn't generate that much traffic, it's only one (or possibly more, depending on how you have it setup) query per domain, most likely the information will be cached as well (depening on the TTL set).

      2) Most mailservers don't accept mail from domains that don't exist (eg, they already query the DNS servers of the domain in question) and since the timeout for a DNS response is rather short, it shouldn't affect mail receipt that much.

      Actually the whole thing could be handled in 1 query, just look up the SPF record for the domain in question, if it comes up with NXDOMAIN, that domain didn't exist in the first place. if it didn't fail, but didn't find the SPF record, then we try TXT, if that dosn't show up, then we just allow the mail through.

      if a mailserver has a problem accepting mail it also returns an error message, basically telling the remote server to try later, or another mailserver. so no mail is lost (unless the servers remain loaded down and un-responsive for about a day)

      Oh, and I've already setup the record for my domain, and I'll be updating my MTA to query them soon!

    • Re:I like it, but.... (Score:3, Insightful)

      by Piquan ( 49943 )

      1) Increased network traffic at all points

      I expect that after SPF gets into wide usage, that spammers will no longer forge from those domains. So by adding SPF records for your domain, you lower the spam bounces and joe-job BS that you get. Besides, a DNS query is cheap, much cheaper than an email, particularly since it can be cached. And you are using your ISP as a cache, right?

      Worst case, no caching, you add about 400 bytes of traffic per email. That's nothing; the rest of the traffic involved in s

      • " 2) Spammers tend to use made up domains anyways.

        Not in my experience, not anymore. Many MTAs will, by default, bounce mail that doesn't come from a genuine domain. So spammers use real domains, or real email addresses. "

        Well, most of my spam comes from forged domains which don't exist, usually with a few constants here and there with a bunch of numbers thrown in.

        " The timeout would have to be short for this to work....

        Why? If you're waiting for a response, you're not burning CPU. The timeout can be
        • Well, most of my spam comes from forged domains which don't exist, usually with a few constants here and there with a bunch of numbers thrown in.

          Then your mail server needs to be reconfigured. There is absolutely no point in accepting email from bogus domains. I've never used a mail server that did so.

          In my business, deferred email, even 4 hours, is just as bad as not getting it most of the time. Email is a benefit to our business because it's instant. So, delaying it for hours is a bad thing for us.
    • Imagine how this might increase AOL's or hotmail's network traffic, while they gain nothing from it.

      Well, they do gain, actually -- if the plan works, it will blot out quite a lot of spam. AOL and Hotmail spend an astronomical amount of money dealing with spam in the current situation (it doesn't help that lots of spammers forge AOL or hotmail return addresses... I'm sure those bounces crank out the bandwidth required). If they need to pay for more bandwidth and more servers to support SPF, I have to im
    • I work at a free email service and we get on average dozens of spam complaints a day. Unfortunately, NONE of these spams originate from our service-- we just happen to be spoofed very frequently by one or more spammers.

      That's at least 20 emails a day I have to sit down and respond to, educating users on how to read email headers. Then, on top of this, 99.9% of the spam we RECEIVE is from spoofed addresses--- THAT adds up to the hundreds of megabytes per day category.

      This system, even if it adds 400 bytes

  • Not helpful to me (Score:1, Interesting)

    by Anonymous Coward
    My main spam related problem is that I can't send mail from my residential IP to aol.com, rr.com, and some others. Will this provide such a great spam filter that those ISPs will stop blocking me ? I suspect not, because I suspect those people just want to force me to get a higher priced fixed IP. (I suspect RR doesn't care if I spam for a little side income, as long as I pay more and don't do it enough to cost them more than I am paying.)

    Besides my residential IP with its dyndns name, I maintain two ot

    • I use a couple of sendmail rules to relay mail to aol and hotmail through my ISP, and everything else goes directly. Maybe you could do something like that.

    • There are some places that block residential IPs... usually this is based on the reverse DNS (feed your IP in and try to get back a name) - it contains numbers like d22-164-99 or whatever. One solution is to set up your home server to send out through your ISP's server which should have a proper reverse DNS without so much numbers. Some smaller ISPs will allow you to set up "real names" for your reverse DNS, most will charge a small fee for this since they need to issue static (dedicated) ip address to do

    • Re:Not helpful to me (Score:1, Insightful)

      by Anonymous Coward
      > Come on, sell me on this

      Assuming SPF is successful, there would be less need for manually-created "residential" IP lists that ban you. It would all be automatically handled by your DNS provider. (However, this put an anti-spam burden on DynDNS etc)

      So this is the way out for you.

  • Adoption Rate (Score:4, Informative)

    by jhunsake ( 81920 ) on Tuesday December 16, 2003 @02:00AM (#7732255) Journal
    I know I'm going to put the SPF records in as soon as I get a chance, but these statistics aren't terribly optimistic so far:

    http://www.infinitepenguins.net/SPF/register.php [infinitepenguins.net]

    This system serves to monitor the take-up of SPF. So far, 274 domains with SPF records are known.
    As yet, only a count of registered domains is displayed; more analysis tools will appear once the number of domains increases.

    Of these:
    84 parse cleanly
    0 parse with warnings
    173 parse with errors
    17 are yet to be checked by this system
    • 84 parse cleanly
      173 parse with errors

      Although I'm not sure, I assume this is due to changes in the SPF format. I created my records many moons ago, and now I (nor the automated checking tools) don't even recognize the new format.

      With the freezing, the errors should be getting less soon.

    • 173 parse with errors

      Ahm, I've just added my domain, was easy to do with the SPF wizzard [pobox.com], you just answer the questions, and it tells you what to enter into you bind config files. (And even explains what it means you're adding). But then, going back to the checking tool [infinitepenguins.net] you mention, I get this:

      Domain: uea.org

      Record Found: "v=spf1 a a:co.uea.org include:cistron.nl -all"

      Errors: Malformed or truncated domain 'co.uea.org' in 'a' declaration in rule part 3 (a:co.uea.org)
      Malformed or truncated domain '

      • So I guess the checking tool is somewhat too strict (or the wizzard is sloppy.). explains the reported errors, though. I just checked your domain name again, and the registry now reports your SPF record as being correct. As I mentioned above, this registry is new and bugs are obviously still being fixed. If you have other problems, please let me know. (I'm not involved in the registery, but I might be able to answer your questions.)
      • The registry was only actually completed today; the parser wasn't fully operational before that (it was just online for testing).

        Unfortunately some of you caught the parser while it was buggy... it *should* be fine now.

        It's also correct that some of the records were produced before the standard was finalised. All these bugs should now be out of the system (I'm going to regret saying that)...
    • The registry was created only a few days ago and has doubled in size since I last checked. The SPF specifications were frozen only a week or so ago, and most of the parse errors are due to early adoptors not updating their records. The SPF libraries are now being updated to allow for some backwards compatibility, but I suspect that more of the records will just be fixed in the comming weeks.
    • That's just people who register in their database.

      I've published SPF records for >100K domains for my employer, and that's just one sample.

    • It's probably not obvious (see also: article on /.) but those stats are voluntary ones based on people that -might- have read the mailing list that -might- have put something into a web form.

      It is certainly not exhaustive.

    • Well, I looked into adding the TXT records to my domains, but register.com [register.com] doesn't provide a method for adding the TXT records if you use the domain manager tool.

      Soo... looks like they'll need to be prodded into adding that functionality to their DNS tool.

  • How does this reduce spam in any shape or form? (Score:4, Insightful)

    by onomatomania ( 598947 ) on Tuesday December 16, 2003 @02:31AM (#7732413)
    Okay, I am not trolling here, I'm serious. This plan will be moderately successful at preventing joe-jobs [catb.org] on unwitting victims. If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard, so this will never completely wipe out the possibility of joe-jobs. And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.

    But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header. They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control. In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.

    Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged." And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations. (They already do this when they're playing hosting tricks, to bounce you around from one host to another.)

    Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. Everyone has ranges of IP addresses that they won't accept mail from, and some very kind organizations have even maintained lists of "bad IP addresses", so you might expect a similar thing to happen with domain names. But all you have to do is look at the current state of blocklists and you'll know this doesn't buy you much. We already have blocklists, and they're riddled with problems. You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with example.org, you block example.org. You're always one step behind, while the spam piles up in your inbox. You might make the point that this inconveniences them, but you have to realize how many domains there are out there that are available for forging. The SPF-protected domains will be the vast minority of all domains for the forseeable future.

    So, in summary: This might be moderately effective at preventing joe-jobs. It will not make a significant change, however, until everyone on the face of the earth that's not a spammer both updates their DNS and updates their MTA software to check these records. The likelyhood of this happening any time soon is quite small. And even if this were to happen, the spammers would still be able to deliver piles and piles of garbage to your inbox though domains that they control. You're back to blocklisting, which we've had for quite some time now.

    So, I ask seriously, what does this do to combat spam that is really all that significant? I applaud any developments on the antispam frontier, but let's not get too carried away with visions of this somehow "plugging the insecure SMTP hole", or anything remotely resembling it.
    • I largely agree with you, but keep in mind that SPF uses DNS; we don't need every host on the planet to adopt it, only those organizations that run mail and DNS servers.

      The big ones (yahoo, hotmail) are on board already; that's going to put some fierce pressure on ISPs to use this.

    • Exactly (Score:3, Insightful)

      by 0x0d0a ( 568518 )
      From a security standpoint, this is a dumb idea. Really dumb. It's stupid, open to a ton of attacks, and does diddly about spam. However, it's probably going to get some popularity for the following reasons:

      * Folks hate spam, and will glom onto anything that claims to reduce it with the gullibility of a cancer victim being scammed by a faith healer.

      * It's easy for IT folks to implement. The CIO can say that he "implemented an initiative to reduce the most frequent user complaint, saving the company N
      • From a security standpoint, this is a dumb idea. Really dumb. It's stupid, open to a ton of attacks, and does diddly about spam.

        Could you back up those claims with facts?

        • Could you back up those claims with facts?

          Sure.

          First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is pois
      • Actually, whitelisting is even dumber than SPF and won't work. The other ideas are good, though.

        SPF was shot to ribbons on the IETF ASRG list, but obviously someone decided to go ahead with it anyway.
        • The parent says

          SPF was shot to ribbons on the IETF ASRG list...

          but offers no pointers to allegedly valid objections. Here are some [ietf.org] pointers [ietf.org] into the ASRG discussion. I didn't see any compelling criticisms of SPF there. The criticism [ietf.org] that SPF "is not a serious technical effort" is odd, given that an implementation exists.

          • Like whitelisting, SPF works for a while.

            Then the spammers build up a database of SPF information, and whenever they get access to a server to spam through, they make their software use one of the correct SPF-allowed domains for that server, to generate the fake From: addresses.

            e.g. they 0wn 1000 Windows boxes of Comcast users, so they look up the SPF info from Comcast's DNS records, and use those domains to generate the fake e-mail addresses when spamming using those 0wn3d boxes. When spamming via their
            • Yes, but in the world with SPF, under your scenario, Comsat will only publish it OWN smtp servers as allowed (the customer boxes will NOT be published as allowed); thus the owned boxes won't be authorised, and people like me will reject them outright; unless they relay via Comsats own servers (which hopefully causes Comsat to wake up and take notice that their smtp servers have a giant outbound spam issue from certain customers, who they can then block until they are fixed)
            • e.g. they 0wn 1000 Windows boxes of Comcast users, so they look up the SPF info from Comcast's DNS records, and use those domains to generate the fake e-mail addresses when spamming using those 0wn3d boxes. When spamming via their collection of open relays in China, they use SPF-valid From: addresses for those open relays.

              Uh, no... in a world with a high adoption rate of any reverse-MX solution (DRIP, DMP, SMTP+SPF, RMX), the spammer can only use a FROM: domain that is valid from the IP address of the 0w
        • Actually, whitelisting is even dumber than SPF and won't work. The other ideas are good, though. SPF was shot to ribbons on the IETF ASRG list, but obviously someone decided to go ahead with it anyway.

          The people doing the shooting down made no substantive arguments and instead engaged in a series of vitriolic personal attacks against the people making constructive proposals. Basically some folk who had a position in the anti-spam world wanted to make sure nothing challenged it.

          IETF is pretty much an i

        • Actually, whitelisting is even dumber than SPF and won't work.

          Used alone, it is extreme, though I know a number of people that happily use whitelisting in instant messaging environments.

          The biggest use of whitelisting, however, would likely be in conjunction with other solid antispam methods.
      • How did you ever get +4 insightful?? Your post has a lot of strong words and zero substance. You spend some time complaining about SPF without backing anything up. Then you offer some rather tired suggestions:

        Limit email amplification.

        Great. How? People have been trying to do this since the mid-90s with little success. Remember that amplification is a very valuable feature of email ("send this message to everybody in marketing").

        Require one of a number of pay or auth systems for email.

        Ha. The
        • See my comments to an earlier respondent to my post.
        • How did you ever get +4 insightful?? Your post has a lot of strong words and zero substance. You spend some time complaining about SPF without backing anything up.
          It's a troll. Intentionally inflammatory, knows he/she is wrong, just trying to provoke a response.
    • You don't need everyone on the planet, just enough so that you can start filtering or bouncing mail from non SPF domains.

    • I use SpamAssassin. The SPF record could be used to alter the score.

      Some people use RBLs with a time lag. SPF-passed mail could bypass the lag.

      It's another step.

    • Ok, so you think this won't work. What do *you* suggest be done in its stead? Although this is a minor step forward, the major steps forward (like, oh I don't know, requiring encrypted passwords (SPA) before a send, which is already available) seem to never take hold because of some downlevel client user whining about lack of access.

      Your argument regarding DNS entries that spammers control is valid, but weak in that *any* solution must allow a domain holder to still send mail. What it *does* do, is stuff
    • This is intended to plug a hole, that's all. It's not designed to solve the whole problem. Its a simply solution that makes existing technology better with little investment. Also I think you are underestimating the indirect effect it has. Look at your spam box, where do probably half of them say they come from? Hotmail and Yahoo right? You can't block Hotmail and Yahoo though because they have millions of legitimate users. With this type of system you are forcing them to use smaller and smaller doma
      • If yahoo and hotmail incorporate this and set it such that only the main/official SMTP servers can send out mail that is from yahoo.com or hotmail.com, then how many people is that going to screw over? (That's an actual question, not a rhetorical one.) I'd imagine there are probably lots of folks out there that set their From name in their mailer to their Yahoo or Hotmail address, but don't use the official SMTP servers. They would all be forced to stop using their email app and start using the webmail i
        • It's going to affect alot of people. Since spammers use the same mechanisms that normal people use anything that affects spammers is in some way going to affect normal users. The more similar a normal behavior is to a spam behavior, the more it will be affected, like the header "forging" you mention. While putting a legitimate address you own from a different domain is a legitimate thing to do, its indistinguable at the technical level from a spammer forging an address.

          This is an important thing however

    • If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard

      nice summary. SPF becomes useful long before everyone on the planet starts using it. In fact, once you get yahoo.com, aol.com, hotmail.com and a hundred other

    • Once any significant percentage of domains use it, we can just not accept mail from the domains that don't.
    • Okay, I am not trolling here, I'm serious.

      You raise some good points, I'll try to address some of them.

      SPF is not designed or intended to stop all forms of spam. In fact, I see SPF doing as much to protect people from phishing and joe-jobs as reducing spam. UBE is not the only form of email abuse.

      SPF gives domain name owners a voice to communicate which IP addresses, if any, are authorized to send email using the domain name. Anyone who wants to listen to what the domain owner has to say is free to

    • It's going to be a long road, and I think SPF is just a first step, but it's an important first step. I would describe it as "necessary but not sufficient" to stopping spam.

      Here's how I think things might go if everything works out.
      1. Some key large domains publish SPF, and a few large ISPs start checking for it.
      2. Some of the mail that is forged using the big names is downgraded or dropped.
      3. Spammers start to spoof the addresses of other names instead.
      4. Pressure is on for the owners of those other name

  • Will make filtering much easier (Score:3)

    by Micah ( 278 ) on Tuesday December 16, 2003 @04:31AM (#7732792) Homepage Journal
    Some people here have complained that this might not work because everyone on the planet would need to use it and even then spammers could use their own domains.

    Certainly it's true that nearly everyone will need to get on board for this to work. Fortunately, it should be an easy update on both the MTA and DNS ends.

    The real advantage here, I think, is that it will make filtering and blacklisting much easier. Instead of trying to filter on 18 zillion weird rules and scads of IP addresses, some of which may have some valid users, you just need to filter on domain names.

    For this to work, we will need one or more trustworthy registries of bad domain names. And it should probably be distributed, with a way to continually update it by automatically propagating the list of bad domains to all clients. There should be a way to get a domain into the blacklist very quickly if anyone receives spam from that domain.

    Alternatively, a system could be in place to treat all new domains as bad by default. That has obvious problems though -- how would you get your domain trusted? Would it require a VeriSign like identification process? I would oppose that -- I think people should be able to buy domains and freely run email servers on them without paying some central "authority."

    My biggest concern with this idea is that I run a domain where I give out POP email addresses to people. I'm still trying to figure out how that will affect me.

  • Ok - RFC ? I don't think soon (Score:3, Interesting)

    by MerlynEmrys67 ( 583469 ) on Tuesday December 16, 2003 @05:48AM (#7733020)
    This should become an informational RFC - it could be published within a month. As experimental - I don't see it surviving the IETF Last Call process. Way too many operational people that don't like mucking with DNS records - too man spammers that wouldn't like it.

    If they couldn't get consensus inside the IRTF's spam working group, what makes them think they can get it in the IETF community at large (I love the note to the RFC editor - HA)

    • More likely, one of the big ISPs (AOL, Yahoo) will require that you configure DNS records in order to send e-mail into their network. Initially (during the adoption period), they'll probably only use the information to score e-mails as being spammy/hammy. After the adoption period, they'll start using the information like a blackhole list and just drop the connections.

      The MTAs (postfix, sendmail) will probably implement one of the (4) solutions and admins will start using it by default.

      I doubt we'll s
  • My home ISP is SBC, and while they may let me send mail through mail.swbell.net, chances are that's not the name of the outward-facing ring of mail servers they have (I am assuming they actually built an enterprise-class mail service, of course, which is a lot to assume about SBC).

    How do I get all the names of their outward facing servers, which may not leave my original mail.swbell.net in headers as my first stop?

    Speaking of editing headers, what's to stop the Asian remailers from having their servers ge
    • After SBC implements SPF (good luck, SBC is a great company to work with;), you can bring up a terminal, and run something like 'dig TXT sbc.com' and copy their 'v=spf ...' record from there. This should provide an accurate description.

      I'm not quite sure what you're saying at the end there... A remailer will have to be on the SPF record for the domain they're trying to deliver for, yes, and they'll still get through fine, but if there is also a destributed blacklist system (or responsive DNS registrars
    • You can refer to your ISP in terms of "include=" (basically, this tells people checking your record that they should check SBC's record as well). You can add multiple includes for the ISPs you use.

      Regarding headers, SPF is able to drop the connection based only on the SMTP commands, before you have sent any headers. Headers are part of the DATA step in the transaction which is like 4th, MAIL FROM step is 2nd.

      If you're not adding it directly to the mail server, you can analyze headers after the fact, but
      • Oh, I see, now it makes sense - someone can't really pretend they're just passing on the mail from a legitimate host, because that legitimate host wouldn't relay through someone else without listing it. I guess that was obvious to everyone but me :)
        • Not to worry, smtp is naturally confusing -- it's designed that way :)

          Spammers definitely take great advantage of how confusing all those extra headers are, and the smtp transaction has a couple of steps to go through before the headers even arrive. Luckily most mail servers will record their part of the transaction, the HELO command is "received from", the Mail From is the Return Path, etc. But it's still kind of tortured.

  • Summary for mail & network admins (Score:4, Informative)

    by CrystalFalcon ( 233559 ) on Tuesday December 16, 2003 @08:22AM (#7733419) Homepage
    If your MX record is also the IP(s) used for outgoing mail, as in my case, all you have to do is add this line to your DNS:

    [domainname] IN TXT "v=spf1 +mx -all"
    That's it. That's really it, at least for publishing your permissions. So simple I already did it for my domains.
  • http://www.ietf.org/internet-drafts/draft-danisch- dns-rr-smtp-03.txt

    http://www.danisch.de/software/rmx/

  • MTAs should block mail where the FROM does not match the originating server (i.e. act like "v=spf1 a mx ptr -all"). SPF should be used to configure domains to extend this rule. If you have a weird setup, you could add an SPF record to allow additional hosts to send email on your behalf that are outside your domain.


    Without this default ("v=spf1 a mx ptr -all"), spammers will be able to find domains that don't use SPF.

  • SPF is too limited (Score:1, Insightful)

    by Anonymous Coward
    SPF is all well and good if you intend to have all of your users send mail through your short list of approved hosts. Some places can swing this. Good for them.

    I have run a vanity domain for myself and a handful of friends from high school since the mid 90s. They use their vanity accounts to get mail, since it forwards to wherever they happen to be now. I want them to be able to send mail as those accounts, but SPF won't let that happen.

    The SPF-approved answer is "have them relay through you with some
  • A lot of folks have commented that this won't do anything to reduce spam, because spammers will just register new domains and send from those.

    But, those new domains won't have any data in people's Bayesian corpus; they will be neutral in affecting spam probability scores.

    On the other hand, domains that publish SPF records will be protecting their domain names, which means that those domain name tokens in people's Bayesian corpuses will count positively towards the message not being spam.

    In other words, p
  • this requires too many levels of parsing and difficulty on the client. it also "tells too much", a better answer involves knowing the IP and the return-path and examining:

    1.0.0.10._spf.example.com

    for a "valid" record. existing RBL-publishing software can be used, existing RBL-scanning clients can be used, we won't need to set up DNS-over-TCP servers, and we don't give any information we don't have to.

    note, and this is very important. what we're looking for is what would better be called a "reverse MX"--
    • Early versions of SPF actually had reverse lookups like 1.0.0.10._spf.example.com. I actually like the new TXT format better since it is more flexible and easier to write for most domains.

      There is a careful tradeoff between "too simple" and "too complex". I have seen other similar proposals doomed by getting too complex, because they bow to what the users want and then nobody wants to write the code. At the same time I have seen proposals doomed because they were not flexible enough to handle most cases
      • statements like that, "v=spf1 +mx +ptr +include:rr.com -all" are dangerous- they add extra complexity to the client which is EXACTLY where we don't need complexity- and they're difficult to be correct. How do you know you didn't accidentally type "... +include:. rr.com -all" -- that's as good as nothing, and isn't that easy to spot.
  • A lot of spam is supposedly coming from compromised hosts. Those systems will probably have a SMTP server on the local network that can be used. It is probably even already configured with the configuration easily found (outlook/mozilla/etc?). So, the software, instead of running it's own SMTP server, looks up the configured one and uses that, with a made-up account name on that server.

    You still get the spam, it even looks more authentic!

    Jason
  • But didn't Coppertone standardized SPF over 20 years ago?!
    • No, SPF has a different meaning in that context. SPF = Sun Protection Factor, iirc.

      This SPF is different. Since spam and sunblock are NOT related, no one is gonna confuse the two SPFs.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close