Greylisting in Plesk

[Nerion@]

Hello,

could you please integrate Greylisting in Plesk and QMail, because Spam takes a lot of time today.
And if you integrate it by yourself and perform a plesk-update you have to integrate it again.

And please give the user the ability to switch on/off greylisting.

I think many Plesk-User just waiting for Greylisting in Plesk.

Thank you.

 

[Nerion@]

For everyone waiting for greylist in plesk too.

I get this answer from Parallels Support

You are absolutely right about number of users who is awaiting for this feature, and because of that we do already work on making this feature available in the nearest versions of Plesk.
Thank you for letting us know your opinion, we highly appreciate it!

 

[breun]

Atomic Rocket Turtle has qgreylist packages that are compatible with Plesk.

 

[Nerion@]

Hello,

where can I download this packages. And is this only a package for qmail or with a controlpanel where users can change there settings?

Is this for Debian 3.1 and 4.0 too?

Thank you

 

[atomicturtle]

greylisting packages are available for CentOS, Fedora and RHEL. Add the atomic archive:

wget -q -O - http://www.atomicorp.com/installers/atomic |sh

and run:

yum install qgreylist

 

[Nerion@]

Thank you, but our systems are all running Debian.

 

[atomicturtle]

The src.rpm is here: http://3es.atomicrocketturtle.com/packages/qgreylist/ if you want to give porting it a shot. Its not a terribly sophisticated package, it shouldn't be too much trouble.

 

[Nerion@]

Thank you, but I wait for the hole integration by parallels.
If Parallels integrate Greylisting User could change there settings over the plesk panel.

 

[faris]

also check out www.spamdyke.org which installs in less than 5 mins. You compile it so it does not matter what OS you use.

There's an excellent howto on the forums here somewhere. search for spamdyke

Faris.

 

[Nerion@]

spamdyke is really nice. We install it on nearly every server.

 

[tiramisu_]

will wait in 8.4 or 9.x =))

 

[Amin Taheri]

I think grey listing is not a great solution. If lots of people will implement it then spammers will just change their stuff to retry - its not that hard for them to do it now, there is just not much of a need.

Not to mention this adds latency on real emails which will cause users angst in getting their email in a timely fashion. it is better to invest in a spam filter then to use grey listing in my opinion.

 

[Nerion@]

Greylisting is a great solution because spammers haven't enough server power and free Traffic to wait for answers of the mailservers.

 

[Amin Taheri]

Most server admins think greylisting is the greatest thing since sliced bread and it will solve all their issues - and it may for a couple of months. But it wont last. Server power is cheap enough that they will have it soon enough, and if enough people use grey listing they will get it anyways just becuase that is the only reason grey listing even remotely works.


The main thing though is most clients do not want to have grey listing becuase it causes a delay in them recieving email. If they have a delay of even a few minutes some customers think about cancelling and moving some where else. A better and more permanent solution would to be to invest in a spam filter and just keep your rules updated so that no matter what spammers do or regardless of how they send email it will still catch viruses, spam, phishing, etc.

jsut my opinion and 1.5 cents

 

[atomicturtle]

I concur, greylisting is a nice feature in your overall anti-spam program, but it is hardly the silver bullet everyone makes it out to be. I put its effectiveness on my systems around 3-5% over the last 24 months.

 

[stupidnic]

I feel compelled to add my opinion to this discussion.

I have spoken to Atomic in great length over IRC about the effectiveness of greylisting. I think we both came to the conclusion that it isn't a panacea, but more so a necessary piece of a much larger layered solution.

The problem really stems from how qmail deals with incoming email recipients. By default it accepts anything for a domain that is in its rcpthosts file, and then attempts to deliver it. If that user doesn't exist, it then generates a bounce which is probably sent to an email address that doesn't exist, creating a double bounce (this is also called "backscatter"). Each of these messages increases the amount of work that the system must process for each message.

Now couple this with a dictionary based attack on a particular domain name that is hosted under Plesk and it doesn't take long before you have a pretty big problem. I have personally experienced this problem on a couple of servers. It is possible to change some of the settings in qmail to cope with situations like this, but they only help to a certain extent (doublebounceto, aliases, and sending things to /dev/null).

In each of the instances where we have experienced these sorts of dictionary based attacks, or just tons of spam (think 5000 messages an hour) installing greylisting has greatly reduced the load and processing time that qmail spends processing messages.

The thing to keep in mind with greylisting is that spammers are all about sending out the maximum number of messages per minute. The higher this number is, the higher their return is (it is simple law of averages). Many spammers won't bother with retrying to send messages (as other have eluded to this will change if it becomes a clear benefit to them) because it lowers their total messages sent count, which in turn lowers their overall profit (because at the end of the day it is all about money).

What we use is a layered solution that uses greylisting at the SMTP level to reject initial connection attempts (based on IP, sender - which is highly randomized, to the spammers detriment, and recipient). If the message does make it through then we use spamassassin to inspect the message and determine its spam content level (with the spamassassin downloading new rules on a nightly basis).

This particular setup works very well because greylisting acts as a check valve allowing the highly CPU intensive process of SpamAssassin scanning to handle a relatively low volume of messages that make it through greylisting (which again, makes the message easier to trace because it has to come from the same IP and sender twice which makes SpamAssassin more effective overall).

Getting back to the original question... for Debian you can install greylisting using the instructions here:

http://meshier.com/2006/09/18/adding-greylisting-support-to-qmail-on-plesk-8/

Be sure to read the comments as they outline a couple of errors in the installation instructions. Also be sure to search for ExpressColo in the comments as I have provided some additional patches to the code base to deal with some by passes spammers were using to get around greylisting.

I have on my todo list to create a nice how to on installing greylisting, and then coupling it with an updated SpamAssassin setup that uses a new version of SA that allows you to download updated rules from http://saupdates.openprotect.com/ (also in Debian).

Anyways... good luck.

 

[Amin Taheri]

If your machine is processing that many emails per hour it may be prudent to either offload the email processing to another machine so that your web and email servers are different, or to put an inline device on your network that does your email scanning and then passes the good stuff through. That inline device can be clusetered or load balanced as needed, and provides no customer detriment in delayed message delivery, while still having the same benifits of spam reduction on the mail box level, and system load reduction on your customer facing servers.

 

[stupidnic]

You have obviously never used a Barracuda box, if you think there is no delay using something like that then you are mistaken.

While I certainly agree that what you discuss is a proper setup, this _is_ a Plesk based discussion and for most operators, I think, this would not be a cost effective approach, nevermind something that wouldn't work together with Plesk's default configuration. (Add a domain to plesk, then go and configure the mail cluster... sort of defeats the purpose of Plesk.)

Also throwing more hardware at a problem that can be handled in software isn't cost effective either.

I understand you don't like greylisting, everybody is entitled to their opinion. I just think that you are exagerating the delay. To date we haven't had any customers complain about the delay because they never notice it (normally chalking it up to "the internet being slow" I assume), but perhaps you have more technically savy users then we do.

 

[atomicturtle]

You could use a Project Gamera box for that, it has a client/server setup to automatically update its config off a plesk box. Breun has been merciless in hassling me to make that work better.

My personal strategy when latency is an issue is to use greylisting on the higher level MX in a project gamera cluster since the spammers will typically target that first. Here are some stats on that kind of set up:

Project Gamera box #1, MX 0, no greylisting
Total mail for the month: 1,267,321
Total spam for the month: 1,118,281

Project Gamera box #2, MX 100, with greylisting
Total mail for the month: 2,236,425
Total spam for the month: 1,940,719

Pretty crazy numbers huh? This reflects the mail processed by the system, so PG #2 is showing the mail getting past greylisting. One of the conclusions I draw from this is that the spammer MTA's are the ones that target the higher MX, and ergo the ones greylisting should be the most effective against. Clearly, at least in this sample, it is not as effective as hoped.

Second observation, the fact that qmail will accept mail for any email address could be a positive thing in a global sense. Plesk servers waste spammers time, and poison their spam lists by accepting all those messages. This could potentially be reducing overall spam because of that. (Trying to find a silver lining here )

 

[breun]

You could use a Project Gamera box for that, it has a client/server setup to automatically update its config off a plesk box. Breun has been merciless in hassling me to make that work better.

Yeah, there were some problems with that client/server setup. I eventually got it to work, but I reverted this setup after I wrote myself a script to automatically generate the morercpthosts and smtproutes files from our PowerDNS database.