
There is two main configuration files in /etc/postgrey: whitelist_clients and whitelist_recipients.
In whitelist_clients, you can define a list of mail server that you do not want to greylist. Either because there are hosts that you trust, or because there are host that it is an issue to greylist.
Client addresses can be specified as follow:
In whitelist_recipients, you can specify a list of recipients that you do not want to apply greylisting on.
Recipient addresses can be specified as follow:
Earlier on, I told you that postgrey was greylisting mails for 5 minuntes if it is the first time a triplet client_ip/sender/recipient has been seen or if the last time the triplet was seen was more than 35 days ago.
Well, those settings can be changed when starting postgrey daemon. On a Debian Like system, those settings are in /etc/default/postgrey.
By default, this file contains:
POSTGREY_OPTS="--inet=127.0.0.1:60000"
Now let's imagine you want to greylist mails for 2 minutes, and allow a known triplet to bypass greylisting if it successfully went through greylisting less than 20 days ago, you will need to use the following settings:
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=120 --max-age=20"
Also, postgrey offers a nice neat feature which is the ability of whitelisting triplet that have successfully attempted to deliver mails 5 times (default value) after greylisting was done and if the client was last seen before --max-age.
Default value can be change with --auto-whitelist-clients. Setting this to 0 will disable that feature.
If you want to override that value, same as above, modify /etc/default/postgrey and set --auto-whitelist-clients to your needs, like for instance:
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=120 --max-age=20 --auto-whitelist-clients=10"
Postgrey is shipped with a tool called postgreyreport. Using postgreyreport you can get a report of triplet than did not pass the greylisting step (meaning that the difference in first and last time seen is less than --delay=N and therefore it might have been a spam).
To get a report, you can use the following command line:
#cat /var/log/mail.log | postgreyreport \
--nosingle_line --check_sender=mx,a --show_tries \
--separate_by_subnet=":===============================================================================================\n"
This will output somthing like:
:===============================================================================================
unknown XXX.XXX.XXX.XXX
1 spammer1@spammer1.com user1@host1.com
1 spammer2@spammer2.com user2@host2.com
1 spammer3@spammer3.com user3@host3.com
:===============================================================================================
unknown YYY.YYY.YYY.YYY
1 spammer4@spammer4.com user4@domain1.com
:===============================================================================================
unknown ZZZ.ZZZ.ZZZ.ZZZ
1 spammer5@spammer5.com user1@host1.com
1 spammer6@spammer6.com user1@host1.com
1 spammer7@spammer7.com user2@host2.com
:===============================================================================================
Postgrey is really easy to install and you get a pretty efficient job done as soon as you enable it. The only backdraw one could see from it is the fact that the first email from a specific sender is going to be delayed for at least 5 minutes (or your --delay settings).
If this is an issue for you, you should fill free of adding a list of trusted (whitelisted) domain senders in /etc/postgrey/whitelist_clients .
But anyway, if you can bare the 5 minutes, people your are exchanging mail with often, will soon get into the autowhitelisted entries and you won't suffer the delay anymore.








Spanish translation
Hello Chantra, I make spanish translation of your article at my site, http://www.pastelero.net/2006/12/21/postfix-y-postgrey-un-acercamiento-a-la-lucha-proactiva-contra-el-spam/
If you have any problem whith this, please tell me.
Bye.
No bother at all
Hi Angel,
Thanks for telling me.
This is cool, hopefully, this is going to help even more people than it might have by only being in english.
Debuntu
in real life
Postgrey is an efficient tool and I've managed to reduce SPAM by about 80%. However, spammers tend to use zombie hosts and botnets and it's only a matter of time unless they've adopted. Furtheemore, you have to consider that there are hosts with extremely long retransmission times, some of them with 12 to 24 hours and there are non-rfc-compliant hosts that start no retransmission at all.
Hi Benjamin, Yeah, I agree
Hi Benjamin,
Yeah, I agree with you to say that spammers will come over that, but still, at the moment, it is an efficient way to reduce the amount of spams getting to your inbox in the first place.
This is actually why I said at the beginning of the article that postgrey won't replace spam filtering tools such as spamassassin, but it is a great way to get rid of a good amount of spams in the first place.
Considering the hosts which are not 100% RFC compliant, this is where whitelist_clients comes to be handy. This file already contains a subset of non RFC compliant known hosts. If it happens that you get troubles receving email from a specific host, you just need to add this client to whitelist_clients.
regards
Debuntu
Greylisting 'only' clients that are listed in RBLs.
You might want to try also marbl by orangegroove.
It will greylist only those clients that are listed in RBLs.
http://www.orangegroove.net/code/marbl/
Regards,
Jett
Greylisting = Welcome Back
Greylisting = Welcome Back in Snail-Mail Century.
no so snail
Lol,
Well, not really. It might be delayed on the first attempt, but then as the triplet does get whitelisted, mails are not delayed anymore.
Debuntu
Something useful to remember
Something useful to remember is the "warn_if_reject" restriction. This allows you to test your restriction is working properly, without actually rejecting mail. It's easy to make mistakes, and testing helps avoid them.
In addition, with postgrey (or any greylisting implented using a postfix based policy server), it allows you to effectively "pre-load" it with a set of IP addresses (as postgrey still sees them) during testing. Once you're confident that you've seen a fair bit of regular mail, and that the logs say it's working correctly, you can then remove the "warn_if_reject" to make it work the way it was intended.
Effectively this allows you to prime the database of greylisted IP's, which at least initially helps to get around delivery lag for commonly seen addresses. This is very useful if you're using greylisting in a business setting, as someone will always complain that they sent mail just after you enable greylisting, and that it's not getting through.
Note that "warn_if_reject" needs to go immediately before the restriction you're trying to test. For more info on this restriction, see http://www.postfix.org/postconf.5.html#warn_if_reject
Good to know
Thanks Cefiar for this tip.
I believe (but haven't tried yet) that the syntax in our example should look like:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, warn_if_reject check_policy_service inet:127.0.0.1:60000This is definitely handy to be able to build up your postgrey database before taking any action.
Thanks again.
Debuntu