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

[marnanel]

It doesn't solve the whole problem of spam, no. It's one possible way to deal with one particular aspect of the problem: forging From addresses will become harder. This is a major annoyance and it'd be good to have the hole closed.

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:BAD Idea

[sgifford]

Sure, each email provider can provide a secure SMTP for me to log into, but this sounds like a lot of work.

Running a mail server is a lot of work; providing SSL and SMTP AUTH isn't much more.

I'm not sure this would work very well, but having more ISPs support SSL and SMTP AUTH doesn't sound like a terrible thing even if it doesn't.

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

[PhoenixRising]

Presumably, the body responsible for the domain would be responsible for authenticating users to ensure that they are not spoofing before it comes out of their domain. Unfortunately, this would lead to even more ISPs taking the AOL-esque tactic of stopping anyone from setting up a mail server, forcing all outbound mail to pass through the ISP's servers.

This would also cause serious problems for mobile users -- if I'm on the road, who knows what ISP I'll be connecting to. However, I probably want my From: address to stay the same no matter where I'm connected.

This solution doesn't seem likely to make a serious dent in the flow of spam, and would likely add unwanted restrictions to the actions of users. As such, it seems unwise.

Not realistic, and not a complete solution.

[Elias Israel]

Yes, having information on which SMTP servers are the expected and typical mail "emitters" for a given domain would help reduce (not eliminate) spam.

But the number of cases where users "forge" their from lines for perfectly innocent reasons is huge. Everyone here can probably think of a few cases. Here's one to get you started: "I'm working from home today about I don't want replies to my business email sent to my home account."

Of course, they've covered that in their FAQ. Their answer boils down to: "Tough noogies. You have to suffer the inconvenience and change your behavior because I don't want to suffer the inconvenience of spam."

This, alas, it typical of the disdainful, anti-user mentality that one finds in too many anti-spam efforts.

Here's a clue: want an anti-spam solution to work? Then start from the idea that it needs to make the life of the end user easier, not harder.

Of course, I'm biased. See my sig.

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:Won't work unless everyone implements this

[wayne]

Nope, you didn't miss anything. Those people who don't care if spammers forge their domain name will likely have spammers use their domains. If the SPF system (or similar systems) become widespread, then receiving email from a domain that doesn't use SPF will become a strong indicator of spam and some people may choose to reject such email, or add in a score into spamassassin.

This is not much different than feel that they should be allowed to run open relays. They will end up on DNS blacklists and others may choose not to accept mail from them. Their server, their rules. No one is forcing anyone to close open relays, and no one is forcing anyone to accept email from everyone.

Re:Another problem:

[Pharmboy]

Actually, that brings something important to mind: Here in Australia a very large proportion of mail servers are Debian boxes. If that patent idea gets taken up, I can't see Debian including SPF; it'll be poison.

He refered to patenting it, and immediately releasing it as Public Domain. This means it can be used by anyone, in any license, even Microsoft. Actually, you NEED Microsoft to use it if you want it to work anyway. But there is already lots of PD in Linux, including Debian, so no worries.

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?

Think of the email virus/worm consequences...

[gladbach]

This could do wonders... One of the ways that the latest email viruses/worms have been so effective, is that they tend now to randomly spoof the from lines after mining valid emails so that its harder to figure out *who* it is that is sending you the infected email.... If this system were globally in place, email worms like sobig and blaster would have never gotten as big as they did, so easily...

Travelling Mailman problem's solution's problem

[Todd Knarr]

He mentions the Travelling Mailman problem, that of being able to use your home e-mail address while not on your home network. His solution, having your home mailserver use authentication so that you always send via it, has it's own problem. The problem is Windows malware that e-mails itself out. Several large ISPs have responded to this by prohibiting the use of any mailserver but their own from inside their network. This puts me in a quandry: I wouldn't be able to use my domain while on my ISP's (Cox Cable) network because SPF would reject it, and I can't use my domain's mailserver because my ISP won't let me connect to it. This is, IMHO, a fatal flaw in the scheme.

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.