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 60000tcp 0 0 127.0.0.1:60000 0.0.0.0:* LISTEN 18478/postgrey.pidNow you need to add a line to /etc/postfix/main.cf 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:127.0.0.1:60000
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;
reject_rbl_client sbl-xbl.spamhaus.org
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/main.cf;
mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexpWhere the file /etc/postfix/mime_header_checks.regexp has;
/filename=\"?(.*)\.(bat|chm|cmd|com|cpl|do|exe|hta|jse|rm|scr|pif|vbe|vbs|vxd|xl|zip)\"?$/
REJECT For security reasons attachments of this type are rejected.
/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(lnk|cpl|asd|hlp|ocx|reg|bat|c[ho]m|cmd|exe|dll|vxd|pif|scr|hta|jse?|sh[mbs]|vb[esx]|ws[fh]|wav|mov|wmf|xl))"?\s*$/
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 main.cf, 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.
reject_rbl_client sbl-xbl.spamhaus.org
should be in "smtpd_client_restrictions"
[ Parent | Reply to this comment ]
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 http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
which is worth looking at I think.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Another good trick is to check for sites claiming to be you in your helo_checks file.
33.33.33.33 ACCEPT # Bob works from home and runs
# his own mail server
localhost REJECT
example.com REJECT
12.34.56.78 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 ]
[ Parent | Reply to this comment ]
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 ]
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 ]
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 ]
I installed postgrey
then ran netstat -anp |grep 6000
tcp 0 0 127.0.0.1:60000 0.0.0.0:* LISTEN 30839/postgrey.pid
then I add
check_policy_service inet:127.0.0.1:6000
to main.cf 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 127.0.0.1:6000: Connection refused
Mar 1 11:23:40 abyss postfix/smtpd[23994]: warning: problem talking to server 127.0.0.1:6000: Connection refused
I know I am missing something silly but this is just one of those days.
Any help would be much appreciated,
--Joss
[ Parent | Reply to this comment ]
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,
--Joss
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
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 ]
really simple and to the point.
[ Parent | Reply to this comment ]
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 http://isg.ee.ethz.ch/tools/postgrey/help/xxxxxx.nl.html); from=<xxxxxxxxxxxx> to=<xxxxxxxxx> proto=ESMTP helo=<xxxxxxxxx>
Anybody knows know to solve this?
[ Parent | Reply to this comment ]
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 ]
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!
its awerner.homeip.net
my email Adress is mail@awerner.homeip.net
pls send me spam :) maybe then i can see that it is working. :)
i can send in logs or config on request.
greets
Axel
[ Parent | Reply to this comment ]
.
.
.
mydestination = weisweil.lan, localhost.lan, localhost, awerner.homeip.net, 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 = 127.0.0.0/8 192.168.0.0/24
.
.
.
SMTPD_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client list.dsbl.org,
check_policy_service inet:127.0.0.1:60000
.
.
.
snap of my /etc/postfix/master.cf
#
# 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 127.0.0.1
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 ]
[ Parent | Reply to this comment ]
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.
thanks.
Axel
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Otherwise I think you could do it in postfix classes, but that is more difficult to ensure the right thing is done.
http://www.postfix.org/RESTRICTION_CLASS_README.html
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]