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.
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.
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"
http://www.tmda.net/
Working wonders here.
No more Micro$oft bashing from me. Its like bashing at the special olympics.
How can this help with so many pink contracts?
Look at Bellsouth and OptIn.com for heaven's sake!
Any preoccupation with ideas of what is right or wrong in conduct shows an arrested intellectual development. (Wilde)
am considering taking out a defensive patent on this architecture for exactly one reason: I don't want to get sued for infringing someone else's patent, bogus or not. Patent it, then declare it public domain, and we sidestep a a quagmire of Intellectual Property issues. A patent will cost approx USD$10,000. If we can get ten major ISPs to contribute $1,000 each, we can jointly own the patent and guarantee there will be no legal liability. Contact me if you can help with this.
Only in America do you have to patent something to put it into the public domain. Shouldn't that be free?
SAILING MISHAP
the problem with this is the following, most users are told to use their isp as the relay for outgoing mail. this would mean that if the users travels somewhere else where their relaying server is not in the list of ips, their email would be marked as spam and be trashed.
a solution like this would be all or none, either everyone uses it and follows those rules, or no one will use it.
besides you now have to get all the people who own domains to get a list of ips together, not the most trivial thing for non technical people.
Like all the other final ultimate spam solutions, this one is broken. The designers assume that spammers will not have domains of their own - as we've observed, spammers have many domains, and $6.95 will hardly break them. They can register thousands of domains, set up perfectly legitimate SPF records on them, and forge mail from those domains. This scheme would slow spam down for about a week, after which spammers would all be using throwaway domains.
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.
Hey man, I love abusing my cable connection too, but since I'm not willing to pay $100 instead of the $40 I'm paying now, I don't expect being able to do everything I want to.
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?)
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.
GROGGS: alive and well and living in
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.
Yes, this measure, by itself, will not remove all spam from the face of the Earth.
Yes, this measure will operate to make e-mail somewhat less convenient and require authenticated SMTP servers and the like.
But YES, Spam is awful and a serious problem, and if we wait for the silver bullet, we will accomplishn nothing ever at all.
We need to take steps, a few at a time, that will help, a bit. Steps, a few a t a time, that will help a bit, even if it means some inconvenience.
Eventually, the problem will be better.
Eventually,m the problem will be much better.
And maybe, the dollars will start moving to other ways to annoy us.
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.
Don't worry, it's still being actively worked on. In fact I believe there is work going on with the IETF's ASRG (Anti-Spam Research Group) to integrate some of the various proposals (SPF, DMP, RMX, whatever) together.
And assuming one were to piggy back it on DNS or some existing service, how would something like Verisign sitefinder fuck it up?
It is piggybacked on DNS, and it's done through TXT records that specify either "spf=allow" or "spf=deny". A confusion of A vs. NXDOMAIN, such as if VeriSign goes meddling again, seems not to affect the system.
Will I retire or break 10K?
"Broken SMTP" and "don't know much about the internet" my arse. Actually, there are several people who do know a hell of a lot about the Internet involved in this, and the problems (yes, including the one you mention) have been considered. I'm afraid I can't remember how it gets round that particular problem, though; you'll just have to read up on it yourself.
Am I the only person that remembers an idea generated by some anti-spam commissioned think tank, which came up with the idea of putting reverse MX records into zone files?
Basically, this approach would allow one to specify a list of domains that were allowed to relay mail. For example, Mail Service A would add an RMX record that specified mailA.com Then, whenever email was delivered to Mail Service B that claimed to be from @mailA.com, B would check the RMX record to confirm that the delivering server resolved to a domain that did in fact have permission to deliver email for mailA.com.
Elegant, efficient, and perfectly reverse-compatible (no RMX listing would allow anyone to relay email for that domain). And this would pretty much wipe out forged domains on email. Why has this not become a standard?
As just a test of the possible efficiency of such an approach, I worked at Shadango.com for awhile and we tested out the option of rejecting mail if it wasn't coming from the domain that the email claimed on the "from" line. You'd be COMPLETELY blown away at the effectiveness of this. I believe Shadango is currently testing it again on their production servers, and I have only seen a handful of outlying cases when email ends up getting rejected. Seriously.. so anyone that doesn't believe how effective this can be, go sign up for a Shadango account (it's free) and see for yourself how much spam just disappears.
I really think this is the solution to spam.. force all of the spammers into the light by making them honest in their email headers.
-Alan Steele
No. There are plenty of legitimate configurations where the inbound MXs are not the same machines as the outbound MXs, or are different interfaces on the same machines.
This is, additionally, more elegant than the 'RMX' proposal, as 1. there could be potentially thousands of machines which were trusted to send mail from a given domain, and 2. it doesn't require a new RR type.
You're doing it wrong.
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.
from what i see into this, it is the notion of a white-list, which is advertised to the world. I duno, but I kinda like ot keep my white-list private if that is ok with you? Anyhoo... what about huge address spaces? I could be using ip6 one day, and how well would this scale up to something huge like that in years to come? Especially the large scale sites like hotmail, aol, yahoo, etc.. where users send email to all over the world.
It isn't a lie if you belive it.
The FAQ says...
To which I can only add:
Or is there something I'm missing here?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 think this actually makes things better for you. Right now many DSL addresses are blacklisted, because they are major sources of spam. With this system, you can set up the name server from your domain to say that your DSL IP address is a valid relay for your domain, and then it should just work.
How so?
it reduces the load on your server
The load on my server is already negligible.
and you do not need to do DNS lookups.
I don't have to do that now. My server does, but see above about its load. Besides, the number of lookups it does for outgoing mail is dwarfed by the number it needs to do for incoming mail, and even more by those issued with some casual web browsing, so it wouldn't make much of a difference to the servers and networks I'm requesting the DNS data from either.
Why would you want to bother with all the crap involved in sending an email when you can let your ISP worry about it
Would you care to enumerate said "crap"? It's trivial to do; inbound is considerably more of a headache. Routing the mail to my ISP's server would be more work, albeit not by much.
Those people who actually know anything about SMTP actually pay for rack space and/or a real Internet connection.
What a bunch of arrogant bullshit! I happen to have a "real Internet connection", but I'll likely switch to a consumer-level connection at some point, as I'm having a hard time justifying the cost. If I were to do so, would my knowledge of the SMTP protocol or the method of setting up an SMTP server suddenly be wiped from my brain? Are others incapable of acquiring such knowledge because they never decided (or were able) to spend the extra money in the first place?
When you have read and completely understand RFC 821, 822, 2821, 2822, 1034, 1035, 1123, etc. then come talk to us.
...and bought rackspace or a "real" internet connection, right? While I certainly don't want to discourage the reading of RFCs, I don't see why it's necessary to know the byte-level format of a DNS request in order to configure a mail server to properly send outgoing mail.
Until then, go back to your Kazaa.
Ah, so now people who haven't read all of the RFCs you listed (or are we back to talking about those with cable or ADSL?) are not only inherently ignorant, but also, without exception, flagrantly ignore copyright law and load their systems with all kinds of malicious software. Uh huh.
This is just a weak try. What it actually does is to move the weak spot of SMTP to another level, kinda out of SMTP down to IP.
This whole principle will not help to reduce spam, it will even increase it: the "noise" in the DNS system, the exchange of valid IP addresses, etc.
Plus: IP spoofing is not that hard. With this protocol at hand, just ask some mail servers for some valid IPs, and then build your own mail server with that IP.
Thank you very much, now I do not even have the means of spoofed headers to proof it wasn't me.
I'm a customer of pobox.com (for my personal correspondence) and the poor schmuck who runs part of the anti-spam solution for about 15,000 people, but that's part of a company 30 times that size.
Professionally, I already run SpamAssassin. It does pretty well without SPF. Users are actually sending thank you emails. I guess we'll see if it has much effect after v2.70. It sure will be a while before it has a large score.
The problem is that even with the company being 30 times this size, all of our email comes from the same 2nd level domain name rather than subdomains. We have 2 choices: send all of our outgoing email through the same place (they charge by the byte for internal corporate backbone usage, it's cheaper for us over the Internet), or keep the SPF records up to date for all the internet access points. Both options suck.
Personally, since pobox.com is primarily a mail-forwarding service, this might seriously affect their bottom line. This proposal makes their service more annoying to use, perhaps enough that it isn't worth my $15/year. It might be worth it to finally just get a DynDNS setup instead.
Their "objections rebutted" page mentions this as one of the biggest problems with the system. No shit. They are under the mistaken impression that many MUAs make it easy to separate the configuration of your envelope from and your header From:. Of course, they "offer" that I can use their SASL SMTP servers. Unless their customer base is a lot smarter than the average bear they will not understand what to do with this. Years of experience as postmaster@ suggests most email users are frighteningly stupid. How many crystal clear bounce messages have you "interpreted" for your users? Just what part of "user unknown" is confusing? "Thanks, you just decreased spam worldwide by a few percent. Too bad your company went out of business because of it."
All true wisdom can be found in sigs.
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
No doubt the RFC will work very effectively against people like me -- who run a secure mailserver on there own PC to avoid the mediocre service, and lone, unchangeable mail address provided by my ISP. My ISP will soon discover they can ask thousands of dollars per year for the honour being able to fully utilize the IP address I'm already paying through the nose for -- a great marketing opportunity! (if fact, with 65K ports per address, maybe they can charge for each one individually! It's only fair -- after all people use NAT to 'illegally' connect more than one machine to net -- thieves!) In the mean time, the spammers will have no trouble finding people will to host them -- millions, if not billions of dollars are at stake, and the Internet takes another step to becoming a semi-useless content delivery system.
To authenticate, you must connect to your home server first. Often, the "traveling mailman" can't do that due to network partitions, slow links, etc. I've often found it difficult to connect to my home server while traveling in India, Europe, etc.
It is often possible to guess an author's age by the proposals generated. My guess is that the author of this proposal is under 35 or at least got into the business sometime after 1993... People who have never known anything other than the amazing connectivity and bandwidth that we've had in the last decade in the US tend to forget some of the more basic realities of working with networks...
bob wyman