Hey,

Is there a way to check local_recipient_maps from within smtpd_recipient_restrictions? Is this a good idea? The reason is, I'm using greylisting for one of my client's mailservers. The greylisting program we're using is GLD, which stores everything in MySQL. I'd like to optimize the smtpd_recipient_restrictions so that the the SQL database is hit less frequently (it's been 24hrs, and it already has 7500 records). It doesn't seem to make sense to greylist the user if we're just going to reject him later on down the road).

smtpd_recipient_restrictions =
hash:/etc/postfix/protected_destinations,
permit_mynetworks,
reject_unauth_destination,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_unauth_destination,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
check_policy_service inet:127.0.0.1:2525

Does your GLD has automatic whitelisting? Postgrey has this and makes everything automatic and transparent. Greylisting happens only during the very first appearance of the "triplets" and purely intended only to fail zombies and not legitimate MTAs. So greylisting has no meaning and significance with legitimate or even with spam relays.

To completely or to almost eradicate spam and malware, we still need to combine amavisd-new together with spamassassin and clamav. These tandems well with postfix and makes things automatic and simpler.

Although, I'm now suspicious that at this time certain bots were now rewritten to counter greylist by retrying after its own predefined period. Bots might be now acting like MTAs.

With regards to the later, there is a contributed patch for postgrey and postfix that enables postgrey to tarpit by combining some regexp lines and to further delay automatic whitelisting and requires that clients retry twice after a greylist.

http://k2net.hakuba.jp/targrey/index.en.html

As for me, this one works efficiently and makes things simpler for us admins.

-------

GLD does automatic whitelist, more or less. It keeps track of the number of times an email has been received from that ip and sender. If it's < 1 then it allows it to come in.

However, I'm weary of using greylisting. After only one day of use my client is reporting that email is not coming in. I grepped the logs and sure enough, some major company's email servers aren't resending emails after being greylisted. If that's the case, I can't see greylisting being a viable anti-spam measure.

The other problem is huge email services like Gmail. Gmail has dozens (hundreds?) of different IPs. I don't see how you can whitelist them all. With GLD you can ignore the last octet, but I'm not so sure that will always work.

Justin

I took a look at the S25R patch, and it's interesting. I think it would solve some of the false positives, since it only greylists dynamic addresses. However, I can't really use tarpitting on my server, due to the postfix sleep() issue (I can't patch this server).

So let me make sure I understand the basic configuration when using this patch. If all I want is the S25R stuff, I don't need to change any of the commandline parameters, right? And the only thing I need to add to the postfix config is:

check_client_access regexp:$config_directory/permit_client_nots25r

Am I missing anything else?

Justin

I don't have this issue using Postgrey. Postgrey has a handy list, included by default of the world's non-cooperative MTA that doesn't retry. Why don't you try to use Postgrey or get its source tar ball and get the lists of those MTAs.

Postgrey doesn't even have issue with any gmail smtp servers.

In CentOS I thought its hard or maybe not possible. This is the reason why I always prefer Slackware with this kind of application. I can compile anything I want and the way I want it and customization is what you would love with Slackware. And adding Rgrey - S25R + Tarpit + Postgrey, is easily done. (1) Patch postfix with the sleep() patch; (2) recompile postfix; (3) patch Postgrey with S25R; (4) install & configure Postgrey the way it should be then finally put this line: check_client_access regexp:$config_directory/permit_client_nots25r in your smtpd_recipient_restrictions and your done.

In fact in our mail server, I'm using this anti-spam mechanism as well combined with amavisd-new, spamassassin and clamav and we haven't receive even a single spam and malware. In one of my clients, a government hospital, this is the same anti-spam that that protects their exchange server since August last year. And of course, this is running on Slackware.

In your case you can try to use the original S25R. This one does not require any patch and it just need all the six regexp lines placed in a file and called on within smtpd_recipient_restrictions' check_client_access. Although, I'm not so sure about the level of its false positives.

http://www.gabacho-net.jp/en/anti-spam/

In case you haven't included yet these parameters within your main.cf, kindly use this. This is a handy anti-spam mechanism built within postfix.

-------

Thanks for the help. I looked over the patch itself and realized that it actually only implements tarpitting. All of the S25R stuff is in the postfix configuration. This is great, b/c I can continue to use gld on their server. And on my server I don't have to bother with patching postgrey.

In fact, it's been running like that for an hour or so, and seems to be doing exactly what it's supposed to. On my server I also run amavisd-new, clamav, and spamassassin. I just need to tweak the configuration for my client's network. I think it'll be necessary... they get an immense amount of spam.

CentOS isn't the problem with installing the postfix patch. I'm sure it could be done easily. The issue is that I prefer to use the built-in RPMS rather than installing from source. I do this because I manage a lot of servers, and I like to use CentOS's built-in automatic update functionality. This allows me to roll out security updates MUCH faster. It's a pain when I start using patched software.

Again, thanks a lot for the help and recommendations. I think this will work well for stopping spam without false positives.

Good thing about this method is that it works during RCPT TO and hence, no spam from zombies would be able to reach DATA and no SPAM messages would be sent to your gateway. This would greatly unload your MTA performing deeper scanning and detections of spam and malware and as well would unload your internet bandwidth.

Reports shows that spam coming from zombies comprises 80% of all spam on the wild. But based on my continued observation through the help of this anti-spam system, it's even more and ever growing. Nowadays, spam relays are getting fewer and zombies are the wildly used medium of proliferating spam.

This method intelligently rejects zombies and any type of spam that it carries as well are rejected. Further, since it works during RCPT TO and through regexp, it uses very low hardware resource.

-------