"All those cable modems out there, which aren't allowed to run servers because of blazingly clueless policies by cable companies, could be running honeypots, especially teergruben [tuxedo.org], which run valid SMTP vvvv...eeee..rrr..yyyy...sssss...loooowwwww....lyy yyy"
Jackpot has a tarpit value, or tarpitting can be disabled. Jackpot will run on windows systems if a JVM is installed. Those wanting to do this to screw spammers hitting their cable/DSL connecitons should be quite pleased at the results.
http://jackpot.uk.net/
Incidentally, I push Jackpot but it is another person's project - Jack Cleaver. It's a very fine piece of software.
"These people learn quick, after their servers make their way to the open relay blacklists. Just make sure it happens every time when you receive a spam that have been apparently sent through an open relay. Forward the spam to relays@ordb.org with the first line:
"Relay: IP_address"
But I am the open relay. That's my approach. I'm only "open" for the spammer relay tests - the spam gets flushed (actually usually it is archived but as far as the spammer is concerned it's the same thing.) Jackpot will stop storing spam received form a particular IP when a specified number of spam messsages from that IP is reached.
You really ought to try Jackpot - it's a neat program. http://jackpot.uk.net/
What you say does very often apply for open proxies - a lot of spam I've trapped came first through an open proxy.
I should mention that while 235 million spam messages stopped is wonderful and impressive it isn't the focus. Spammers can send relay spam because they can easily and reliably find open relays. The real goal of honeypots is to undo that - make finding open relays difficult and unreliable. Some open relays may still relay only 50 messages/day for about 1000 recipients. Setting up honeypots in the same zone with these makes the real open relays less easy to find, and that is the real goal. We need to destroy, completely, the ability of spammers to find open relays. Causing them grief using information from trapped relay test messages is another way to make finding open relays too difficult for them.
Put enough painful traps in an IP region and the spammers will have reason to not test at all in that region. Then it won't matter if there's an open relay in the region becuase the spammers will never look there for it and won't find it.
(Sure, secure all you can, but securing them by making them honeypots is far more powerful than just bolting the door, so to speak.)
The same discussion works for open proxies and for any other TCP/IP service they decide to abuse. Punish them if they try. Drive them away. Make not bothering you (or anyone else) the course they choose. Make them suffer if they don't choose wisely.
Re:Spam needs a global solution (Global Solution)
on
Plan for Spam, Version 2
·
· Score: 5, Interesting
"Also, isn't it easy for a spammer to workaround a spam honeypot -- create a hotmail account, add it to your spam list, and verify that it did go through."
Yes. So far many don't (I don't know of any that do, but spammers do, eventually, stop sending to a honeypot.) Ralsky never caught on to the Moscow honeypot that was whacking him last year (I think he's the one who told Shiksaa - visit NANAE to find out who she is - that SPEWS was killing him, just at the time of the major whacking Ralsky was getting.) (Chuckle.) I looked for spammer dropbox addresses in trapped spam 3 years ago - I figured they'd use the same address every once and a while in the list of victims. I sorted the list of recipients, sorted again, removing duplicates, and compared. No differences: each victim showed up once. They could do it, they don't. Years of experience has taught them that they can test for open relays and abuse them incautiously - nobody does anything to counter them. They think they own the internet because people ignore their attempts to relay. It's easy to knock the smirk off their faces: pay attention to illicit connection attempts.
There is a project already in motion to collect all recipient addresses for honeypot-collected spam in a central location. If any address shows up too frequently then that's a suspicious address. The real problem isn't what the spammers do or could do, it is that too few people use this very simple method to wreck the spam path.
My original honeypot went down last week (I retired in 2001; I haven't really checked to see what the current managers are doing with it.) This year I only captured relay messages, delivered nothing. When it went down last week it had captured over 100 relay test messages in January. You can also go after spammers with these (and I did - no results yet to report, I'm hoping for some big results.) Spammers could detect that - but too late.
There's a sneakier version of what you suggested that the spammers could use. I won't tell them what it is.
Volume is the key - many honeypots are needed, quickly, to whack them before they adapt. Same for open proxies. It is an absolutely simple approach. You could set up Granny's system to run a honeypot and it would work, if she has a connection to a segment the spammers search for open relays. http://jackpot.uk.net/
Try Jackpot and see for yourself, if you can.
Re:Spam needs a global solution (Global Solution)
on
Plan for Spam, Version 2
·
· Score: 5, Informative
OK, signal and noise. What if the signal was all in one frequency band and the noise all in another. Problem separating them? No.
What if, in effect, a similar distinction held for spam in the transmission channel - that spam by itself selected a pathway to the recipient that was never used by the signal? Block that pathway and the spam never gets through.
Spam doesn't select a pathway but spammers do. If you could block relay spam at the open relays it would be dead. You can't, of course - the open relays are controlled by people who don't know the need to block spam. You know that, I know that. If you can't change the people then change the open relays (from the spammers' points of view.) Set up a system that looks like an open relay and stop the spam. An open relay honeypot.
I asked an operator of such a honeypot how he did last year:
> How did 2002 end?
From March 7 to December 26 2002, the total was:
235,624,232
Using one Pentium 90 he stopped spam to 235 million recipients. Think about that number when you see filter people reporting what they stop just for their own domains. This was spam to recipients all over, not simply to the honeypot operators domain: he operates at the relay level. He stopped 100% of the spam, no deception deceived him, no tuning was needed, no valid email was caught - it is perfect filtering. Perfect filtering - who else has that?
And you can do it at home on your DSL or cable connection (the guy above uses sendmail -bd, but Windows users have a program they can use):
http://jackpot.uk.net/
Yeah, I know, spammers are switching to open proxies. So, write an open proxy honeypot. That, too, will be 100% efficient. In addition you now are giving spammers reason to fear every open relay and every open proxy they detect. FEAR. The SPAMMERS have to scramble. They have to scramble and they have to show everything they do to overcome the technique - there is no stealth way to look for open relays and open proxies.
The problem is solved, it is a matter of implementation and of getting active systems everywhere in the net space (so there's no safe IP space for the spammers anywhere.)
Remember: A single Pentium 90, 235 million spam messages stopped in 10 months.
"Personally, I think we could do a great deal to slow down spam if we stuck SMTP honeypots on port 25 andchecked out mail from a different port."
You've made my day. For Windows (and other JAVA environments) there's Jackpot: http://jackpot.uk.net/
Most windows users have no program that listens on port 25. Only spammers are going to be attempting connections to their port 25. The Jackpot users catch these spammers easily.
I've run a combined server/honeypot. It happened that my MTA gave filenames of different forms to local vs. relayed messsages. I could filter FOR the in-domain relayed messages and leave the rest undelivered (no matter how clever the spammer his spam didn't get out because my filter looked for valid email and delivered that. The failure mode was for some valid email to be caught - I had to examine the trapped spam periodically and improve my filter. I used exceedingly dumb algorithms - someone doing this intelligently would probably have it right the first time.)
You don't have to change ports if you run a server - just filter intelligently. Spam is exceedingly more obvious at the relay than at the destination (how many times a year would VALID relay email hit your server from a site in.br? Something like.000000001, I'd guess. Close enough to never to suit me.)
"I've actually been writing my own personal SMTP honeypot for this very purpose. I don't imagine I'll have much trouble getting friends to run it."
I don't even know who your friends are but I like them tremendously already.
You need to know a little about relay tests. You can learn on the fly or go to news.admin.net.abuse.email (using Google) and look for postings with "relay test" in the subject (also in news.admin.net-avuse.sightings.) Most relay tests have your IP encoded in decimal ascii in the message-ID. Some have your IP in plain text in the subject or message body. One spammer has your IP in the body in a line that starts with MAILINFO: and then in decimal, with 111 added to 3-digit IP fields in the dotted quad, 11 added to 2-digit fields, 1 to 1-digit fields. A couple of years ago there was a spammer that encoded the IP in the serial number of a "face-painting kit" - he stole a scenario from a Seinfeld episode.
You want to deliver relay test (only.) This convinces the spammer you are an open relay. Then he sends spam. You don't deliver that, you can examine the trapped spam and find ways to hurt the spammer. A lot of relay spam now hits the open relay from an abused open proxy.
There's a real opportunity for open proxy honeypots - they also can be wicked.
A quick honeypot can be created from a standard MTA - just disable message delivery. Add to that a means for delivering the relay tests you want to deliver and you have the spammer by the b*lls.
It's good to see you thinking about port 25 and SMTP. There's value in the sorts of thing you advocate and many ISPs have done them. Spam remains - it isn't enough. Same for filters and blocklists. Something more needs to be added - spam is growing (the growth of spam is in large part the result of the success of the other methods: the spammers must send more spam to get a return.)
One can complain on and on about systems with unsecured port 25. That isn't solving the problem - time to stop and take a look. Spammers send relay spam, to send relay spam they must find open relays, to find open relays they send test messages. Most email system managers can tell you that they see failed relay attempts in their logs.
How much more of a clue is needed? You see that the "secure the relays" campaign isn't working, you see that the spammers test and test and test, looking for open relays. Taking them away hasn't worked - try GIVING THEM OPEN RELAYS. Partly open - ones that only deliver their test messages. Now what do the spammers do? If deceived (right now they mostly are) they send relay spam to the fake relays, where it is simply stored (one can look through the trapped spam and find ways to cuase further hurt to the spammers.) It isn't delivered, the spammer doesn't make a dime from it. No matter how clever the spammer is in disguising what he's sending it doesn't matter - the trapping is based on the spam delivery path, not on its content.
Don't want to deliver tests? OK, don't even do that. Just set up a system that captures them. I have one, I have a test message that appears to have originated within a few miles of the MIT conference the same week as the conference:
Received: from ts009d22.cam-ma.concentric.net by X.X.X;
Wed, 15 Jan 03 17:56 CST Message-Id:[lab]049049049049049049049049049@m sn.co m[rab] Date: Wed, 15 Jan 2003 18:57:16 -1700 From: candy@webname.com Subject: pick up the phone To: porcha@SoftHome.net MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
I munged the system name and I changed the encoded IP of the system in the message-ID to all 1's. The numeric strings are decimal ascii: "048" is "0," etc. [lab] is a left angle bracket, [rab] is a right angle bracket.
Get enough people trapping spam and even more people trapping and reporting relay tests and you put pressure on the spammers that, up to now, they haven't felt. It is a wide-open area for using technical means to bring them down. Wide open - note that well.
In the SE part of the US is a system operator who has stopped spam to over one millon recipients so far this year.
When this idea is presented there's frequently someone who objects "but the spammers could simply put one of their own addresses in the list of spammed addresses and see if the mail got through. That way they could detect the honeypots." That's true. So far they do not do it. Even if they do there's no way they can eliminate the danger to them from trapped and reported relay tests. If they get clever and test only though open proxies then the center of activity shifts to fake open proxies. That's also easy. A couple of people (including Michael Tokarev, in Moscow) have had great success with open proxy honeypots. There's another objection that can be made. It can be overcome but I won't state it here and give spammers ideas.
Spam is not defeated. It would seem that every reasonable defense should be employed while that is true. Running fake open relays is fantastically easy and is very close to 100% perfect. Do it on an IP that has no legitimate port 25 traffic. Then everything that comes to that port 25 is spam or a relay test. Do it on a Windows system with no MTA - port 25 isn't even in use.
Run Jackpot: http://jackpot.uk.net/
There are, uh, a few Windows systems out there?
An earlier expression of this same idea is indicated by sendmail -bd. At one time that would mean sendmail accepting but not delivering messages - now you have to od more to stop delivery attempts. In general, any MTA configured to accept anything but deliver nothing will trap relay tests. Force delivery of the relay tests before they're too old and you deceive the psammer who sent it.
"Name one technological measure which has a zero false-positive rate, a low false-negative rate, and a snowball's chance in hell of being adopted. The problem should address spam at the server side, since it's already wasting space by the time it's allowed onto a client machine."
Relay spam honeypots. They operate at the relay level which is better than the server side since the server never sees has to deal with the spam. A relay spam honeypot has no legitimate email function - the only email that comes to it is spam. That's 0.000% false positives. It delivers only the spammers own relay tests. That's a low false negative rate - 0, for all practical purposes.
The chance of being adopted is problematic. People are so used to thinking in terms of blocklists and filters they don't expand their thinking to honeypots. But think about it: with a honeypot you may get to wallop some spammers spew on your own system. Not just a little but a lot.
My original honeypot is only a half-honeypot now - it delivers nothing. In 4 days, 6 hours it has received 27 spammer relay tests (all reported in NANAE.) In all probability if I had delivered any one of these tests I'd have gotten spam back, in volume. That would be spam for other users, spam that I'd not deliver. Wollop.
It was doing the whole bit in November. Here's a tiny sample of Subjects from that batch:
Subject: Get more energy 10260 Subject: Gain muscle and lose fat 26020 Subject: Lose weight while you sleep 26898 Subject: Lose inches 8883 Subject: Feel your Best 19718 Subject: Lose weight easily 13661 Subject: Lose inches 23016 Subject: Feel young Agian 30401 Subject: Feel your Best 20100 Subject: Feel your Best 27895 Subject: Feel young Agian 2513 Subject: Be your best 7665 Subject: Feel young Agian 3943 Subject: Gain muscle and lose fat 19581 Subject: Get more energy 17343 Subject: Build muscle and Burn fat 18488 Subject: Look and Feel Younger 20897 Subject: Feel young Agian 12503 Subject: Look your Best 6785 Subject: Look younger 10878 Subject: Feel ten years younger 3524 Subject: Lose weight while you sleep 8892
I imagine all have references to href=3D"http://14610@wwW.nutritionmatrix.com
I didn't do anything with these earlier because the disk was down until 4 days, 6 hours ago.
Yu can do this on a network-connected Windows system using Jackpot:
http://jackpot.uk.net/
Jackpot gives you a web page that lists all the spam you've gotten by source IP. People can look at every trapped spam message. You'd send the URL to people who should be looking, like ISPs.
0 false positives, 0 false negatives, no external database, no training, no particular skill - good enough? I think so.
Last year I had the (somewhat) good fortune to capture relay spam from a spammer who used reply-to addresses at freemail providers to receive his responses. Good fortune? Yes. The spammer had large numbers of these - most (maybe all) appeared in spam I captured. A simple string search and a single email message to the freemail provider got all of the accounts nuked. That spam run was largely lost to the spammer.
But what I'd like to mention is that if the freemail provider paid much attention at all to patterns in the logs I think it could fairly easily identify many spammer dropboxes.
Additionally I'd like to mention that rather than nuke the account I'd prefer the freemail provider simply blackhole any mail to that account - nuking tells the spammer the account is dead, he moves on. If nuking isn't in accord with the TOS then I suggest changing the TOS.
One example, listing Reply-to addresses:
http://groups.google.com/groups?q=snowboarding.c om +group:*.*.*.email+author:brad&hl=en&lr=&ie=UTF-8& selm=3C7B0714.749B048D%40mail.tds.net&rnum=1
"This is just your broken filtering, which you insist on keeping broken. Your broken filtering isn't my problem. It is trivial to filter on the IP address in the Received Header. Even if the spammer inserts some additional forged headers, their real IP address is still there, and will be
found on an IP address RBL."
I have the advantage in this discussion of having trapped relay spam at the relay - I can see the headers, I can log the actual source IP. At the beginning of 2002 a lot of relay spam did come direct from the spammer - many spammers try very hard to obscure their own IPs (even the spam I'm trapping now has HELOs with forged IP numbers in them - that deceives some MTAs, I think.) Now I think it is far more typical for spam to arrive at the relay from an open proxy someplace (South America being a very common "someplace.") In that case you don't see the spammers IP at all - you see, at best, the IP of the open proxy. There's millions of those - most probably aren't yet listed by any RBL. The spammer may add fake headers that show a source at AOL or elsewhere - these are pure fiction.
During one long period of trapping relay spam I observed that it was all directed to AOL addreses. At that time AOL didn't (apparently) use any RBL or local equivalent - all that spam would have reached the recipient if it had not been trapped at the relay. DNSBLs do not stop all spam (if for no other reason than that many ISPs don't use them.) Filters don't stop all spam (my ISP uses Brightmail - I get classic 5-report chain-letter spam, still.)
In any case there are two aspects to stopping spam: stopping spam to you (or to your users) and stopping spam, period. The major efforts right now are directed to stopping one's own spam. It isn't working well enough to stop spam overall. If spam is to be stopped by technical means it had better happen soon - the DMA backs an anti-spam bill and that could become law this year. If that happens the odds are great that the "stupid" spam will end in a year or so - the law wil work against that. That will open the gates for a flood of "respectable" spam that the law will grnadly declare legitimate. Maybe the law would forbid blocking of such spam. Few sane email users should want that.
("Stupid spam" isn't precisely defined, but it's the common crap you now get: porn, organ enlargement, Viagra, mortage, debt consolidation,... One aspect of stupid is "If 90 percent of spam is blocked we'll just send 10 times as much." The distinction I'm making, while imprecise, is between the millions-of-addresses-CD type of spam and spam that's modeled on traditional bulk-mail advertising. The DMA wants the latter to be allowed.)
"Yes, they almost never have valid return addresses so they never know whether the mail gets there or not. The just have stats based on hits on sites and web bugs in html mail. So the answer is yes, they do send long term to blocked addresses. There were some stats on that, how much actual spam was being blocked by spews, for example."
Don't forget that two different things are done by SPEWS and that the argument is over only one of these. Blocking spam is something SPEWS does well - may they continue to do so as long as needed. Blocking non-spam to pressure non-spammers to do something (SPEWS apologists aren't crystal-clear in their explanation of this) is abusive and wrong-headed. The impression I have is that they have perhaps done only a few hundred such blockings in their history, making essentially no progress in fighting spam. They have made many innocent users associated with the blocked IPs associated aware of SPEWS. Awareness could be good, but the majority of those made aware now hate SPEWS, and, by extension, all DNSBLs and all anti-spammers. OK, maybe not all of either but the actions and attitude of SPEWS and its backers pisses off real, normal people.
For other than huge ISPs most could block most of the net and cause little problem. If there's no email coming from all those blocked IPs then the blocks do nothing that stops spam. They don't hurt, don't help - are immaterial. Add to that lunatics who take the complaints of legitimate mailers as signs that blocking aimed at non-spam sources is having a good effect and you have a rotten situation. It would be seemly for the SPEWS blockers who claim that the customers of the ISP have more clout to actually test that claim and document their results. My suspicion is that a spam-tolerant ISP is not measurably more affected by complaints from customers than from non-customers. They know what they are doing and intend to continue. Harrassing their non-spamming customers does not end spam and diverts effort away from something that might have an effect into something that doesn't. Add to this the apparent frequent occurrence of SPEWS targeting ISPs who are not spam-tolerant but who have, by error (and the perfidy of spammers) gotten a spammer in their space and you have SPEWS grandly attacking targets that are not in any way the main source of the spam problem. In addition, Doesn't SPEWS, when it takes on a large ISP such as Verio, only list non-spam-source IPS in some subset of the blocks belonging to that ISP? Weird.
When the popular press discusses SPEWS and states that what SPEWS is doing is wrong it appears that the SPEWS apologists take the attitude "screw the popular press." Last time I looked in NANAE that's how it was, at least. That is not going to win SPEWS any friends (not any worth having, at least), is not going to win DNSBLs any friends (look at this thread), not going to win anti-spammers any friends.
The solution is for SPEWS to stop listing IPs of non-spam sources. They probably won't soon embrace that situation. Until they do they will receive well-deserved criticism and contempt. It's clear that SPEWS, during it's more than one year of existence, has not stopped spam. They don't have a highly-successful track record to point to as evidence that they are correct - they just sit quiet and let people weave lies about how effective SPEWS is. I'd like to flat-out decree that no one ever again use the good results SPEWS achieves by blocking spam sources to justify the blocking of non-spam sources. The decree won't work - SPEWS apologists will continue to pop up with that illogical defense - there's apparently no way to get them to use logic instead of emotion.
I'd also like to decree that those who block only for their own email not cite their perfect satisfaction as sufficient grounds for ISPs with large numbers of customers using SPEWS. It is two different situations - you are free to screw with your own email any way you please - why not? That this works for you has no bearing on whether it is good for an ISP to inflict SPEWS on its customers. The LOGICAL thing to come out of satisfaction with SPEWS for single-user IPs is to say SPEWS should be used only by single-user IPs. THEN if an important email message is blocked because of the SPEWS policy of listing non-spam source IPs the one suffering the consequences will be the one who decided to use SPEWS. That's just.
(SPEWS-supporters who delude themselves into thinking they've said something smart by responding that "SPEWS doesn't block anyone, SPEWS only lists" are welcome to do so. The issue is that of valid email blocked because some ISP used SPEWS. Your cute little objection doesn't speak to the issue - it's just noise.)
You have described the situation perfectly - I hope many people see and understand what you say about SPEWS (including those who run SPEWS). My point was that most DNSBLs don't do the idiotic blocking of non-spam sources.
Not only do I have no quarrel with what you say I think what you say is on the mark and extremely well said.
LARTing is a tough question for Jackpot (although you really should ask the author about this - I'm only giving my opinion.) If the spam is coming to the fake open relay through an open proxy (it may be) then LARTing the owner of the open proxy is a nice heads-up for him. This will in all liklihood never reduce the number of open proxies enough to matter. If the source is the spammer, himself then LARTS should go to his upstream, if that is likely to be productive. I don't think you can automate the LART/don't LART decision well enough - you have to use human judgment.
I don't know about Bayesian training. Sometimes on my (non-Jackpot) honeypot I got waves of exactly the same spam. I'd think one sample is enough for training. I (and Michael Tokarev) also sometimes trapped spam in which it looked like different parts of the spam were selected randomly from two or more equivalent but different (in checksum terms) text versions. Have twenty binary choices for the wording in the spam message and there's 1 million+ variants, all with different regular checksums (I don't know about DCC "fuzzy" checksums.) What's the impact of having 1 million different forms of the same spam on a Bayesian filter?
Note that spammer games with the content have no effect on a relay spam honeypot - it isn't content-based. Relay email through random open relays is, for legitimate email, a thing of the past. Set up a fake open relay and there is no filter needed - the spammer does the filtering for you. Well, not exactly filtering, but pretty much anything the spammer sends through an open relay is guaranteed to be spam (even more guaranteed for something sent first through an open proxy.) If it comes it's spam. No filter needed.
If the sample collected by Jackpot is too uniform to be useful for training a Bayesian filter it's all the spammers fault. Of course the spammer doesn't know he's sending to a honeypot, so if he sends the exact same spam to a honeypot he probably sends the exact same spam to true open relays and will be caught just the same.
While there is spam it seems to me that anti-spam measures at every level are needed. As the relay level has been the property of the spammers for years it seems also that acting at the relay level will have a massive payoff. By all means continue with Bayesian filters. One of the beauties of honeypots is that they stop spam aimed at a broad specxtrum of recipients, including some truly clueless ones - ones who respond to spam, ones who would never have have the wit to use any filter. Maybe they even want the spam. Too bad - the spammer chose the wrong "open relay." His fault, not yours.
Scelson was sending direct spam - maybe he stll is. He's the sort I'd anticipate might sue a honeypot operator. There's some danger of dying of laughter if that ever happens - getting sued for not allowing theft of service to occur.
Ah, Rackspace. The only ISP to ever telephone ME to lie about taking action against a spammer I reported. That's not something you forget.
Now that I think of it, they may be the only ISP that ever telephoned ME for any reason. Doesn't it seem right for alarm bells to go off in your head when an ISP telephones to report something other ISPs report by email? It did for me - I made the same spammer complaint to Rackspace's upstream when they got off the phone. Whether anything happened as a result I don't know...
There's been some indication Rackspace has been cleaning up but if they aren't clean yet (I don't know myself) then that indication doesn't correspond to what is.
Please. One DNSBL intentionally blocks non-spam sources. I agree - they're wrong in that.
Your question is a good one. No, I don't think that's how the system should work - it's dumb. But you have other options in DNSBLs than SPEWS and you have other options in fighting spam than DNSBLs. I can't prove it, I wish it weren't so, but it may be every large effort not carefully controlled by a central authority will have its share of participants that are imperfect. That doesn't tar the entire effort, does it? Don't fixate on the guys screwing up - there's a lot more guys that aren't screwing up.
I can only guess but I think I know who three of the SPEWS people are. Two I've seen posting - reasonable chaps, mostly, from what I saw. the third I think is also reasonable, mostly, but there I'm more guessing, partly on the basis of another thing he does. Even SPEWS is pretty good - they have this one quirk that diverts attention from all the rest they do that has merit. So be it - it's their choice, but I recognize they aren't all bad.
Spammers, in my case, are not thieves: I give them the bandwidth needed to get the spam TO my server. But the only reason they send the spam is because I look to them like one of those fools from whom they steal service every day - like someone who will deliver the spam (the joke is on them.) For the mass of the spam, for the spam that reaches the recipient's server, delivered or rejected, the process of getting that spam to that server is based on deliberate theft. The spammers have an out in that theft of service alone isn't a federal crime unless the value of what is stolen is $5000 or more. Overall they steal many times $5000 worth of service - just not from the same victim. It would be hard to show they steal $5000 worth from any one entity (and once the entity sees the theft it stops it, so accumulating enough to hit the $5000 mark is even harder.)
There is a small fraction of spam that goes direct from the spammers server to the victimes server. All else is some form of relay spam, and relay spam is spam based on theft of service as the delivery method. Spammers are thieves. There's a lot more to spam than what the recipient sees and experiences. I'd not be paying much attention to this discussion tonight if I had not, 3 years ago, been the victim of a relay spammer.
Right on - RFC 2505 gives good advice on not running an open relay. You, in general, do not want to be running an open rely.
RFC 2505 also says (many overlook this) that securing open relays is not the approach to use if you want to end spam. Why? Because the spammers will continue to find open relays, so even securing 99% of the servers won't stop spam. As has been the case.
There's a third reason to relay a message, if you wish to stop spam: relay the spammer's message sent to test to see if you relay. Give him the answer: "Yes, I relay." Prove it: relay his test.
Then don't relay anything else for him.
Up to now most people haven't acted this way. the result has been, as can be seen on reflection, that all the relay spam goes to systems that will relay it. Well heck, is that what you want? Sure a surprise to me if you do. In general you don't know where the open relay is, you don't know how to contact the operator, you can't get him to understand the problem and change, you are frustrated. That's because the wrong guy is in charge of the relay that gets the spam. If you were in charge it wouldn't be delivered, would it? Think of how powerful it would feel to be able to stop a batch of relay spam dead. Think of a spammer burning a whole weekend, sending spam to your dead-end relay. That is BOFH-time. BOFH-time for a good cause is quality time - give yourself that.
So. Get in charge. Set up a system that delivers the spammers' test messages and nothing else. (By the way, there's people that pop up almost every time this is said who reply that the spammers will spam themselves, see non-delivery, and drop the relay. Do the experiment and see. I can promise you neither that they will nor that they won't. You can find out. I'd be very keen to hear.) It's cheap, it's easy, you may seen something in the trapped spam that lets you really wallop the spammer, you will have a much better current picture of how spammers spam. It's very likely you'll see the relay spam coming from open proxies. spammers can run a whole chain of these, making it hard to see where they are in IP space. One of those proxies will get the connection direct from the spammer - that proxy can see where the spammer is. Open proxy honeypots are in their infancy - you can get in on the ground floor now, if you hurry.
Hmm. While I don't see "straw dummy" I can see "overblown language" in what I posted. By "brutal" I meant blocking non-spam-soure email, and "brutal" is too extreme a word.
"The serious spam harvesters would just dump all the results from your domain."
Well of course there is already Webpoison which does create spurious addresses just for harvestors. And I think I recall seeing a huge block of trapped spam on Michael Tokarev's Moscow honeypot with what looked to me like this kind of fake, generated email address. I can't remember if this was or wasn't Ralsky spam. Ralsky is, I think, a serious spam harvester.
There are also web pages on the net salted with the dropbox addresses some spammers use for their test messages. I know because I trap test messages and do Google searches on the names in the addreses. For instance, "china9988@21cn.com".
Google for china9988 - see what you find. (It's not earth-shattering but you do find people all over the world who have correctly identified spammer test message dropboxes just from the logs.) Now if you whitelisted email to the above address you'd probably soon be rejecting tons of spam, wouldn't you? Hmmm - that would be annoying on your server, what else could you do?
"no, because *your* server at the first point you have control over it."
What if the open relay operator is a BOFH? HE has control over the spam while its on his system. He gets control of the spam by inducing the spammer to regard him as an open relay. He does THAT by delivering the relay tests the spammer sends to him. He may be able to induce the spammer to send the relay tests by nominating HIMSELF to a DNSBL. If the BOFH relay operator stops the spam you'll never even see it.
Naturally the BOFH doesn't want to screw up his mail server so he does all these things on a non-mail-server IP.
Look this over again. Simple, isn't it? Once the spammers are sending you spam you can be the ultimate BOFH and get applause for doing it. Even if you act silently you can applaud yourself.
Great for the big boys, the guys who work for ISPs, companies, universities, etc. How about the poor fellow who just has a home system with a cable or DSL connection? Does he have to miss out on the fun?
No, he doesnpt have to sit this one out. There's a program just for him, if he has a JVM (Java Virtual Machine) on his system (or can get one): Jackpot.
http://jackpot.uk.net/
Depending on where you are (and it may be the home user in South America has a huge advantage in this) you may be able to stop a massive quantity of spam.
Let's see - tomorrow is New Year's Resolutions time. How about "I resolve to help kill off relay spam in 2003 - I'll run a relay spam honeypot"?
If enough make this resolution and follow through then it will truly be a Happy New Year.
"Check with me in April. spam probably won't be gone by then"
"Isn't that what I just wrote?"
You left off the "coughing up blood in the morning" part.
"That honeypot of yours is cute, but the 6000 user ISP I work for has blocked almost 4000 messages today thanks to SPEWS and other blocklists. If you want evidence just check out how many spammers there are crying their eyes out in NANAE because of SPEWS."
"Cute" isn't a bad word at all for mine - it is a nice effort but not tremendously meaningful in the battle. OTHER HONEYPOTS TRAP FAR MORE SPAM. Unless I run the honeypot I do not and can not know how much spam would come to it - I have to do the experiment.
I won't look at NANAE to see how many spammers are crying out their eyes but when I did read NANAE the spammers were few and far between - it was the collateral damage victims causing most of the threads. If it's gotten better since then then hooray for SPEWS.
You can stop 4000 spam messages FOR YOUR users. I stopped millions of spam messages for AOL, hotmail, and huge numbers of other ISPs with my prototype honeypot, at work. Michael Tokarev stopped millions of spam messages FOR OTHER ISPs with his Moscow honeypot. It should be clear that if a honeypot stops spam that would be blocked by a DNSBL at its destination it hasn't done much. You prepared to tell me that AOL has successfully blocked spam the last three years? Your DNSBLs all have to have external data to identify spam. The honeypot identifies spam simply: if it comes to it it is spam (in the preferred, non-server implementation.) Collateral damage, false posiives? Not with a honeypot. Get the ISP to throw off the spammer? Three ISPs in one weekend nuked off Ralsky on the basis of honeypot reports.
By all means use SPEWS. Don't ask everybody to wait forever for SPEWS to work. Don't ask me to wait, either. I see how spammers can be hit hard at the relay level - a level that up to now they've been able to command with ease (nobody did anything.) Spam survives - all the techniques used up to now haven't been enough. Take away the relay level and watch spam die.
1 million cute honeypots would do it. Right now there's probably 20 to 30 honeypots (some people run multiple honeypots.) 999,980 to go. It's not like that's hard.
I know of a honeypot with a truly incredible number of stopped spam messages but the owner wants me to reveal neither his location nor his count. I'm sure you would not believe me if I told you the number stopped (since February.)
The internet is awash in spammer relay test messages and in relay spam - some spam may make three or more hops before reaching the destination, multiplying the bandwidth used. The chances are excellent that more than one spammer is attempting to give you the opportunity to trap his spam (although HE doesn't see things that way.) Up to now most people have passed on that opportunity. Let's watch and see how that goes in 2003 - I'm telling people that they can, often on their simnple home systems (with cable or DSL connections) actively trap spam aimed at others. Trap enough and the spammers will quit. (Yes, I know that first they'll send more. Eventually they will quit.)
Yo - I **saw*** it. Read what I said: he spoofs the IP of a dialup from a system with a fast connection and receives the handshake packets on the dialup IP. These he communicates back to the sending system - the loop is complete. That way he can do port 25 traffic on dialups (e.g. those of uu.net) which don't allow OUTGOING port 25 traffic. The outgoing traffic is on the fast side and spoofs the dialup IP. If a succesful spam complaint is made then all he loses is the account used to do the dialup - it's a throwaway account anyway. For a while the complaints would be ignored, if the claim was made that the spam came from the dialup. Abuse at the ISP KNOWS that outgoing port 25 is disabled - it can't be a spam source. But it is, as far as the IPs indicate. The ISP DOESN'T and CAN'T block outgoing spam with it's systems' IPs when that spam goes out from another ISP.
It took a while to convince uu.net (one of the dialup ISPs.) Once they were convinced they moved right smartly.
But Ralsky never anticipated getting throwaway accounts thrown away one after the other, in just minutes. By sending the URL of the Moscow web page (the last contents can still be seen at http://www.corpit.ru/cgi-bin/h0n5yp0t) to abuse at the ISP of the dialup you give the abuse desk a tool they can use to watch for new IP addresses in their space. They only need to hit reload on their browser to see if a new IP in their space appears. Once it does they verify how it is being used (to receive return packets for spam) and nuke.
Ralsky lost three ISPs in one weekend that way - he burned all his throwaway accounts on three different ISPs. He never saw anything like that before.
Next weekend he was back - he didn't figure out how he was being hit (right about then Shiksaa, who is know to communicate with Ralsky, said in NANAE "a spammer" was begging her to get off SPEWS - it was kiling him. Would *I* tell him what was really causing him the grief? I can't be sure it was Ralsky, but that's what I'd bet.)
As far as I can tell the sending system need not ever have an IP. Even if it does it need never use it or respond to it. (This is immaterial to the scam - just observations.)
You may not see one of the morals: The spammer can be tres clever but a simple, dumb honeypot can still overthrow him. Not that Michael's honeypot was dumb - he added the brilliant idea of a web page that had a real-time log of incoming relay spam.
(More recently Michael's very simple open proxy honeypot that he wrote at about the same time fooled another spammer - it was idle for months, then a spammer hit it. Too beautiful for words, almost.)
"...how is anyone outside the ISP supposed to know that the spammer is no longer a customer?"
If you can't tell is there a problem? And you appear to claim a dead DNS entry does something - what I can't imagine.
"Free clue: Nothing will end spam."
Check with me in April. spam probably won't be gone by then but it might be "spitting up blood in the morning." Do you have some notion I propose sitting meekly and doing nothing? Hah! that's been the central policy for years, for relay spam (the one that hurts the most.) I propose NOT sitting meekly, doing nothing. Patting yourself on the back for what a clever sysadmin you are for bouncing all relay email doesn't end spam. Look at the history - it hasn't.
You want to end spam? Then end spam. The internet is awash in relay test messages and relay spam and you can't see how to stop that?
Spammer sends a test message to a bunch of IPs. A few IPs deliver the test message. Spammer concludes those IPs are open relays, spammer sends relay spam to them (now, often through open proxies.)
If YOU would deliver his test messages then he'd send the relay spam to YOU for delivery. Well? Would you deliver the spam or wouldn't you?
This is not idle theory. Right now the spammer is in charge. When will YOU be in charge, when will YOU control whether or not relay spam gets delivered? Not all, but some - others can control the rest. (I do assume you would NOT deliver the spam - that's all it takes, once you have control of it. Getting control is ridiculously easy.)
My home honeypot is pretty feeble. It's trapping spam only from the cursed Hinet spammer in Taiwan, spam directed to recipients in Taiwan. Only 665 messages since 12/20, only 6274 recipients. Others do far better - see how you can do. It did pick up some today - busiest day yet.
Here's his latest test message. It didn't even get delivered but the idiot sends spam anyway:
Message data for C0A87BB3-B80A025 (from 218.147.98.232)
250 OK
Mail from:china9988@21cn.com
250 Sender china9988@21cn.com OK
RCPT to:china9988@21cn.com
250 Recipient china9988@21cn.com OK
Data
(I had to remove the angle brackets around the addresses for them to display.)
Message:
Received: from 1217-vkztw12ofn by homebrad (ESMTP Sendmail V8); Tue 31 Dec 2002 03:03:35 GMT
From: china9988@21cn.com
Subject: 66.222.28.6
To: china9988@21cn.com
Date: Tue, 31 Dec 2002 11:55:39 +0900
X-Priority: 3
X-Library: Indy 8.0.25
t_Smtp.LocalIP
Google on china9988 - you'll see it is a known test message dropbox.
The above from Jackpot's web-page spam report.
http://jackpot.uk.net/
Obviously what you trap depends on which spammer tests your IP. Note that if they figure you out and stop testing that is still a win, particularly if they leave your whole IP block alone because of one honeypot.
Afraid to be tested? Expand your mind and your understanding. I ran an open relay (with, heh-heh-heh, special features) and I ASKED ORBS to test me - I WANTED to be listed.
There's two things you need to understand:
(1) While it was an "open relay" the "special features" blocked spam.
(2) At the time I did this ORBS was so little used by systems with which my users communicated by email that there were virtually no valid messages blocked.
Part of my collaboration with ORBS was an effort to try to see if being on the aged-ORBS list attracted spammers. I never had enough data to find out if it did or didn't, but I did get lots of relay spam to whack.
I had to grow up myself to get the good sense to ask to be tested - I started with the attitude that ORBS was an arrogant intrusion. Once I thought of ORBS as my friend I could see how we could work together to fight spam and possible defeat it. Isn't that the goal? I tire of "solutions" that aim no higher than to have a tolerable situation for oneself while spam continues rampant. Don't you?
Slashdot Mirror
"All those cable modems out there, which aren't allowed to run servers because of blazingly clueless policies by cable companies, could be running honeypots, especially teergruben [tuxedo.org], which run valid SMTP vvvv...eeee..rrr..yyyy...sssss...loooowwwww....lyy yyy"
Jackpot has a tarpit value, or tarpitting can be disabled. Jackpot will run on windows systems if a JVM is installed. Those wanting to do this to screw spammers hitting their cable/DSL connecitons should be quite pleased at the results.
http://jackpot.uk.net/
Incidentally, I push Jackpot but it is another person's project - Jack Cleaver. It's a very fine piece of software.
"These people learn quick, after their servers make their way to the open relay blacklists. Just make sure it happens every time when you receive a spam that have been apparently sent through an open relay. Forward the spam to relays@ordb.org with the first line:
"Relay: IP_address"
But I am the open relay. That's my approach. I'm only "open" for the spammer relay tests - the spam gets flushed (actually usually it is archived but as far as the spammer is concerned it's the same thing.) Jackpot will stop storing spam received form a particular IP when a specified number of spam messsages from that IP is reached.
You really ought to try Jackpot - it's a neat program. http://jackpot.uk.net/
What you say does very often apply for open proxies - a lot of spam I've trapped came first through an open proxy.
I should mention that while 235 million spam messages stopped is wonderful and impressive it isn't the focus. Spammers can send relay spam because they can easily and reliably find open relays. The real goal of honeypots is to undo that - make finding open relays difficult and unreliable. Some open relays may still relay only 50 messages/day for about 1000 recipients. Setting up honeypots in the same zone with these makes the real open relays less easy to find, and that is the real goal. We need to destroy, completely, the ability of spammers to find open relays. Causing them grief using information from trapped relay test messages is another way to make finding open relays too difficult for them.
Put enough painful traps in an IP region and the spammers will have reason to not test at all in that region. Then it won't matter if there's an open relay in the region becuase the spammers will never look there for it and won't find it.
(Sure, secure all you can, but securing them by making them honeypots is far more powerful than just bolting the door, so to speak.)
The same discussion works for open proxies and for any other TCP/IP service they decide to abuse. Punish them if they try. Drive them away. Make not bothering you (or anyone else) the course they choose. Make them suffer if they don't choose wisely.
"Also, isn't it easy for a spammer to workaround a spam honeypot -- create a hotmail account, add it to your spam list, and verify that it did go through."
Yes. So far many don't (I don't know of any that do, but spammers do, eventually, stop sending to a honeypot.) Ralsky never caught on to the Moscow honeypot that was whacking him last year (I think he's the one who told Shiksaa - visit NANAE to find out who she is - that SPEWS was killing him, just at the time of the major whacking Ralsky was getting.) (Chuckle.) I looked for spammer dropbox addresses in trapped spam 3 years ago - I figured they'd use the same address every once and a while in the list of victims. I sorted the list of recipients, sorted again, removing duplicates, and compared. No differences: each victim showed up once. They could do it, they don't. Years of experience has taught them that they can test for open relays and abuse them incautiously - nobody does anything to counter them. They think they own the internet because people ignore their attempts to relay. It's easy to knock the smirk off their faces: pay attention to illicit connection attempts.
There is a project already in motion to collect all recipient addresses for honeypot-collected spam in a central location. If any address shows up too frequently then that's a suspicious address. The real problem isn't what the spammers do or could do, it is that too few people use this very simple method to wreck the spam path.
My original honeypot went down last week (I retired in 2001; I haven't really checked to see what the current managers are doing with it.) This year I only captured relay messages, delivered nothing. When it went down last week it had captured over 100 relay test messages in January. You can also go after spammers with these (and I did - no results yet to report, I'm hoping for some big results.) Spammers could detect that - but too late.
There's a sneakier version of what you suggested that the spammers could use. I won't tell them what it is.
Volume is the key - many honeypots are needed, quickly, to whack them before they adapt. Same for open proxies. It is an absolutely simple approach. You could set up Granny's system to run a honeypot and it would work, if she has a connection to a segment the spammers search for open relays. http://jackpot.uk.net/
Try Jackpot and see for yourself, if you can.
OK, signal and noise. What if the signal was all in one frequency band and the noise all in another. Problem separating them? No.
What if, in effect, a similar distinction held for spam in the transmission channel - that spam by itself selected a pathway to the recipient that was never used by the signal? Block that pathway and the spam never gets through.
Spam doesn't select a pathway but spammers do. If you could block relay spam at the open relays it would be dead. You can't, of course - the open relays are controlled by people who don't know the need to block spam. You know that, I know that. If you can't change the people then change the open relays (from the spammers' points of view.) Set up a system that looks like an open relay and stop the spam. An open relay honeypot.
I asked an operator of such a honeypot how he did last year:
> How did 2002 end?
From March 7 to December 26 2002, the total was:
235,624,232
Using one Pentium 90 he stopped spam to 235 million recipients. Think about that number when you see filter people reporting what they stop just for their own domains. This was spam to recipients all over, not simply to the honeypot operators domain: he operates at the relay level. He stopped 100% of the spam, no deception deceived him, no tuning was needed, no valid email was caught - it is perfect filtering. Perfect filtering - who else has that?
And you can do it at home on your DSL or cable connection (the guy above uses sendmail -bd, but Windows users have a program they can use):
http://jackpot.uk.net/
Yeah, I know, spammers are switching to open proxies. So, write an open proxy honeypot. That, too, will be 100% efficient. In addition you now are giving spammers reason to fear every open relay and every open proxy they detect. FEAR. The SPAMMERS have to scramble. They have to scramble and they have to show everything they do to overcome the technique - there is no stealth way to look for open relays and open proxies.
The problem is solved, it is a matter of implementation and of getting active systems everywhere in the net space (so there's no safe IP space for the spammers anywhere.)
Remember: A single Pentium 90, 235 million spam messages stopped in 10 months.
"Personally, I think we could do a great deal to slow down spam if we stuck SMTP honeypots on port 25 andchecked out mail from a different port."
.br? Something like .000000001, I'd guess. Close enough to never to suit me.)
You've made my day. For Windows (and other JAVA environments) there's Jackpot: http://jackpot.uk.net/
Most windows users have no program that listens on port 25. Only spammers are going to be attempting connections to their port 25. The Jackpot users catch these spammers easily.
I've run a combined server/honeypot. It happened that my MTA gave filenames of different forms to local vs. relayed messsages. I could filter FOR the in-domain relayed messages and leave the rest undelivered (no matter how clever the spammer his spam didn't get out because my filter looked for valid email and delivered that. The failure mode was for some valid email to be caught - I had to examine the trapped spam periodically and improve my filter. I used exceedingly dumb algorithms - someone doing this intelligently would probably have it right the first time.)
You don't have to change ports if you run a server - just filter intelligently. Spam is exceedingly more obvious at the relay than at the destination (how many times a year would VALID relay email hit your server from a site in
"I've actually been writing my own personal SMTP honeypot for this very purpose. I don't imagine I'll have much trouble getting friends to run it."
I don't even know who your friends are but I like them tremendously already.
You need to know a little about relay tests. You can learn on the fly or go to news.admin.net.abuse.email (using Google) and look for postings with "relay test" in the subject (also in news.admin.net-avuse.sightings.) Most relay tests have your IP encoded in decimal ascii in the message-ID. Some have your IP in plain text in the subject or message body. One spammer has your IP in the body in a line that starts with MAILINFO: and then in decimal, with 111 added to 3-digit IP fields in the dotted quad, 11 added to 2-digit fields, 1 to 1-digit fields. A couple of years ago there was a spammer that encoded the IP in the serial number of a "face-painting kit" - he stole a scenario from a Seinfeld episode.
You want to deliver relay test (only.) This convinces the spammer you are an open relay. Then he sends spam. You don't deliver that, you can examine the trapped spam and find ways to hurt the spammer. A lot of relay spam now hits the open relay from an abused open proxy.
There's a real opportunity for open proxy honeypots - they also can be wicked.
A quick honeypot can be created from a standard MTA - just disable message delivery. Add to that a means for delivering the relay tests you want to deliver and you have the spammer by the b*lls.
It's good to see you thinking about port 25 and SMTP. There's value in the sorts of thing you advocate and many ISPs have done them. Spam remains - it isn't enough. Same for filters and blocklists. Something more needs to be added - spam is growing (the growth of spam is in large part the result of the success of the other methods: the spammers must send more spam to get a return.)
m sn.co m[rab]: 7bit
8 04 80571000500500460990971090451090970460991111100991 01110116114105099046110101116058
One can complain on and on about systems with unsecured port 25. That isn't solving the problem - time to stop and take a look. Spammers send relay spam, to send relay spam they must find open relays, to find open relays they send test messages. Most email system managers can tell you that they see failed relay attempts in their logs.
How much more of a clue is needed? You see that the "secure the relays" campaign isn't working, you see that the spammers test and test and test, looking for open relays. Taking them away hasn't worked - try GIVING THEM OPEN RELAYS. Partly open - ones that only deliver their test messages. Now what do the spammers do? If deceived (right now they mostly are) they send relay spam to the fake relays, where it is simply stored (one can look through the trapped spam and find ways to cuase further hurt to the spammers.) It isn't delivered, the spammer doesn't make a dime from it. No matter how clever the spammer is in disguising what he's sending it doesn't matter - the trapping is based on the spam delivery path, not on its content.
Don't want to deliver tests? OK, don't even do that. Just set up a system that captures them. I have one, I have a test message that appears to have originated within a few miles of the MIT conference the same week as the conference:
Received: from ts009d22.cam-ma.concentric.net by X.X.X;
Wed, 15 Jan 03 17:56 CST
Message-Id:[lab]049049049049049049049049049@
Date: Wed, 15 Jan 2003 18:57:16 -1700
From: candy@webname.com
Subject: pick up the phone
To: porcha@SoftHome.net
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
05405204605004604905204804604905505605811611504
I munged the system name and I changed the encoded IP of the system in the message-ID to all 1's. The numeric strings are decimal ascii: "048" is "0," etc. [lab] is a left angle bracket, [rab] is a right angle bracket.
Get enough people trapping spam and even more people trapping and reporting relay tests and you put pressure on the spammers that, up to now, they haven't felt. It is a wide-open area for using technical means to bring them down. Wide open - note that well.
In the SE part of the US is a system operator who has stopped spam to over one millon recipients so far this year.
When this idea is presented there's frequently someone who objects "but the spammers could simply put one of their own addresses in the list of spammed addresses and see if the mail got through. That way they could detect the honeypots." That's true. So far they do not do it. Even if they do there's no way they can eliminate the danger to them from trapped and reported relay tests. If they get clever and test only though open proxies then the center of activity shifts to fake open proxies. That's also easy. A couple of people (including Michael Tokarev, in Moscow) have had great success with open proxy honeypots. There's another objection that can be made. It can be overcome but I won't state it here and give spammers ideas.
Spam is not defeated. It would seem that every reasonable defense should be employed while that is true. Running fake open relays is fantastically easy and is very close to 100% perfect. Do it on an IP that has no legitimate port 25 traffic. Then everything that comes to that port 25 is spam or a relay test. Do it on a Windows system with no MTA - port 25 isn't even in use.
Run Jackpot:
http://jackpot.uk.net/
There are, uh, a few Windows systems out there?
An earlier expression of this same idea is indicated by sendmail -bd. At one time that would mean sendmail accepting but not delivering messages - now you have to od more to stop delivery attempts. In general, any MTA configured to accept anything but deliver nothing will trap relay tests. Force delivery of the relay tests before they're too old and you deceive the psammer who sent it.
END spam in 1Q2003. It has gone on far too long.
"Name one technological measure which has a zero false-positive rate, a low false-negative rate, and a snowball's chance in hell of being adopted. The problem should address spam at the server side, since it's already wasting space by the time it's allowed onto a client machine."
Relay spam honeypots. They operate at the relay level which is better than the server side since the server never sees has to deal with the spam. A relay spam honeypot has no legitimate email function - the only email that comes to it is spam. That's 0.000% false positives. It delivers only the spammers own relay tests. That's a low false negative rate - 0, for all practical purposes.
The chance of being adopted is problematic. People are so used to thinking in terms of blocklists and filters they don't expand their thinking to honeypots. But think about it: with a honeypot you may get to wallop some spammers spew on your own system. Not just a little but a lot.
My original honeypot is only a half-honeypot now - it delivers nothing. In 4 days, 6 hours it has received 27 spammer relay tests (all reported in NANAE.) In all probability if I had delivered any one of these tests I'd have gotten spam back, in volume. That would be spam for other users, spam that I'd not deliver. Wollop.
It was doing the whole bit in November. Here's a tiny sample of Subjects from that batch:
Subject: Get more energy 10260
Subject: Gain muscle and lose fat 26020
Subject: Lose weight while you sleep 26898
Subject: Lose inches 8883
Subject: Feel your Best 19718
Subject: Lose weight easily 13661
Subject: Lose inches 23016
Subject: Feel young Agian 30401
Subject: Feel your Best 20100
Subject: Feel your Best 27895
Subject: Feel young Agian 2513
Subject: Be your best 7665
Subject: Feel young Agian 3943
Subject: Gain muscle and lose fat 19581
Subject: Get more energy 17343
Subject: Build muscle and Burn fat 18488
Subject: Look and Feel Younger 20897
Subject: Feel young Agian 12503
Subject: Look your Best 6785
Subject: Look younger 10878
Subject: Feel ten years younger 3524
Subject: Lose weight while you sleep 8892
I imagine all have references to href=3D"http://14610@wwW.nutritionmatrix.com
I didn't do anything with these earlier because the disk was down until 4 days, 6 hours ago.
Yu can do this on a network-connected Windows system using Jackpot:
http://jackpot.uk.net/
Jackpot gives you a web page that lists all the spam you've gotten by source IP. People can look at every trapped spam message. You'd send the URL to people who should be looking, like ISPs.
0 false positives, 0 false negatives, no external database, no training, no particular skill - good enough? I think so.
Last year I had the (somewhat) good fortune to capture relay spam from a spammer who used reply-to addresses at freemail providers to receive his responses. Good fortune? Yes. The spammer had large numbers of these - most (maybe all) appeared in spam I captured. A simple string search and a single email message to the freemail provider got all of the accounts nuked. That spam run was largely lost to the spammer.
c om +group:*.*.*.email+author:brad&hl=en&lr=&ie=UTF-8& selm=3C7B0714.749B048D%40mail.tds.net&rnum=1
But what I'd like to mention is that if the freemail provider paid much attention at all to patterns in the logs I think it could fairly easily identify many spammer dropboxes.
Additionally I'd like to mention that rather than nuke the account I'd prefer the freemail provider simply blackhole any mail to that account - nuking tells the spammer the account is dead, he moves on. If nuking isn't in accord with the TOS then I suggest changing the TOS.
One example, listing Reply-to addresses:
http://groups.google.com/groups?q=snowboarding.
"This is just your broken filtering, which you insist on keeping broken. Your broken filtering isn't my problem. It is trivial to filter on the IP address in the Received Header. Even if the spammer inserts some additional forged headers, their real IP address is still there, and will be
... One aspect of stupid is "If 90 percent of spam is blocked we'll just send 10 times as much." The distinction I'm making, while imprecise, is between the millions-of-addresses-CD type of spam and spam that's modeled on traditional bulk-mail advertising. The DMA wants the latter to be allowed.)
found on an IP address RBL."
I have the advantage in this discussion of having trapped relay spam at the relay - I can see the headers, I can log the actual source IP. At the beginning of 2002 a lot of relay spam did come direct from the spammer - many spammers try very hard to obscure their own IPs (even the spam I'm trapping now has HELOs with forged IP numbers in them - that deceives some MTAs, I think.) Now I think it is far more typical for spam to arrive at the relay from an open proxy someplace (South America being a very common "someplace.") In that case you don't see the spammers IP at all - you see, at best, the IP of the open proxy. There's millions of those - most probably aren't yet listed by any RBL. The spammer may add fake headers that show a source at AOL or elsewhere - these are pure fiction.
During one long period of trapping relay spam I observed that it was all directed to AOL addreses. At that time AOL didn't (apparently) use any RBL or local equivalent - all that spam would have reached the recipient if it had not been trapped at the relay. DNSBLs do not stop all spam (if for no other reason than that many ISPs don't use them.) Filters don't stop all spam (my ISP uses Brightmail - I get classic 5-report chain-letter spam, still.)
In any case there are two aspects to stopping spam: stopping spam to you (or to your users) and stopping spam, period. The major efforts right now are directed to stopping one's own spam. It isn't working well enough to stop spam overall. If spam is to be stopped by technical means it had better happen soon - the DMA backs an anti-spam bill and that could become law this year. If that happens the odds are great that the "stupid" spam will end in a year or so - the law wil work against that. That will open the gates for a flood of "respectable" spam that the law will grnadly declare legitimate. Maybe the law would forbid blocking of such spam. Few sane email users should want that.
("Stupid spam" isn't precisely defined, but it's the common crap you now get: porn, organ enlargement, Viagra, mortage, debt consolidation,
"Yes, they almost never have valid return addresses so they never know whether the mail gets there or not. The just have stats based on hits on sites and web bugs in html mail. So the answer is yes, they do send long term to blocked addresses. There were some stats on that, how much actual spam was being blocked by spews, for example."
Don't forget that two different things are done by SPEWS and that the argument is over only one of these. Blocking spam is something SPEWS does well - may they continue to do so as long as needed. Blocking non-spam to pressure non-spammers to do something (SPEWS apologists aren't crystal-clear in their explanation of this) is abusive and wrong-headed. The impression I have is that they have perhaps done only a few hundred such blockings in their history, making essentially no progress in fighting spam. They have made many innocent users associated with the blocked IPs associated aware of SPEWS. Awareness could be good, but the majority of those made aware now hate SPEWS, and, by extension, all DNSBLs and all anti-spammers. OK, maybe not all of either but the actions and attitude of SPEWS and its backers pisses off real, normal people.
For other than huge ISPs most could block most of the net and cause little problem. If there's no email coming from all those blocked IPs then the blocks do nothing that stops spam. They don't hurt, don't help - are immaterial. Add to that lunatics who take the complaints of legitimate mailers as signs that blocking aimed at non-spam sources is having a good effect and you have a rotten situation. It would be seemly for the SPEWS blockers who claim that the customers of the ISP have more clout to actually test that claim and document their results. My suspicion is that a spam-tolerant ISP is not measurably more affected by complaints from customers than from non-customers. They know what they are doing and intend to continue. Harrassing their non-spamming customers does not end spam and diverts effort away from something that might have an effect into something that doesn't. Add to this the apparent frequent occurrence of SPEWS targeting ISPs who are not spam-tolerant but who have, by error (and the perfidy of spammers) gotten a spammer in their space and you have SPEWS grandly attacking targets that are not in any way the main source of the spam problem. In addition, Doesn't SPEWS, when it takes on a large ISP such as Verio, only list non-spam-source IPS in some subset of the blocks belonging to that ISP? Weird.
When the popular press discusses SPEWS and states that what SPEWS is doing is wrong it appears that the SPEWS apologists take the attitude "screw the popular press." Last time I looked in NANAE that's how it was, at least. That is not going to win SPEWS any friends (not any worth having, at least), is not going to win DNSBLs any friends (look at this thread), not going to win anti-spammers any friends.
The solution is for SPEWS to stop listing IPs of non-spam sources. They probably won't soon embrace that situation. Until they do they will receive well-deserved criticism and contempt. It's clear that SPEWS, during it's more than one year of existence, has not stopped spam. They don't have a highly-successful track record to point to as evidence that they are correct - they just sit quiet and let people weave lies about how effective SPEWS is. I'd like to flat-out decree that no one ever again use the good results SPEWS achieves by blocking spam sources to justify the blocking of non-spam sources. The decree won't work - SPEWS apologists will continue to pop up with that illogical defense - there's apparently no way to get them to use logic instead of emotion.
I'd also like to decree that those who block only for their own email not cite their perfect satisfaction as sufficient grounds for ISPs with large numbers of customers using SPEWS. It is two different situations - you are free to screw with your own email any way you please - why not? That this works for you has no bearing on whether it is good for an ISP to inflict SPEWS on its customers. The LOGICAL thing to come out of satisfaction with SPEWS for single-user IPs is to say SPEWS should be used only by single-user IPs. THEN if an important email message is blocked because of the SPEWS policy of listing non-spam source IPs the one suffering the consequences will be the one who decided to use SPEWS. That's just.
(SPEWS-supporters who delude themselves into thinking they've said something smart by responding that "SPEWS doesn't block anyone, SPEWS only lists" are welcome to do so. The issue is that of valid email blocked because some ISP used SPEWS. Your cute little objection doesn't speak to the issue - it's just noise.)
You have described the situation perfectly - I hope many people see and understand what you say about SPEWS (including those who run SPEWS). My point was that most DNSBLs don't do the idiotic blocking of non-spam sources.
Not only do I have no quarrel with what you say I think what you say is on the mark and extremely well said.
Thanks.
LARTing is a tough question for Jackpot (although you really should ask the author about this - I'm only giving my opinion.) If the spam is coming to the fake open relay through an open proxy (it may be) then LARTing the owner of the open proxy is a nice heads-up for him. This will in all liklihood never reduce the number of open proxies enough to matter. If the source is the spammer, himself then LARTS should go to his upstream, if that is likely to be productive. I don't think you can automate the LART/don't LART decision well enough - you have to use human judgment.
I don't know about Bayesian training. Sometimes on my (non-Jackpot) honeypot I got waves of exactly the same spam. I'd think one sample is enough for training. I (and Michael Tokarev) also sometimes trapped spam in which it looked like different parts of the spam were selected randomly from two or more equivalent but different (in checksum terms) text versions. Have twenty binary choices for the wording in the spam message and there's 1 million+ variants, all with different regular checksums (I don't know about DCC "fuzzy" checksums.) What's the impact of having 1 million different forms of the same spam on a Bayesian filter?
Note that spammer games with the content have no effect on a relay spam honeypot - it isn't content-based. Relay email through random open relays is, for legitimate email, a thing of the past. Set up a fake open relay and there is no filter needed - the spammer does the filtering for you. Well, not exactly filtering, but pretty much anything the spammer sends through an open relay is guaranteed to be spam (even more guaranteed for something sent first through an open proxy.) If it comes it's spam. No filter needed.
If the sample collected by Jackpot is too uniform to be useful for training a Bayesian filter it's all the spammers fault. Of course the spammer doesn't know he's sending to a honeypot, so if he sends the exact same spam to a honeypot he probably sends the exact same spam to true open relays and will be caught just the same.
While there is spam it seems to me that anti-spam measures at every level are needed. As the relay level has been the property of the spammers for years it seems also that acting at the relay level will have a massive payoff. By all means continue with Bayesian filters. One of the beauties of honeypots is that they stop spam aimed at a broad specxtrum of recipients, including some truly clueless ones - ones who respond to spam, ones who would never have have the wit to use any filter. Maybe they even want the spam. Too bad - the spammer chose the wrong "open relay." His fault, not yours.
Scelson was sending direct spam - maybe he stll is. He's the sort I'd anticipate might sue a honeypot operator. There's some danger of dying of laughter if that ever happens - getting sued for not allowing theft of service to occur.
See subject. That's a lot of the objection to spam - the recipient has to pay for it even though the recipient doesn't want it.
(This is old information, of course. I just couldn't resist the opportunity to turn the subject around.)
Ah, Rackspace. The only ISP to ever telephone ME to lie about taking action against a spammer I reported. That's not something you forget.
Now that I think of it, they may be the only ISP that ever telephoned ME for any reason. Doesn't it seem right for alarm bells to go off in your head when an ISP telephones to report something other ISPs report by email? It did for me - I made the same spammer complaint to Rackspace's upstream when they got off the phone. Whether anything happened as a result I don't know...
There's been some indication Rackspace has been cleaning up but if they aren't clean yet (I don't know myself) then that indication doesn't correspond to what is.
Please. One DNSBL intentionally blocks non-spam sources. I agree - they're wrong in that.
Your question is a good one. No, I don't think that's how the system should work - it's dumb. But you have other options in DNSBLs than SPEWS and you have other options in fighting spam than DNSBLs. I can't prove it, I wish it weren't so, but it may be every large effort not carefully controlled by a central authority will have its share of participants that are imperfect. That doesn't tar the entire effort, does it? Don't fixate on the guys screwing up - there's a lot more guys that aren't screwing up.
I can only guess but I think I know who three of the SPEWS people are. Two I've seen posting - reasonable chaps, mostly, from what I saw. the third I think is also reasonable, mostly, but there I'm more guessing, partly on the basis of another thing he does. Even SPEWS is pretty good - they have this one quirk that diverts attention from all the rest they do that has merit. So be it - it's their choice, but I recognize they aren't all bad.
Spammers, in my case, are not thieves: I give them the bandwidth needed to get the spam TO my server. But the only reason they send the spam is because I look to them like one of those fools from whom they steal service every day - like someone who will deliver the spam (the joke is on them.) For the mass of the spam, for the spam that reaches the recipient's server, delivered or rejected, the process of getting that spam to that server is based on deliberate theft. The spammers have an out in that theft of service alone isn't a federal crime unless the value of what is stolen is $5000 or more. Overall they steal many times $5000 worth of service - just not from the same victim. It would be hard to show they steal $5000 worth from any one entity (and once the entity sees the theft it stops it, so accumulating enough to hit the $5000 mark is even harder.)
There is a small fraction of spam that goes direct from the spammers server to the victimes server. All else is some form of relay spam, and relay spam is spam based on theft of service as the delivery method. Spammers are thieves. There's a lot more to spam than what the recipient sees and experiences. I'd not be paying much attention to this discussion tonight if I had not, 3 years ago, been the victim of a relay spammer.
Right on - RFC 2505 gives good advice on not running an open relay. You, in general, do not want to be running an open rely.
RFC 2505 also says (many overlook this) that securing open relays is not the approach to use if you want to end spam. Why? Because the spammers will continue to find open relays, so even securing 99% of the servers won't stop spam. As has been the case.
There's a third reason to relay a message, if you wish to stop spam: relay the spammer's message sent to test to see if you relay. Give him the answer: "Yes, I relay." Prove it: relay his test.
Then don't relay anything else for him.
Up to now most people haven't acted this way. the result has been, as can be seen on reflection, that all the relay spam goes to systems that will relay it. Well heck, is that what you want? Sure a surprise to me if you do. In general you don't know where the open relay is, you don't know how to contact the operator, you can't get him to understand the problem and change, you are frustrated. That's because the wrong guy is in charge of the relay that gets the spam. If you were in charge it wouldn't be delivered, would it? Think of how powerful it would feel to be able to stop a batch of relay spam dead. Think of a spammer burning a whole weekend, sending spam to your dead-end relay. That is BOFH-time. BOFH-time for a good cause is quality time - give yourself that.
So. Get in charge. Set up a system that delivers the spammers' test messages and nothing else. (By the way, there's people that pop up almost every time this is said who reply that the spammers will spam themselves, see non-delivery, and drop the relay. Do the experiment and see. I can promise you neither that they will nor that they won't. You can find out. I'd be very keen to hear.) It's cheap, it's easy, you may seen something in the trapped spam that lets you really wallop the spammer, you will have a much better current picture of how spammers spam. It's very likely you'll see the relay spam coming from open proxies. spammers can run a whole chain of these, making it hard to see where they are in IP space. One of those proxies will get the connection direct from the spammer - that proxy can see where the spammer is. Open proxy honeypots are in their infancy - you can get in on the ground floor now, if you hurry.
For Windows users (and others with a JVM):
http://jackpot.uk.net/
Hmm. While I don't see "straw dummy" I can see "overblown language" in what I posted. By "brutal" I meant blocking non-spam-soure email, and "brutal" is too extreme a word.
I could say more, and did. I removed it.
Happy New Year.
"The serious spam harvesters would just dump all the results from your domain."
Well of course there is already Webpoison which does create spurious addresses just for harvestors. And I think I recall seeing a huge block of trapped spam on Michael Tokarev's Moscow honeypot with what looked to me like this kind of fake, generated email address. I can't remember if this was or wasn't Ralsky spam. Ralsky is, I think, a serious spam harvester.
There are also web pages on the net salted with the dropbox addresses some spammers use for their test messages. I know because I trap test messages and do Google searches on the names in the addreses. For instance, "china9988@21cn.com".
Google for china9988 - see what you find. (It's not earth-shattering but you do find people all over the world who have correctly identified spammer test message dropboxes just from the logs.) Now if you whitelisted email to the above address you'd probably soon be rejecting tons of spam, wouldn't you? Hmmm - that would be annoying on your server, what else could you do?
"no, because *your* server at the first point you have control over it."
What if the open relay operator is a BOFH? HE has control over the spam while its on his system. He gets control of the spam by inducing the spammer to regard him as an open relay. He does THAT by delivering the relay tests the spammer sends to him. He may be able to induce the spammer to send the relay tests by nominating HIMSELF to a DNSBL. If the BOFH relay operator stops the spam you'll never even see it.
Naturally the BOFH doesn't want to screw up his mail server so he does all these things on a non-mail-server IP.
Look this over again. Simple, isn't it? Once the spammers are sending you spam you can be the ultimate BOFH and get applause for doing it. Even if you act silently you can applaud yourself.
Great for the big boys, the guys who work for ISPs, companies, universities, etc. How about the poor fellow who just has a home system with a cable or DSL connection? Does he have to miss out on the fun?
No, he doesnpt have to sit this one out. There's a program just for him, if he has a JVM (Java Virtual Machine) on his system (or can get one): Jackpot.
http://jackpot.uk.net/
Depending on where you are (and it may be the home user in South America has a huge advantage in this) you may be able to stop a massive quantity of spam.
Let's see - tomorrow is New Year's Resolutions time. How about "I resolve to help kill off relay spam in 2003 - I'll run a relay spam honeypot"?
If enough make this resolution and follow through then it will truly be a Happy New Year.
"Check with me in April. spam probably won't be gone by then"
"Isn't that what I just wrote?"
You left off the "coughing up blood in the morning" part.
"That honeypot of yours is cute, but the 6000 user ISP I work for has blocked almost 4000 messages today thanks to SPEWS and other blocklists. If you want evidence just check out how many spammers there are crying their eyes out in NANAE because of SPEWS."
"Cute" isn't a bad word at all for mine - it is a nice effort but not tremendously meaningful in the battle. OTHER HONEYPOTS TRAP FAR MORE SPAM. Unless I run the honeypot I do not and can not know how much spam would come to it - I have to do the experiment.
I won't look at NANAE to see how many spammers are crying out their eyes but when I did read NANAE the spammers were few and far between - it was the collateral damage victims causing most of the threads. If it's gotten better since then then hooray for SPEWS.
You can stop 4000 spam messages FOR YOUR users. I stopped millions of spam messages for AOL, hotmail, and huge numbers of other ISPs with my prototype honeypot, at work. Michael Tokarev stopped millions of spam messages FOR OTHER ISPs with his Moscow honeypot. It should be clear that if a honeypot stops spam that would be blocked by a DNSBL at its destination it hasn't done much. You prepared to tell me that AOL has successfully blocked spam the last three years? Your DNSBLs all have to have external data to identify spam. The honeypot identifies spam simply: if it comes to it it is spam (in the preferred, non-server implementation.) Collateral damage, false posiives? Not with a honeypot. Get the ISP to throw off the spammer? Three ISPs in one weekend nuked off Ralsky on the basis of honeypot reports.
By all means use SPEWS. Don't ask everybody to wait forever for SPEWS to work. Don't ask me to wait, either. I see how spammers can be hit hard at the relay level - a level that up to now they've been able to command with ease (nobody did anything.) Spam survives - all the techniques used up to now haven't been enough. Take away the relay level and watch spam die.
1 million cute honeypots would do it. Right now there's probably 20 to 30 honeypots (some people run multiple honeypots.) 999,980 to go. It's not like that's hard.
I know of a honeypot with a truly incredible number of stopped spam messages but the owner wants me to reveal neither his location nor his count. I'm sure you would not believe me if I told you the number stopped (since February.)
The internet is awash in spammer relay test messages and in relay spam - some spam may make three or more hops before reaching the destination, multiplying the bandwidth used. The chances are excellent that more than one spammer is attempting to give you the opportunity to trap his spam (although HE doesn't see things that way.) Up to now most people have passed on that opportunity. Let's watch and see how that goes in 2003 - I'm telling people that they can, often on their simnple home systems (with cable or DSL connections) actively trap spam aimed at others. Trap enough and the spammers will quit. (Yes, I know that first they'll send more. Eventually they will quit.)
Yo - I **saw*** it. Read what I said: he spoofs the IP of a dialup from a system with a fast connection and receives the handshake packets on the dialup IP. These he communicates back to the sending system - the loop is complete. That way he can do port 25 traffic on dialups (e.g. those of uu.net) which don't allow OUTGOING port 25 traffic. The outgoing traffic is on the fast side and spoofs the dialup IP. If a succesful spam complaint is made then all he loses is the account used to do the dialup - it's a throwaway account anyway. For a while the complaints would be ignored, if the claim was made that the spam came from the dialup. Abuse at the ISP KNOWS that outgoing port 25 is disabled - it can't be a spam source. But it is, as far as the IPs indicate. The ISP DOESN'T and CAN'T block outgoing spam with it's systems' IPs when that spam goes out from another ISP.
It took a while to convince uu.net (one of the dialup ISPs.) Once they were convinced they moved right smartly.
But Ralsky never anticipated getting throwaway accounts thrown away one after the other, in just minutes. By sending the URL of the Moscow web page (the last contents can still be seen at http://www.corpit.ru/cgi-bin/h0n5yp0t) to abuse at the ISP of the dialup you give the abuse desk a tool they can use to watch for new IP addresses in their space. They only need to hit reload on their browser to see if a new IP in their space appears. Once it does they verify how it is being used (to receive return packets for spam) and nuke.
Ralsky lost three ISPs in one weekend that way - he burned all his throwaway accounts on three different ISPs. He never saw anything like that before.
Next weekend he was back - he didn't figure out how he was being hit (right about then Shiksaa, who is know to communicate with Ralsky, said in NANAE "a spammer" was begging her to get off SPEWS - it was kiling him. Would *I* tell him what was really causing him the grief? I can't be sure it was Ralsky, but that's what I'd bet.)
As far as I can tell the sending system need not ever have an IP. Even if it does it need never use it or respond to it. (This is immaterial to the scam - just observations.)
You may not see one of the morals: The spammer can be tres clever but a simple, dumb honeypot can still overthrow him. Not that Michael's honeypot was dumb - he added the brilliant idea of a web page that had a real-time log of incoming relay spam.
(More recently Michael's very simple open proxy honeypot that he wrote at about the same time fooled another spammer - it was idle for months, then a spammer hit it. Too beautiful for words, almost.)
"...how is anyone outside the ISP supposed to know that the spammer is no longer a customer?"
If you can't tell is there a problem? And you appear to claim a dead DNS entry does something - what I can't imagine.
"Free clue: Nothing will end spam."
Check with me in April. spam probably won't be gone by then but it might be "spitting up blood in the morning." Do you have some notion I propose sitting meekly and doing nothing? Hah! that's been the central policy for years, for relay spam (the one that hurts the most.) I propose NOT sitting meekly, doing nothing. Patting yourself on the back for what a clever sysadmin you are for bouncing all relay email doesn't end spam. Look at the history - it hasn't.
You want to end spam? Then end spam. The internet is awash in relay test messages and relay spam and you can't see how to stop that?
Spammer sends a test message to a bunch of IPs.
A few IPs deliver the test message.
Spammer concludes those IPs are open relays, spammer sends relay spam to them (now, often through open proxies.)
If YOU would deliver his test messages then he'd send the relay spam to YOU for delivery. Well? Would you deliver the spam or wouldn't you?
This is not idle theory. Right now the spammer is in charge. When will YOU be in charge, when will YOU control whether or not relay spam gets delivered? Not all, but some - others can control the rest. (I do assume you would NOT deliver the spam - that's all it takes, once you have control of it. Getting control is ridiculously easy.)
My home honeypot is pretty feeble. It's trapping spam only from the cursed Hinet spammer in Taiwan, spam directed to recipients in Taiwan. Only 665 messages since 12/20, only 6274 recipients. Others do far better - see how you can do. It did pick up some today - busiest day yet.
Here's his latest test message. It didn't even get delivered but the idiot sends spam anyway:
Message data for C0A87BB3-B80A025 (from 218.147.98.232)
250 OK
Mail from:china9988@21cn.com
250 Sender china9988@21cn.com OK
RCPT to:china9988@21cn.com
250 Recipient china9988@21cn.com OK
Data
(I had to remove the angle brackets around the addresses for them to display.)
Message:
Received: from 1217-vkztw12ofn by homebrad (ESMTP Sendmail V8); Tue 31 Dec 2002 03:03:35 GMT
From: china9988@21cn.com
Subject: 66.222.28.6
To: china9988@21cn.com
Date: Tue, 31 Dec 2002 11:55:39 +0900
X-Priority: 3
X-Library: Indy 8.0.25
t_Smtp.LocalIP
Google on china9988 - you'll see it is a known test message dropbox.
The above from Jackpot's web-page spam report.
http://jackpot.uk.net/
Obviously what you trap depends on which spammer tests your IP. Note that if they figure you out and stop testing that is still a win, particularly if they leave your whole IP block alone because of one honeypot.
Afraid to be tested? Expand your mind and your understanding. I ran an open relay (with, heh-heh-heh, special features) and I ASKED ORBS to test me - I WANTED to be listed.
There's two things you need to understand:
(1) While it was an "open relay" the "special features" blocked spam.
(2) At the time I did this ORBS was so little used by systems with which my users communicated by email that there were virtually no valid messages blocked.
Part of my collaboration with ORBS was an effort to try to see if being on the aged-ORBS list attracted spammers. I never had enough data to find out if it did or didn't, but I did get lots of relay spam to whack.
I had to grow up myself to get the good sense to ask to be tested - I started with the attitude that ORBS was an arrogant intrusion. Once I thought of ORBS as my friend I could see how we could work together to fight spam and possible defeat it. Isn't that the goal? I tire of "solutions" that aim no higher than to have a tolerable situation for oneself while spam continues rampant. Don't you?