Greylisting with Postfix (and other antispam stuff).

Posted by simonw on Fri 24 Jun 2005 at 19:35

The postgrey package is a greylisting implementation for postfix. It is a breeze to set-up and stopped 99.99% of my spam in conjunction with blacklisting.

First back-up everything - just in case! ;)

You should let any users you have know that greylisting may delay the odd email, or otherwise pacify the end user community (Tip: offer them free software if they need compensating for delayed email).

As root or your preferred way of getting root privileges....

apt-get install postgrey

You should have a policy server running on port 6000 of localhost, check with netstat.

# netstat -anp | grep 60000
tcp        0      0*               LISTEN     18478/
Now you need to add a line to /etc/postfix/ to tell Postfix to use the new postgrey policy daemon. Since this is a restriction on SMTP traffic you need to add the following to "smtpd_recipient_restrictions";
check_policy_service inet:

Now reload postfix; postfix reload (me being a lazy luddite often runs /etc/init.d/postfix restart which is slower, but saves remembering which changes require what sort of restart, and what the syntax for this particular service is).

The only gotcha is that if the default Greylist text isn't right for you, then you probably want to read about this Debian bug 298832 to save some frustrating attempts to edit the text issued. This mostly affects people with many domains, where "postmaster@" isn't the preferred address for support, or to preserve corporate identity.

Postgrey is reliable - very - but you want to know if it is not running as Postfix will defer email if it can't speak to a policy daemon. Set up some sort of test!

Greylisting isn't for everyone. Postgrey by default has some exceptions for email servers that don't behave, and accounts to exempt in /etc/postgrey, and you can of course use these to whitelist servers. After 5 successful deliveries (by default) postgrey will whitelist a server, so you quickly get a whitelist of trusted servers, some people suggest reducing this default from 5. There is a script in /usr/share/doc/postgrey/postgrey_clients_dump which lists the whitelisted servers, it doesn't have execute permissions so you have to;

# perl /usr/share/doc/postgrey/postgrey_clients_dump

The documentation directory also has contact details for the mailing list - it is very quiet - I think it just works. Beware greylisting will delay things like password emails for signing up to thing like this website, but for many this is a price worth paying for the relief from spam.

Hand in hand with greylisting is blacklisting. Part of the idea with greylisting is to delay the spammer till others have identified the poor exploited spambots. I looked around and picked the SBL-XBL blacklist. Again a restriction on SMTP so to the "smtpd_recipient_restrictions" add;


You'll have to read the documentation to figure out what order to put your "smtpd_recipient_restrictions", as order can matter terribly - you've been warned.

That single one line change is estimated to stop 60% of spam!

The other restriction I use is implemented by adding this line to /etc/postfix/;
mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp
Where the file /etc/postfix/mime_header_checks.regexp has;
   REJECT For security reasons attachments of this type are rejected.
      REJECT Attachment type not allowed. File "$2" has the unacceptable extension "$3"

Note that is only two lines if you cut and paste it.

This is just taken and hacked from earlier examples on the Postfix mailing list, there may be better ways. This hasn't caught much email recently till I added ".zip" to the list, you may well not want the ".zip" (or other types), but I was getting many many viruses with .zip for every genuine attempt.

Currently the Greylisting and RBL stop virtually all the virus email traffic, so the MIME type filtering is almost unneeded, but I figure the few extra viruses caught will save some antivirus program (or end user) a little bit of effort. If the regular expression change worries you, leave it out.

It may have taken a fair bit of explaining, but with the addition of one package, a three line change to, and two regular expressions, the advice in this article should stop the vast majority of spam. At least till the spammers start emulating SMTP servers. I still, alas, get the Nigerian scams - seems they just use disposable email accounts on real email servers. Greylisting also doesn't handle backscatter if people spam in your name, but it can spread the pain on your email server.

The Postfix site has some advice on dealing with backscatter from the author of Postfix himself, and the SPF guy has written a policy server for Postfix to use SPF. But I haven't had a chance to get my head around these yet.



Posted by gonad (203.118.xx.xx) on Fri 24 Jun 2005 at 20:39
Great artical. One thing to fix:


should be in "smtpd_client_restrictions"

[ Parent | Reply to this comment ]

Posted by Anonymous (66.92.xx.xx) on Sat 25 Jun 2005 at 03:23
Actually there is one school of thought that it is beneficial to place most of the restrictions in smtpd_recipient_restrictions. Unless you have set smtpd_delay_reject = no (yes is default) no actual rejecting takes place until after RCPT TO in the SMTP exchange.

You can find this issues discussed on the postfix mailing list somewhere I'm sure. It's also mentioned in this Postfix Anti-UCE Cheat Sheet

which is worth looking at I think.

[ Parent | Reply to this comment ]

Posted by hildeb (193.175.xx.xx) on Mon 4 Jul 2005 at 13:20
Not necessarily, and with the default setting for smtpd_delay_reject = yes it makes no difference at all.

[ Parent | Reply to this comment ]

Posted by Anonymous (67.172.xx.xx) on Wed 29 Jun 2005 at 21:45

Another good trick is to check for sites claiming to be you in your helo_checks file.    ACCEPT # Bob works from home and runs
                      # his own mail server

localhost      REJECT    REJECT    REJECT

There's no legitimate reason for other sites to use either your domain name or IP address, but a lot of spamware does, so there's no risk in cutting them off at the knees.

As for 'localhost', I've seen it in the wild. It may be a legitimate but unconfigured mail server, but nobody has squealed yet.

[ Parent | Reply to this comment ]

Posted by hildeb (193.175.xx.xx) on Mon 4 Jul 2005 at 13:21
ACCEPT is not a valid access(5) right hand side.

[ Parent | Reply to this comment ]

Posted by Anonymous (67.172.xx.xx) on Wed 29 Jun 2005 at 22:18

It looks like you can use the auto-whitelist to identify persistent spammers. They would probably be caught by an RBL, but I prefer to have full control over which sites are blocked.

Take that list, verify their website promises exciting offers (or better yet the front page itself is the "opt-out" form) and toss them into a Postfix map.

[ Parent | Reply to this comment ]

Posted by simonw (212.24.xx.xx) on Fri 11 Nov 2005 at 10:00
[ View Weblogs ]
The headline figure that I kept trying to get right was 98.9%, not the rather generous figure in the article.

I'm currently getting the first preliminary figures of deploying same configuration, with the addition of rejecting emails with unknown sender domains, on another server, which does a lot of forwarding of emails.

Initial figures show about ~50% less emails delivered/sent by this server for the same domains.

However the figures vary widely by domain, for those domains actively used for email, I see slightly under 50% reduction in email delivered/forwarded. For one domains almost totally unused for genuine email the figure dropped from 468 a day to 14 in the first full day (~97%). Which suggests that it is stopping a lot of email, and that it is predominantly stopping junk email.

We've got one confirmed report in 3 days of an MTA not retrying, this time it was running Exim.

Worryingly one of our worst spammed domains is seeing some email from what looks like spambots getting through fairly regularly. I do hope this isn't a sign of spammers creating greylist proof spambots.

[ Parent | Reply to this comment ]

Posted by bellerofont (212.76.xx.xx) on Wed 11 Jan 2006 at 18:17

As we all know it's possible to reject many UCE messages at smtp time.
Of course I use other methods for filtering spam(greylisting, policyd...),
but I think that it's still a good idea to enhance the postfix rules.
Currently I have a few nice and helpful rules, but I'd like
to have some more :-). I've been searching along Google
for something new, but mostly I've seen things that I already have.
So I wonder if some of you may share their postfix header checks
and mime header checks with me? I'd be very thankful.
You may post it here or(for privacy) send it to me via e-mail.
My address is: marcin.waligorski at gmail dot com.
If'd receive a lot of interesting stuff, then I'll sure
sort it and then it could become a nice article for this site
and help the others :-).

[ Parent | Reply to this comment ]

Posted by joss (216.153.xx.xx) on Wed 1 Mar 2006 at 17:34
I am having trouble getting this to work

I installed postgrey

then ran netstat -anp |grep 6000

tcp 0 0* LISTEN 30839/

then I add
check_policy_service inet:

to under
smtpd_recipient_restrictions =

but when a message comes in I get the following in my mail.log

Mar 1 11:23:40 abyss postfix/smtpd[23994]: warning: connect to Connection refused
Mar 1 11:23:40 abyss postfix/smtpd[23994]: warning: problem talking to server Connection refused

I know I am missing something silly but this is just one of those days.

Any help would be much appreciated,


[ Parent | Reply to this comment ]

Posted by joss (216.153.xx.xx) on Wed 1 Mar 2006 at 18:54

I knew I was being silly.

I had postgrey running on 60,000 but postfix was trying to talk to 6,000.

So, a zero here or there does mater.

sorry for the noise,


[ Parent | Reply to this comment ]

Posted by sphaero (83.160.xx.xx) on Sat 14 Oct 2006 at 09:31
[ View Weblogs ]
A remark about greylisting is that when you are using multiple dns MX entries with different priorities greylisting will cause all mail to be send to the backup mx. I don't know if running greylisting on all mailservers will make the mail to be send to the primary mx again. But for me it seems this greylisting is not really an option when involved with multiple MX records.

[ Parent | Reply to this comment ]

Posted by simonw (84.45.xx.xx) on Sat 14 Oct 2006 at 10:02
[ View Weblogs ]
First, most people don't need multiple MX records these days, and deploying them makes email administration more complex, and much more error prone, for very limited if any gain. I've seen that "not one of my domain" error once too often, and that I haven't seen it more often is because most genuine email never hits a backup MX server. These days the backup MX also needs a list of all the valid recipients for a domain (or some form of recipient validation proxy service), which has added to the management nightmare they represent.

The reason for backup MX servers was to help cope with unreliable network connections, and connections where email was a substantial part of the network bandwidth usage. Conditions that haven't applied for over a decade for most people.

Okay some people run multiple MX servers local to the main server for coping with volume, or availability purposes, but in this case sharing the greylisting data is usually quite easy.

The first big change I did for the domains at work, was work out the SQL statement to delete all the backup MX records across 600 odd domains that had them. Since the email servers weren't validating the recipients they were a dreadful source of backscatter, and were getting over 999:1 ratio of spam to ham, because the primary mail servers were generally available. Indeed the main reason for the primary mail servers being busy was when the backup email servers dumped another bulk load of spam on them.

But if you have multiple MX servers I'm sure greylisting is possible, although it is probably more logical these days to have a failover system for a backup email server, where one changes the primary MX, or fails its IP address across.

[ Parent | Reply to this comment ]

Posted by Anonymous (85.18.xx.xx) on Thu 4 Jan 2007 at 19:09
great article.
really simple and to the point.

[ Parent | Reply to this comment ]

Posted by Anonymous (80.60.xx.xx) on Fri 5 Jan 2007 at 11:54
Well it al sounds pretty easy and the steps were also no problem but if I am trying to recieve mail, it doens't work. I see this in my logs:

Jan 5 12:39:54 terminator postfix/smtpd[29030]: NOQUEUE: reject: RCPT from xxxxxx[xxxxxxxxxxx]: 450 <xxxx>: Recipient address rejected: Greylisted for 60 seconds (see; from=<xxxxxxxxxxxx> to=<xxxxxxxxx> proto=ESMTP helo=<xxxxxxxxx>

Anybody knows know to solve this?

[ Parent | Reply to this comment ]

Posted by Anonymous (80.108.xx.xx) on Mon 15 Jan 2007 at 22:45
This just informs you that the message has been greylisted.

Quite good to know when you're searching for certain stuff... like when a client claims that you are loosing mail... but mail doesn't just get lost.

[ Parent | Reply to this comment ]

Posted by axel1973 (85.216.xx.xx) on Thu 25 Oct 2007 at 11:33
Hi there! THANKS FOR YOUR ARTICLE! Quick n Easy ... but....

somehow im not sure that thing is working for me. i mean.. i installed postgrey, i can see it runs as a stand alone process (ps aux), i can see its listening on TCP 60000 (nmap or netstat, both show a listening process), i can see starting/stoping messages from postgrey and postfix in my logs if i restart the services.

however i have not seen ANY log message mentioning "postgrey" or "has been greylisted" messages ANYWHERE in mail.log, syslog or messages files. neither seen anything like postfix forwards the request to the postgrey server.. nothing.. i even enabled VERBOSE logging at the postfix smtpd.

so im pretty unsure if this thing is realy working as expected!

i run my server under a dyndns hostname. u can try yourself!


my email Adress is

pls send me spam :) maybe then i can see that it is working. :)

i can send in logs or config on request.

[ Parent | Reply to this comment ]

Posted by axel1973 (85.216.xx.xx) on Thu 25 Oct 2007 at 12:52
some snaps of my /etc/postfix/

mydestination = weisweil.lan, localhost.lan, localhost,, freiburg, weisweil, freiburg.lan
### Antwort an den sendenden Server wenn Empfaenger nicht bekannt
# 450 - Try again later - server versucht es spaeter nochmal
# 550 - reject mail - lehnt die mail endgueltig ab
#unknown_local_recipient_reject_code = 450
unknown_local_recipient_reject_code = 550
mynetworks =
SMTPD_recipient_restrictions = permit_mynetworks,
check_policy_service inet:

snap of my /etc/postfix/

# Postfix master process configuration file. For details on the format
# of the file, see the Postfix master(5) manual page.
# ================================================================= =========
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ================================================================= =========
smtp inet n - - - - smtpd -v

all i can see at /var/log/mail.log is:

mail.log.old:Oct 24 16:55:08 localhost postgrey[14252]: Binding to TCP port 60000 on host
mail.log.old:Oct 24 16:55:08 localhost postgrey[14252]: Setting gid to "118 118"
mail.log.old:Oct 24 16:55:08 localhost postgrey[14252]: Setting uid to "114"
mail.log.old:Oct 24 17:00:32 localhost postgrey[14252]: 2007/10/24-17:00:32 Server closing!
... whenever i restart postgrey.

[ Parent | Reply to this comment ]

Posted by Anonymous (24.126.xx.xx) on Tue 25 Mar 2008 at 17:25
axel, you have reject_rbl_client in your config file. That domain was discontinued in Dec 2006. You are just unnecessarily generating DNS traffic.

[ Parent | Reply to this comment ]

Posted by axel1973 (85.216.xx.xx) on Wed 26 Mar 2008 at 06:59
hi there. thanks fer reply.

the ORDB entry has been removed meanwhile. this was some old entry of 2004 or 2005. however the major problem has been fixed too.

problem was some invisible charakters within the config file made the config file fail and did not parse correctly. a "postconf" showed that some parameters has not been committed to the service. so some "rewriting" of the config file solved the problem.


[ Parent | Reply to this comment ]

Posted by meritol (151.53.xx.xx) on Sun 3 May 2009 at 10:05
It possible config postfix to use greylist only in any mailbox?

[ Parent | Reply to this comment ]

Posted by simonw (84.45.xx.xx) on Sun 3 May 2009 at 17:22
[ View Weblogs ]
Postgrey will let you exempt addresses and domains in its configuration files, which I think is a tidier approach.

Otherwise I think you could do it in postfix classes, but that is more difficult to ensure the right thing is done.

[ Parent | Reply to this comment ]

Posted by Anonymous (173.230.xx.xx) on Sun 12 Sep 2010 at 07:03
DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration.

[ Parent | Reply to this comment ]

Sign In







Current Poll

What do you use for configuration management?

( 104 votes ~ 0 comments )



Related Links