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"
http://www.tmda.net/
Working wonders here.
No more Micro$oft bashing from me. Its like bashing at the special olympics.
Perhaps this could stop spammers from spoofing the addresses of other internet users. However, I don't know if this will stop spammers from using whatever return address they want to regardless of what domain they send their spam from. Would it?
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
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.
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.
Comment removed based on user account deletion
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?)
Add a TXT record in your domain's DNS saying that senders are permitted from your ISP's SMTP server. See Setting up SPF.
how to invest, a novice's guide
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.
Wouldn't it be better to implement something in DNS that sets the ips to be used....Maybe call it an RX record put it in for the @ record of your domain. @ RX 127.0.0.1-254 RX .....
CRX smtp.someotherdomain.com.
That way you can just poll bob.com and ask bob is whatever-dsl-address.goofyisp.com can really send mail as amazon.com or not. This is more extensible to people who have home-grown servers, as well as big companies. I mean, who doesn't know the outbound servers for their own domain?
You could even couple this with some other check that looks up originating IPs and does a query back to the domain to see if they can send (as suggested in the above article).
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.
Look, if we could convince every sysadmin on the planet to upgrade their MTA's, we could just implement HashCash and be done with it. And this guy wants us to concurrently update all our DNS maps?
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,
Works for UDP, not so simple for TCP.
Put someone else's IP in a TCP from when you first connect and the server sends a SYN/ACK packet to that IP. When it gets an RST packet from that host, it drops the connection.
Put someone else's IP in a TCP from after you've connected and the server will drop the packet on the spot because it doesn't have a socket allocated to that connection.
Last time I checked, SMTP ran over TCP.
To spoof the from IP in TCP, you also need to be able to:
1: launch a successful DOS attack against the machine you're spoofing
2: be able to predict TCP sequence numbers coming out of the server (embedded in that SYN/ACK packet) to a reasonable degree of certainty, so that you can guess them in the time that the host you're DOSing in 1 remains down.
All this is significantly more involved than simply forging from: headers.
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 can't wait to see this published by the GTLD servers:
*.com. IN TXT "spf=deny"
*.net. IN TXT "spf=deny"
-ez
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.
...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.
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.
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"?
this could also help spammers. say a company publishes a list under this new recommendation. suppose their mail server is unsecured agains third party relaying. now the spammer has a list of valid domains they can use to bounce through the mail server. lets hope anyone smart enough to use this is also smart enough to secure their mail server.
Oh shit! I forgot to click "Post Anonymously"...
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
$ perl -MMail::SPF::Query -le 'print for Mail::SPF::Query->new(ipv4=>shift, sender=>shift)->result' 207.8.214.4 umbrella.listbox.com
...
fail
client umbrella.listbox.com[207.8.214.4] is not a designated mailer for domain of sender umbrella.listbox.com
So apparently these guys don't have their own mailing list system set up to use their protocol properly? Or am I using their tool wrong? (I'm pretty much just typing in what the README gives).
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.
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
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).
The only way to stop spammers is to stop the people who are paying them money to send it. And the only way to do that is to make it an ineffective advertising medium.
If everyone (and I mean everyone) stopped buying products from spammers and their clients, we could wipe it off the planet by the end of the year. How many people here have explained to their parents, neighbors, and non-technical friends why spam is bad? Or how, even if it's about a product they really want, they should buy it from somebody else on principle? We've been trying to solve this problem for a long time, but I've only seen proposals for technical solutions.
There are no technical solutions to social problems. Support the Great Spam Boycott.
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.
adding obligatory header "x-spoofed-from" to email headers? Just like the new "evil bit" in TCP...
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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...
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.
Thanks for the suggestion... downloaded a SMTP honeypot i'll see how well it works. However most of the proxy/honeypots were aimed at servers not for "grandma's DSL Wintel box". Simple and stupid for the end user. Think distributed computing seti@home meets anti-spam. No single site (monkeys.com) to take down. It would not stop spam but it could make there lives that much more difficult by removing one tool in their toolbox. And costing them time/money/product in the process. My SMTP logs show that I get plenty of relay attempts in a day so using other peoples servers is still a widely used tactic. I think this would be a good response.
This will prevent all mail spoofing. It wouldn't stop anyone from having a mailing list though, although you would A) need your own domain, or B) get your mailing list server authenticated by your ISP.
ReadThe ReflectionEngine, a cyberpunk style n
SPF is a mechanism to prevent envelope sender forgery. No more, no less.
SPF (and other RMX-link proposals) would be effective at detecting the situation you describe. The spammer who trojaned a Win32 box would only be able to use it to send spam with an envelope sender of something@spammercontrolleddomain.com.
The admin can use a real time black list or other mechanism to enforce policy (drop mails from known spam domains).
Spammers can register many throwaway domains, but: it only takes a few spams detected and reported to the black list before the domain becomes worthless to the spammer again; and such domains will end up being composed of random characters, which tools like Spamassassin can use in their suite of tests (for example, SUSPICIOUS DOMAIN = +2) to make detection even easier.
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