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...
As far as I understood, unless everyone with a domain uses this, the spammers can just adjust their scripts/programs to just generate fake emails from domains without SPF. (or did I miss something?)
I have cable. I also run my own mail server. If that's implemented, then no mail server will receive my mail because my residential cable IP won't be allowed to send mail from my ISP's netblock. Thus we all need to pay just to run our mail domains, which is too expensive.
This is a BAD idea. What happens when I have 3 different email accounts that I use for different things, and I want to send mail from each of them from my home ISP? Sure, each email provider can provide a secure SMTP for me to log into, but this sounds like a lot of work.
This is going to make a LOT of people's lives worse, and spammers will get around it anyway. After all...they can still send from another username@theirisp.com. The accounts they're sent from are garbage anyway, because many people notify the proper abuse@ based on the headers (as they should) and not the From address. Forging the from doesn't provide any cover for spammers anyway.
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?
That seems like a really good idea. If the major MTA's adopted this and made it a part of the configuration files, then new installations would be easily configurable.
If the big email services such as Hotmail and Yahoo adopted it, spammers would suddenly find that they have to spend more effort to send out spam by finding domains that didn't opt to use these rules. Even so, it would be a lot easier to filter a specific domain in China or Nigeria than worrying about every piece of mail from Hotmail.
I moderate "-1, Fool"
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.
This seems WAY to complicated as an answer to a problem that's solved much better by PGP/GPG... Wouldn't it be smarter to get encryption and signing, a proven and implemented technology, merged into more email clients instead?
-3Suns
~~~~
The Revolution will be Slashdotted
If not, what are the key differences?
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
One of the ways they do this is by providing inbound and outbound email services, through legitimate servers published through DNS. As a customer of the ISP, you're given rights to use those services, and they're responsible for ensuring your access to same -- that is, they're the responsible party for any given email address at their domain name(s).
You wish to configure your home mail server to appear as a legitimate server for outbound mail coming from another party's domain name(s); as a customer and not an administrator, I don't understand your presumption that you have a right to do so.
This is one of the key points of SPF that is going to start a lot of debate: if you purchase an email address from a provider other than yourself, you are not responsible for the outgoing mail servers for that address. Setting up and running your own mail server does not change this situation; there is no software you can run that will make your personal server the responsible party for someone else's domain name.
Since you're already running mail services, it's just a short step away to activate DNS services, available at no cost to you on virtually any platform that your own mail server will run on.
I currently host my domain with Domain Discover, at $35 a year; there's registration servers out there for as cheap as $7 a year. My $35/year domain is cheaper than a $5/month ($60/year) email account with a local Internet provider.
The primary purpose of SPF is to provide a positive authentication check for messages, to confirm that they have been sent through the outgoing mail server listed as a responsible party for the email address in question. It is inconceivable to me that any provider would bestow upon end-users the power to be a responsible party; partners, perhaps, but not individuals. While exceptions may occur, I don't feel that your situation should be one of them.
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.
I would be happier if he GPL'ed it.
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.
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.
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...
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms,
Web sites on vanity domains are just the sort of thing people like to deface. But how to go about it? Usually there's so little chance that the owner of such a domain is going to be suckered by a mail bomb. Hmm.. what's this SPF record? Seems to point to the network where the owner of this domain connects up to.. that's useful.
How we know is more important than what we know.
The FAQ says...
To which I can only add:
Or is there something I'm missing here?The reason i say this is because the white-list file could get really huge if your not carefull, and then you have the burden of advertising it on demand. Think of a good DoS situation that takes advantage of this.
It isn't a lie if you belive it.
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.
I can't wait to see this published by the GTLD servers:
*.com. IN TXT "spf=deny"
*.net. IN TXT "spf=deny"
-ez
...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.
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
Perhaps it could say DATA/If you receive this, your email server has been misconfigured./Please ask your system administrator or ISP to configure the server to discard incomplete email messages.// -pause- disconnect.
That won't get them all, and there will be the odd false positive (550 unable to validate sender address), but it should get most, no worries. It'll certainly get the zillion or so messages spoofed as being from "@hotmail.com" "@yahoo.com" and so on. If you wanted to be a pedand, you'd check the embedded "From:" address as well as the enveloped one.
I'd also appreciate some name-finding AI, so that when a message which programs like SpamAssassin become absolutely dead-set convinced is spam (ie, the filter doesn't say "maybe spam", the filter says "if this isn't spam, upload me to a microwave") arrives - but passes the above test - any email addresses mentioned in it get a score or so of vary different but realistic-looking "replies" based on the original message ("Re: P*E+N~I:S E|N-L=A/R'G\E!R/Dear Sexy Sal//Please send me four boxes of penis perpetration patches. My credit card number is 3141-5926-5358-9793 and expires on 04-04. My address is Australian Federal Police/Hay Street/East Perth 6001.//Please use plain brown wrapper on the parcel.//Fred Q Nurk esq") but from a variety of bit-bucket addresses and spread out over the next few hours. A bit sad if the spammer is spoofing from your address, but you can easily filter everything related to such spoofing - and otherwise forces the scumbags to work for their addresses. Even better if he wants to talk to a bot about invalid credit card numbers or mismatched expiry dates. Better still if you can arrange to get them done for credit card fraud, maybe by using numbers from your local supermarket's stolen-cards list. Working for their addresses is exactly what spammers don't want to do.
You see, I've become convinced that a war of attrition - making it harder for spam to get through - isn't enough.
The thing that makes spam work is that it's cheap to get addresses and cheap to send out mail. Since there will always be bad-apple ISPs (and dumbo-sucker ISPs) who let the canned-ham merchants send the stuff, the obvious step is to make collecting the addresses harder.
Collecting addresses is a two-phase process. Phase one harvests addresses wholesale using spambots and/or people stupid enough to fill in random on-line forms accurately, phase two qualifies those addresses by sending stuff to them. Unfortunately, the same people stupid enough to fill in forms willy-nilly are the same people stupid enough to respond to spam. I guess it's just not a good survival characteristic.
If it were possible to establish a contract by sending someone email, we could make the initial harvest very expensive, very quickly by simply embedding the email address in an offer of contract. Unfortunately, the courts have so far decreed that such an event doesn't necessarily entail a "meeting of minds" necessary to establish a contract - even if the email address says "email-to-this-address-costs-USD-1000-in-advance@m ydomain.dom". To me, this makes no sense, kind of analogous to releasing an automated tank and being able to claim that any damage done by it was not deliberate.
Nevertheless, if we can make
Got time? Spend some of it coding or testing
It makes filtering spam a lot easier. For one thing, you no longer have spoofed email addresses to deal with. Now, email that claims to come from "aol.com" will really come from aol.com, instead of some spam server.
Secondly, in order to register a domain you need to provide some sort of cc information which would imply that there would be a way to track down spammers (assuming they didn't use stolen cc's, and I wouldn't put that past 'em -- but then they're commiting an actual crime and this kind of thing is much easier to put people in jail for than the current crimes they commit).
Thirdly, it adds costs to the spammer's bottomline. Reducing "profitablity" from spamming == good way to reduce spamming; if it cost them a new domain for every 10000 spams they send out, it'd cost them $800 to send one million spam emails. Not to mention the time it takes for domain info to propigate after registering it, etc (spams will fail to get through until the dns info exists).
As far as registering the victim hostname with the SFP server, that would imply that you would have access to the SFP server. I doubt that it would be something you could have a random computer "register" with. I'd imagine it'd be some sort of non-dynamic system, similar to creating a domain server authoritative for your particular domain (most people don't have fancy systems to update dns entries dynamically; at least I never have).
Yes, you might send some spam to /dev/null with this approach, but it would be only hurt the clueless to amateur spammer and the quantity wouldn't be that much.
I've been swashdotted -- Elmer Fudd
Your idea of running fake open proxies for spammers to discover and 'abuse' is not new. There is already software for this purpose. Search for 'proxy honeypot' or 'proxypot' in Google.
In fact, Ronald F. Guilmette who ran the monkeys.com anti-spam website and open proxy blocklist and who was forced to shut down due to DDoS-attacks also ran an extensive network of proxypots to unconver those criminal spammer gangs who regularly abuse open proxies and also to uncover the rouge ISPs who host these criminals and who let the proxy hijackers to be connected.
Mr. Guilmette posted several times to the news.admin.net-abuse.email newsgroup (charter) compiled lists of the top proxy-abuse allowing ISPs and extensive analyses of the proxy-hijackers' operations (examples here, here, here, here and here). This anti-spam work was partly very fruitful, resulting in several ISPs to be outed as spammer-friendly and also being forced to clean up their act.
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...