Slashdot Mirror

The only truly effective spam prevention technique I've seen is greylisting.

I swear certain websites do this with passwords sometimes. I use a keyboard macro for a couple web sites including a gmail account, and every once in awhile I have to try twice to log in, because I get told my password is incorrect. Unless my keyboard is mistyping the macro or the server is producing the wrong error, I'm thinking they will reject first attempts sometimes to prevent brute force attacks.

The only truly effective spam prevention technique I've seen is greylisting.

I have an email address that relies on greylisting. http://www.greylisting.org/

Years ago, at first, I would get 3 or 4 spams.

Now I get 150 in 12 hours. Spambots are becoming more RFC compliant and resending after a 5xx or 4xx error. And instead of simply firing off *one* copy, I get 3 or 4. Previously spambots had been all fire-and-forget with no resending. Legitimate mail is dwarfed. And while my filtering on my mail client picks off the spam, I always still have to vgrep the trash for false positives.

So instead of seeing my spam decrease, like this article would have me believe, I have seen the opposite. Indeed, in the last 6 months, the load has quadrupled.

What I want to know is when are we going to start boiling these bastards in pitch?

--
BMO

Greylisting.

http://www.greylisting.org/

My mail server uses that along with a trained CRM114 spam filter, and I get virtually no spam. Since most spam is sent from zombie machines, it will reject e-mail from unknown servers with a "try again later" response. Valid MTA's will re-send the message, but infected machines sending spam usually won't or can't re-send the message. Servers that DO re-send get 'greylisted' and their messages get through first time after that.

It's a little annoying having up to an hour or two delay on some e-mails, but if there's something I need urgently, I'll just get it sent to Gmail.

There are lots of different greylist implementations, with different configuration abilities and defaults.

It should be possible to configure the greylist server to have only a five-minute (or even one-minute) waiting period, which is much more reasonable than 15 minutes.

I have noticed that greylisting isn't quite as effective as it once was, because lots of spammers are actually using real queueing mail senders now. But it still has a lot of effectiveness.

See http://greylisting.org/ for more details on the concept. I personally use postgrey.

Doesn't change the from address. And if it did, that'd make me a bit more likely to be filtered, I'd bet.

Greylisting is a simple method of defending electronic mail users against e-mail spam. In short, a mail transfer agent which uses greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again to send it later, at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried, however, even spam sources which re-transmit later will be more likely to be listed in DNSBLs and distributed signature systems such as Vipul's Razor. Greylisting requires little configuration and modest resources. It is designed as a complement to existing defenses against spam, and not as a replacement.

You can start here http://www.greylisting.org/

There are many implementations of this technique so take your pick.
I myself use SQLgrey together with Postfix. It works wonders.

I thought SPF had lots of potential when I first heard about it but as I looked at real examples of how people use their email it started to become apparent pretty quickly that there were big problems.

Just one example - as I travel about I take the old powerbook with me and sometimes hook into various networks to send email. Of course these days, to stop spam, many ISPs filter port 25 so that you can only use their email server to relay your message - no problem, but now your email is not coming from one of the systems listed in your SPF record. Yes, if I had VPN infrastructure I could use that. If I had the mail server listening on a different port as well I could use that but all of it is breaking the ubiquity of email - its like saying, to send a letter in the post with the corporate letterhead you have to first send it back to the main office we will put it in the envelope and send from there.

I think if you are blocking on SPF records you are lining yourself up for a world of hurt. Its far from obvious that domain admins will remember to update these lists when they deploy new email servers (tis obvious when we haven't updated MX - mail doesn't arrive - SPF different).

That's why I concluded best I could so with SPF was add weight to a spamassassin score - it's worth something, but blocking just on this would deep six too much legitimate email.

Greylisting on the other hand is a simply awesome technique. Although all the mail scanning product vendors like to deride it (I suspect because it works so well that their product become far less marketable), it does the very thing that we have been talking about - raises the amount of effort required to send a spam email - and it does so using features of the SMTP protocol meaning that 99.99% of the email servers on the Internet will be able to cope with it no problems. Even that minute amount of (normally windows) MTAs that don't understand are still normally okay, because when the person follows up with the "why didn't you respond to my first email" email, it passes through by virtue of the rules of greylisting.

Yes - I know the spammers will one day have a workaround but so what - this is an arms race and for the moment greylisting is one of the most effective and easy tools in the toolkit.

http://www.greylisting.org/

For more info.

This is already done. It's called graylisting. Here's a website about it. Basically, you examine the unique combination of sender, recipient, and IP. The first time they connect, you return a "temporary failure" message. You continue doing this for a period of time (maybe about one hour), and then you accept the mail. The idea is that spammers, who use bulk-mailing programs, won't have the time or reason to resend a message, but that normal, well-behaved mail servers will. (This also means graylisting has to be employed on the mail server where the mail gets in. Once a "real" mail server receives the message, graylisting can't help.) I use Sneakemail, which is similar to Spamgourmet but a little more featureful, and it offers optional graylisting of addresses. I've used it on the (not spam armored) address posted on my website/blog, and it has filtered every piece of spam so far.

Its a simple idea whereby your server exploits the fact that most mail servers obey the SMTP standard, while most spam sending software does not, to only accept mail from servers which behave properly. Plugins are available for most popular mail server software.

I implemented this about 6 weeks ago and noticed a dramatic and immediate reduction in spam, perhaps better than any other single anti-spam measure.

Yeah, greylisting is superb as a first-pass filter. It's cheap, it's fast, it's completely automatic, and above all, it will reject the spam before you've even received it --- which means it's not taking up any bandwidth! If you have a spam problem, getting a greylister is the first thing to try.

As TFA says, check out greylisting.org for more information. This is also a good site. If you want a greylister, I strongly recommend Spey: it's an SMTP proxy that sits between your existing MTA and the outside world, and so will work on anything. I think it's particularly good because, er, I wrote it...

http://greylisting.org/implementations/postfix.sht ml

There are numerous other greylisting implementations out there on this same webpage. The OpenBSD folks have been putting a lot of effort into their own lately-- if I'm not mistaken, you can get spamd to rewrite pf rules on the fly. This guy has a writeup.

Also check out Vipul's Razor and DCC, which are distributed. I currently use both of these with SpamAssassin when evaluating scores for email.

PS. If you're wondering about load-- we get about 85k email messages a day, and between two dual Xeons (2.something GHz) in a round-robin config, we rarely crack more than 95% idle.

I use a triple approach of greylisting, SpamAssassin and ClamAV. Spam and viruses gone. I've since changed jobs but a few months ago I was using this approach for about 1500 email accounts. I'd say we were blocking 95% of the spam. Some users went from 50+ a day to 2 a week.

If you have anything to do at all the administration of your mail server then I would suggest looking into greylisting. Has helped tremendously with the volume of spam I receive to the server I admin because it forces spammers to use a single point to send spam from (a point which you can identify).

Also ClamAV can be used to scan incoming email on the server side and has definitions for many phishing attacks as well as worms and viruses.

The logic is that a if a spam zombie is the source, they would just react to a problem by going to the next victim. A legitimate server will store the e-mail and try again.

Very few ISPs are so clueless that they don't queue and retry when they get a 4xx response (indicating a tempory failure). There are a few, but not man.

Yes, it's annoying to find out someone has done it better than you, before you. But that's one of the hazards of the modern age. It's called GreyListing (Or Graylisting if you like the american spelling). It takes advantage of the fact that spam programs generally have very primitive SMTP implementations and when they receive a 'temporarily unavailable - try again later' message, they will just consider the message undeliverable. Greylisting works by keeping a database of destination email address/sending IP address, and the first time a given combination of the two is seen, it is given a 'come back later' message for ten minutes or whatever. It works pretty well. But I wouldn't use it as my only line of defense against spam.

I added greylisting to my mail server, and that cut down on both spam and virus messages by a tremendous amount. See http://greylisting.org/ for more info.

That plus a combination of blocking senders on the Spamhaus SBL and doing greylisting, which I put in place on my mail server a few months ago, has dropped my personal spam volume to about one every week (out of about 600 a day that try to get through.) Most spams are stopped by the SBL and the greylisting, which is great because very little bandwidth is wasted. Greylisting blocks a lot of viruses too (ClamAV takes care of the rest.)

Needless to say, I won't be installing any HashCash systems on my mail server any time soon. For the moment, until spammers get a lot more sophisticated, they're pretty much stopped dead in their tracks by a combination of existing, widely-deployed technologies.

• Local access lists. Every serious SMTP MTA supports access control based on IP address, reverse DNS, attested address (HELO), and so forth.
• DNSBLs and other sorts of published blocklists. A DNSBL is nothing but a site's IP-address access list, published over the DNS so that others can use it.
• Protocol enforcement techniques such as greylisting. Greylisting tests that the sending host is willing to make the effort of retransmitting, as required by the protocol.
• Content filtering. Even a server-side antivirus program is a content filter; much more so the statistical filters often used today.
• Multi-site statistical tools. Vernon Schryver's DCC and Vipul's Razor come to mind.
• Traffic limiting. ISPs can restrict the number of SMTP messages a host can send per day or hour.

Many of these techniques can be adapted to VoIP systems. I am surprised that SER and Asterisk do not already support DNSBLs -- even if there is no call for them yet, we will certainly need published lists of abusive hosts or networks within a few years.

The flexibility with which one can express access restrictions is an important part of any system's security. My workplace is just starting a VoIP deployment. I want to be able to say things like:

• No single outside host may make calls to more than 50 different destinations in a day.
• No host may send more than ten pending SIP invites at any time. (Prevent predictive dialing!)
• No host may send SIP IMs to more than 20 addresses in the same minute.
• After an inbound call is completed, the recipient can dial *666 on our Asterisk PBX to report it as an abusive call. If five different addresses report abusive calls from the same originator, that originator is flagged and blocked for 24 hours.

As mentionned in other posts, he's describing http://greylisting.org/. Even if spammers adapt their software, the beauty of the system is that by the time the message is resent, it's probably already in a distributed spam database, so spamassassin will give it a higher score than if it had been accepted the first time around.

I've been using it and it cut my SPAM significantly with only minimal problems (broken mail servers not resending messages after a temporary failure). With the reporting tool included, it's easy to check for legitimate messages that were not resent.

Since you already reject mail with a temporary failure, you should look into using greylisting. More info is available at http://greylisting.org/. As you're using postfix, check out Postgrey at http://isg.ee.ethz.ch/tools/postgrey/. I've been using it for a while and I'm extremely satisfied with it as it's cutting the amount of SPAM significantly. With the report tool, it's pretty easy to see if legitimate mail wasn't resent.

In my experience a catch-all has worked out well. While I do see dictionary attacks constantly at work, I don't think I have ever seen one on my personal domain. I am not sure why, but I can think of many possible reasons. One being that I have a .org instead of a .com or .net. In that isps with lots of customers use .com or .net, but generally not .org. Another is that there may be some minimal number of addresses from the same list for them to dictionary attack it. Overall my domain doesn't seem to really be on the spammers' radars. I do get spam to root@, postmaster@, sales@, etc.

An even better method than a classic catch-all would be a extension catch-all. ie something+(anything)@domain.com instead of (anything)@domain.com. An example jsmith+amazon@domain.com. You can do this with many MTAs and the two most common extensions are + and -. - will work more universally, but if users want some-thing@domain.com as an e-mail address it won't work with - as the extension. Supposedly a few uncommon e-mail clients, and a few very uncommon mtas have a problem with it.

The best method I have for cutting down spam is a greylisting, http://www.greylisting.org/. It cut spam down in volume from 10x real mail to 1x. So instead of 90% of mail being spam, 50% of mail is spam.

Usually DNS records take 24 hours for changes to propogate across the whole of the net. Some blacklists pickup spammers in the same kind of timeframe. So as a spammer, you'll have a very small window of opportunity from the moment your DNS records are valid to the moment you're on a distributed blacklist.

A lot of spam we see comes at work from people with no reverse IP address. I would dearly love to block all mail from sources without a proper DNS setup, but there are too many legit correspondents out there.

Greylisting is one solution we're looking at, where you give a temporary failure to incoming mail. Wait for a while, see if someone is still trying to send you that mail. If they are, chances are at least they're not a zombie ADSL PC.

If only the original authors of SMTP could have seen the mess we're in now.

see http://www.greylisting.org

I have a few domain for free
WUSB.Com is Free
Think of it as Open Source for Domains

We have given several FREE domains to great groups:
Vancouver Oracle Users Group
Greylisting (anti-Spam)
Jabber Software
Xaml .Net
Open Wiki

Please mod this UP.
This is an honest offer to support the Open community