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...

[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.

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: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.

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?

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.