Spoofed From: Prevention

An anonymous reader writes "It looks like the next promising advance in the war on spam is here! Introducing SPF: Sender Permitted From. A draft RFC is still being written, but the idea is simple: we can prevent forged emails by having domain owners publish a list of IP addresses authorized to send mail from their domain. It's no silver bullet, but how much spam can we eliminate by preventing forged mail from spoofed domains? Maybe we really don't need anti-spam legislation after all? The SPF site is chock-full of juicy info for our reading enjoyment. Bon appetit!" Interestingly, the to-do list mentions the possibility of seeking a defensive patent on this scheme, too.

Comments

great idea...

[AmigaAvenger]

Good idea, but the problem is the same as saying spam would go away if all the open relays were taken offline. In theory, it works great, in practice, there are admins who WANT spam moving...

Re:great idea...

[Anonymous Coward]

So here is an instresting question, can perhaps a option be put in to DNS requeries to ask a domain if its an authorized mail server. Requests would have to be non cached of course.

This poses a couple of problems. If a spammer starts spoofing email from a domain all over will this create a secondary DDoS by making massive requests on a legit host?

And assuming one were to piggy back it on DNS or some existing service, how would something like Verisign sitefinder fuck it up?

Re:great idea...

[Pharmboy]

pray, what might be the reasons for admins to have spam moving? To increase their job security?


If the spammers are your customers, you want to keep spam moving. This system may help us see who is the good guys and who is not.

Re:great idea...

[gregmac]

pray, what might be the reasons for admins to have spam moving? To increase their job security?

The same reasons that top-teir backbone providers are totally unwilling to help block spam. If a spammer buys some bandwidth from some ISP, and starts sending GB's of spam, that ISP gets lots of money. For the top-teirs, they get to charge for the spam coming across their pipes (both the people sending and the people reciving). They get to charge more when half of the emails bounce.

An admin of an individual server/company wouldn't necessiarily want spam moving, but the tertiary people (ie, the bandwidth providers and ISPs), in addition to the spammers or the people they're spamming for, are making money.

But *everyone* would have to do it

[doomdog]

if you wanted this to succeed -- otherwise, you'd end up blocking mail from those domains that hadn't upgraded yet to the new techology... What are the chances of everyone upgrading at the same time? And how much mail would be lost during the transition?

There's another problem this could help with.

[rock_climbing_guy]

Although I would agree with the posters that this will not solve the problem of people who own a domain that they want spam sent from, let me point out something else.

Perhaps this could stop spammers from spoofing the addresses of other internet users. However, I don't know if this will stop spammers from using whatever return address they want to regardless of what domain they send their spam from. Would it?

Re:There's another problem this could help with.

[bob_calder]

Maybe. If I put your email address on my spam, it would come back as good if someone queried your mail server. Your mail server would have to keep track of what it sent in order to validate properly.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:RMX?

[wayne]

I have looked at quite a few of the various "designated sender" systems, and I think that the SPF system is by far the best thought out system. There is a reasonable good comparison of SPF vs RMX vs DMP available on the SPF website.

Basically, RMX has to critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it. Secondly, there is a limit to how many resource records can be sent in a UDP packet and many important ISPs such as AOL, MSN, Yahoo, etc., have far to many. If I recall correctly, there are several thousand(!) IP addresses that Yahoo will send email from.

Re:I don't like that idea.

[jhealy1024]

You're screwed already anyway....

Many large ISPs (such as AOL) have already started filtering mail based on the IP of the relaying server. So if your SMTP server talks directly to AOL, then AOL may reject your mail simply because you're *likely* to be a spammer relay (even though you're not).

Meanwhile, cable companies like Cox have already implemented a total blackhole on *outgoing* SMTP. Not only is this annoying for people who run servers, but it also sucks for those of us with POP/IMAP accounts... if I'm connected from home I have to set my outgoing SMTP to Cox, and when I come in to work I have to flip it back to my company's mail server. (I've since set up an automatic ssh tunnel to get around Cox, but the average joe has no hope of doing that for themselves.)

Either way, this new idea isn't going to make sending mail from your own domain any harder than the cable companies are going to make it anyway...

A better idea?

[Vyce]

Wouldn't it be better to implement something in DNS that sets the ips to be used....Maybe call it an RX record put it in for the @ record of your domain. @ RX 127.0.0.1-254 RX ..... CRX smtp.someotherdomain.com. That way you can just poll bob.com and ask bob is whatever-dsl-address.goofyisp.com can really send mail as amazon.com or not. This is more extensible to people who have home-grown servers, as well as big companies. I mean, who doesn't know the outbound servers for their own domain? You could even couple this with some other check that looks up originating IPs and does a query back to the domain to see if they can send (as suggested in the above article).

Re:Another problem:

[qtp]

I am a bit wary of that patent mentioned in the ToDo.

and

I would be happier if he GPL'ed it.

There is no reason that he couldn't distribute this under the GPL even if he patented it.

The patent could be used as a method to could prevent a company from implementing an incompatible "one-off" that it distributed with it's own propietary, market dominating OS in order to prevent other systems from interoperating with it's email software when the feature is activated.

On the other hand there is the issue of software patents in general. Even if you intend no harm, or are actually using the patent system to protect the freedom of your implementation, you are also endorsing software patents that are being used in far less benign ways.

If that patent idea gets taken up, I can't see Debian including SPF; it'll be poison.

Once again, the existance of the patent does not dictate how the patent holder distributes or licenses the patented invention. If this developer is concerned that this be widely implemented and thus chooses the GPL or similar to license the invention, the patent could ensure that any subsequent inventions that are dependant on or derived from this one be distributed under a similar or compatible license.

Missing the point

[Ancil]

Look, if we could convince every sysadmin on the planet to upgrade their MTA's, we could just implement HashCash and be done with it. And this guy wants us to concurrently update all our DNS maps?

Interesting approach to the Essential Problem

[87C751]

That problem, of course, is how to authenticate the entry point into the mail transport system. When the relay sequence is carried in-band, as with SMTP, spoofing the entry point is trivial. But even imagining an advanced system, where routing records are carried out of band and all relay points mutually authenticate, locking down the entry point is still a hard problem. If nothing else, Sam Spammer simply impersonates a server that's passing in-transit messages and forges the upstream transit records. Unless mail is redefined to be passed only by persistent hosts, the system has to allow for previous transit points to be offline except when actually passing traffic. That means authenticating back upstream won't always be possible, thus obscuring the forged transit records.

Possibly, the system could require authentication all the way back to the message originator, but that implies some central repository of mail originator credentials (again, to allow for transient connections), which would have to be is-a-person credentials to be of any use in tracking and punishing spammers. Since TANSTAAFL, that means to send mail, you have to buy an admission pass for the network. That implies an infrastructure to issue and validate these credentials, as well as no provisions for unlinked mail nyms. Big Brother USPS, anyone?

Re:Interesting approach to the Essential Problem

[pjrc]

I believe you have not understood how SPF works.

Sam Spammer simply impersonates a server that's passing in-transit messages and forges the upstream transit records.

Sam is going to have a very difficult time spoofing an IP address that is authorized for the sender address, because TCP requires at least one packet to travel from the destination back to the Sam Spammer before the TCP session is even established.

Spoofing the DNS lookup the SPF uses is probably a weaker path, but also quite difficult for a spammer to do. No spammers are going to be able to sustain compromised hosts that can spoof the lookups.

Unless mail is redefined to be passed only by persistent hosts, the system has to allow for previous transit points to be offline except when actually passing traffic. That means authenticating back upstream won't always be possible, thus obscuring the forged transit records.

Consider the common case where a spammer intends to forge a message to appear to have been from someuser@yahoo.com. All that is necessary is for Yahoo's DNS server to be responding when the receiving MTA sends a query to see if the connecting IP number is really one of Yahoo's servers.

Yes, you are correct that the receiving MTA must handle the case where Yahoo's DNS servers are down, or don't return a SPF response. But in that event, the message is received as it normally would have been without SPF.

All internet protocols must somehow deal with the possibility that a remote host is down. This is very easy with SPF. Arguing that "well, a website may be down" hardly translates into "http is a not a good protocol".

Re:What about IP address Spoofing?

[Anonymous Coward]

Works for UDP, not so simple for TCP.
Put someone else's IP in a TCP from when you first connect and the server sends a SYN/ACK packet to that IP. When it gets an RST packet from that host, it drops the connection.
Put someone else's IP in a TCP from after you've connected and the server will drop the packet on the spot because it doesn't have a socket allocated to that connection.
Last time I checked, SMTP ran over TCP.

To spoof the from IP in TCP, you also need to be able to:
1: launch a successful DOS attack against the machine you're spoofing
2: be able to predict TCP sequence numbers coming out of the server (embedded in that SYN/ACK packet) to a reasonable degree of certainty, so that you can guess them in the time that the host you're DOSing in 1 remains down.
All this is significantly more involved than simply forging from: headers.

Re:Uhh... another version of RMX?

[jefflindl]

I actually have been using shadango.com for the last three months (I heard about it from /. of all places) and I must admit its spam protection (they use spamassassin) has been solid ever since I started using it. In addition to the protection their spam guard affords me, it also allows me to check both my hotmail and my school account from one interface.

I'm not saying services like this are a solution to the spam monger, but a service that applies both spamassassin and RMX checks is taking a step in the right direction and it's definitely worth checking out!

Shadango.com gets my vote!

Jeff Lindl

This can already be done

[SuperBanana]

It's one possible way to deal with one particular aspect of the problem: forging From addresses will become harder.

...something that can already be done with Postfix and other mailers. It's very simple. Postfix can check to see if the hostname you claim to be from matches your IP. It can also check to see if the IP reverses to the hostname you claimed(this one is not as wise, as there are perfectly valid reasons for not having a reverse entry, although you -should- have one). Further, Postfix can return not-authorized if you try and give a MAIL FROM address which doesn't match your domain; ie, if you're coming from a01.nastyspammer.com, you're not going to be able to say "MAIL FROM: niceguy@yahoo.com". It is -incredibly- effective against blocking spam, but the problem is that many ISPs and company just don't have properly configured mail servers, or hostnames set up for their mail servers(an even more common mistake is for the hostname to not match the name reported by the connecting server in the HELO command- most often Exchange servers). This would change quickly if more people configured their mail servers to block such shenanigans.

Right now that RFC seems a)unnecessary and b)like a very thinly veiled attempt by ISPs to prevent their customers from running mailing lists and the like. I help run a VERY low budget mailing list that has about 3,000 subscribers in total, and we may end up using DSL again for connectivity. Said DSL provider could easily screw us over with this.

Re:This can already be done

[Robotech_Master]

And some of us have other reasons for spoofing our from addresses. For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me. It's neither my home Linux box, nor my local ISP. I keep it that way because I never know if I might need to change ISPs for some reasons, and that box is always up and always there. I use fetchmail to pull down my email.

But as a matter of course, I have mutt configured on my desktop box to send in the name of my halfway-across-the-country account, even though it sends through my ISP's SMTP server. (It used to send through my home Linux box's own SMTP server, but then a lot of addresses started bouncing it because it was on a list of cablemodem IPs.) How would I be able to continue doing this under such a system?

Re:This can already be done

[raju1kabir]

Postfix can check to see if the hostname you claim to be from matches your IP.
...
It is -incredibly- effective against blocking spam

It's also -incredibly- effective at blocking legitimate mail. Anyone who uses a single mail server to handle outbound mail only for more than one domain (and that's a LOT of people) can't mail you.

I cannot imagine anyone turning this on unless they really had no interest in receiving their email. I would guess that the way you describe it is not how it actually works.

Re:I don't like that idea.

[gregmac]

Meanwhile, cable companies like Cox have already implemented a total blackhole on *outgoing* SMTP. Not only is this annoying for people who run servers, but it also sucks for those of us with POP/IMAP accounts... if I'm connected from home I have to set my outgoing SMTP to Cox, and when I come in to work I have to flip it back to my company's mail server.

I've always thought that ISPs should add a default "smtp" zone for their customers that resolves to their mail server. That way, you can set your progarm up to use "smtp" and no matter where you are, it will resolve properly.

Now, as far as blocking port 25, I've always thought that was a great idea as well, until last week. Our office has used BellZinc's DSL for connectivity. A few months ago, our smtp suddenly stopped working, and after calling tech support, they told me they had accidentally left port 25 on one of their racks unblocked (and I happened to be on that rack) so they had fixed the situation. (Actually, I had to call twice to find that out, the first guy had no clue whatsoever).

So I switched the smtp server in the office to resolve to Bell's, and all was good. But we've had a few interruptions, espessially over the last couple weeks, where we couldn't send mail at all. After talking to tech, it turns out their mail server is being hammered by whatever virus-of-the-week was hitting windows, and was unusable. I was blown away by their lack of willing to help me: they wouldn't unblock port 25 for me (even to one specific IP), and they has no answers to "Well, what am I supposted to tell everyone in the office? No email for ... an unknown amount of time?"

Of course, I could have just set up my server to accept mail on another port, but that would have been a pain for me - local change on every client, instead of one SMTP fix. Anyways, as of Monday, we have a new ISP. (I won't get into how Bell tried to tell us we had a 1-year contract and wanted to charge us 4 extra months for breaking. They couldn't send us any proof, but apparently it was a "verbal" contract. Wow.)

Anyways, I'm a little mixed on blocking port 25. I don't know what a better solution would be. Perhaps not allowing a computer running Windows to directly connect to the internet. Or maybe monitoring the email sent, and setting either a limit on the number per day, or just watching for patterns of mass mailings.

So the spammer just forges the source IP.

[nuckfuts]

It's trivial to forge the source address of packets. You can even talk to remote computers this way if you can predict their ISN's and you don't care that replies won't get routed back to you. SMTP is a simple enough protocol that spammers could assume what the replies are and thus send mail from a faked address, something like... Connect to port 25 (Assume response was a ready message) helo somename (Assume some response) mail from fake@domain.com (Assume response is "Sender ok") rcpt to: somebody@somewhere.com (Assume response is "Recipient ok") ... So it seems the problem would just be changed to "are your sequence numbers predictable enough for a spammer to fake a TCP handshake on port 25"?

double edged sword

[xee]

this could also help spammers. say a company publishes a list under this new recommendation. suppose their mail server is unsecured agains third party relaying. now the spammer has a list of valid domains they can use to bounce through the mail server. lets hope anyone smart enough to use this is also smart enough to secure their mail server.

two problems

[gunix]

as I can see it.

The *DSL user that has bought a domain foo.bar that is hosted on a server, somewhere in the world (that doesn't allow mail relaying). And this user want to send mail that originates from the foo.bar domain.
Ehhh.. that user is screwed by this.

And patent? Well, that will be very good for making it a technique that every MTA will use.... releasing it as Public Domain? Remember Rambus?

Do as I say, not as I do?

[wmshub]

I signed up for their mailing list. Downloaded their perl test. Used it on their "welocome to the SPF mailing list message". The result:

$ perl -MMail::SPF::Query -le 'print for Mail::SPF::Query->new(ipv4=>shift, sender=>shift)->result' 207.8.214.4 umbrella.listbox.com
...
fail
client umbrella.listbox.com[207.8.214.4] is not a designated mailer for domain of sender umbrella.listbox.com

So apparently these guys don't have their own mailing list system set up to use their protocol properly? Or am I using their tool wrong? (I'm pretty much just typing in what the README gives).

Re:Won't work unless everyone implements this

[Malcontent]

Where is this "contract of email"? I don't ever remember signing such a thing. How am I bullying anybody if I choose not to accept mail from them? The blacklist is a service for me.

Why should't I blacklist all open relays? If they are not spewing spam today they will as soon as they are discovered.

Finally. Why would anybody run an open relay? Just exactly what are you trying to accomplish by doing such a thing.

The Real Solution for Stopping Spam

[rick-o]

The only way to stop spammers is to stop the people who are paying them money to send it. And the only way to do that is to make it an ineffective advertising medium.

If everyone (and I mean everyone) stopped buying products from spammers and their clients, we could wipe it off the planet by the end of the year. How many people here have explained to their parents, neighbors, and non-technical friends why spam is bad? Or how, even if it's about a product they really want, they should buy it from somebody else on principle? We've been trying to solve this problem for a long time, but I've only seen proposals for technical solutions.

There are no technical solutions to social problems. Support the Great Spam Boycott.

Re:black hole relay...

[Lord Prox]

Professional spammers have gone beyond open relays to planting trojans on cracked Win boxes. Rather than rely on a Russian roulette approach of finding an open relay, they just hack a Win box on broadband and they have their own server that they control.

Hmmm... I have to say I partially disagree. My server logs show 3 - 10 attempts per day to use it as a relay. I ran an open relay one to see how long it would take and how much spam would be sent. fast and a lot were the answers. I'll bet I could black hole 100K slices O spam a week...

Re:black hole relay...

[kdsolutions]

What is needed is a way to track total e-mails sent versus spam e-mails sent fron a domain prior to blacklisting a domain. That way, if five or six messages from a domain are marked as spam but five or six million were not, the domain does not get blacklisted.

I would be pissed if I sent someone an e-mail and they didn't recognize my address and immediately reported it as spam and got my domain blacklisted. If there was a way to refer to the total number of messages sent from my domain and it was seen that only that one message was marked as spam, out of several hundred or several thousand messages I have sent, my domain would not be blacklisted.

However, if I set up a mail server at biggerdick4u.biz and send a few VALID mails, then a bunch of spam, the percentage of spam sent would eventually reach 10%, 25%, 50%, 75%, 90%. Any of these would be good points at which to blacklist a domain. 10% spam kills it sooner, 50% gives the benifit of the doubt, and 90% says "okay, you're scum, shut the fuck up already!"

I think a warning at 5% and blacklist at 10% would be a safe way to go. It would let the "average" user know that the type of message they are sending is generally not wanted and give them a chance to change thier mailing pattern and it would almost immediately kill spam domains.

Just the percentages, however, are not enough. What is someone marks the very first mail you send as spam? then you have sent 100% spam and your domain get blacklisted. NOT FAIR! Percentages should kick in after you have sent 100 messages or so. This happens almost immediately on a spam domain.

There should also be a limit on how many messages a domain can have marked as spam before it is blacklisted. Something like one thousand should work. That way, a spammer can't sent out one spam to you, twenty valid messages (subj="hi" msg="hi") to one of thier own addresses (thereby keeping the level of spam below 5%). Once they sent those thousand spams, they get blacklisted. Again, a warning should be issued at 500 messages (half of the limit).

I'd like to see this done, and soon!

SUMMARY:
1. You can send 100 e-mails "free"
2. After that, you must maintain a spam level of less than 10% or one thousand messages total
3. Once you reach 50% of the limit, you will be warned
4. Once you rech the limit, you are blacklisted

<joke>

5. ???
6. Profit

</joke>