Slashdot Mirror
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.
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...
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?
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.
SPF support for most open source mail servers can be found at libspf2.
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...
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.
Read, L
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?
Mail? Put "slashdot" in the subject to pass the spam filters.
...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.
Please help metamoderate.
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.
Speak before you think
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"?
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?
Evolution of Language Through The Ages: 6000 BC : ungh, grrf, booga 2000 AD : grep, awk, sed
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.
War is necrophilia.
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...