In trying to diagnose an issue with delayed receiving of emails on a fresh install of Snow Leopard Server, I noticed some error messages in the logs that looked suspiciously like greylisting. I was already familiar with greylisting having had it used on a mail server I used frequently and initially I was incredibly in favour of it. It was simple, it had a very low to zero false positive rate and it stopped a large amount of spam. The one downside to it, and the reason I no longer use it is that legitimate emails are often delayed by hours or more.
There are few things worse than signing up for a new website login and having to wait a couple of hours to receive the “click on this link” email. Or emailing someone who hasn’t sent you an email before, and having the reply delayed by hours, or more. Some MTAs are good and will retry after just a few minutes, while others wait a couple of hours or more. One ISP (I can not remember which one) had particularly bad mail servers in this regard and emails were often delayed by 12 hours or more.
Anyway, the events I saw in the log were something like the following:
Nov 18 16:21:25 server postfix/smtpd[14593]: NOQUEUE: reject: RCPT from mx1.bigisp[10.0.0.143]: 450 4.7.1 : Recipient address rejected: Service is unavailable; from= to= proto=ESMTP helo=
Nov 18 16:35:20 server postfix/smtpd[14928]: NOQUEUE: reject: RCPT from mx2.bigisp.com[10.0.0.140]: 450 4.7.1 : Recipient address rejected: Service is unavailable; from= to= proto=ESMTP helo=
Nov 18 19:30:51 server postfix/qmgr[135]: 1042CA3E608: from=, size=7842, nrcpt=1 (queue active)
In the example above, you can see two attempts in a number of minutes from the one ISP (bigisp.com in my example) which would be great and this would mean that the email is sent in a timely fashion. The problem is that this big ISP has multiple mail servers, one attempt comes from mx1 and the second from mx2, both on different ip addresses (.143 and .140) so it’s seen as two separate attempts and each one is told to wait. Then, there’s a retry at around 3 hours later, and this time it’s accepted for delivery.
What really gets me about this is that there’s no mention that I’ve seen in the Snow Leopard Server documentation that this is enabled, and no obvious way I’ve found to turn it off. I want spam filtering, I want AV filtering. I most definitely do not want greylisting. The people using this mail server rely on it for their business and the timely delivery of information – greylisting does nothing to help their cause.
Fortunately, with the power of the internet, a solution was quickly proposed on Apple’s discussion forums, and here it is for completeness:
You need to edit the file /etc/postfix/main.cf with root privileges.
On the server, in Terminal type the following (works if you’re using ssh to access the server as well)
sudo -s
Enter your administrator password when prompted. This will give you a root shell on the machine – this is pretty powerful kung-fu, so use it carefully. If you don’t know what you’re doing then don’t do it.
cd /etc/postfix
Feel free to substitute nano, vi, or mate or your favourite text editor for pico. How to drive pico is beyond the scope of this article.
cp main.cf main.cf.backup
pico main.cf
Search for a line that starts with smtpd_recipient_restrictions
Remove the bit of the line that says check_policy_service unix:private/policy
Save and exit.
Finally, type the following into the terminal or reboot the server for the changes to take effect.
postfix reload
exit
exit
I run mail service for a number of clients and have been greylisting for years – twice I’ve needed to add whitelist exceptions but on the whole (in my case at least) it helps more than it hinders.
The real problem here is Apple shipping the crappy demo greylist.pl greylist policy server instead of a smarter option like postgrey. The shipped policy server
1. never expires database entries, so the BDB format database will grow without bound forever (or until the disk runs out of space).
2. doesn’t ship with any of the “known stupid mailhosts” lists that whitelist problem senders
3. doesn’t allow you to add your own whitelist entries for stupid senders.
I run mail on Debian, but adding postgrey to OSX server should be trivial. Install postgrey using macports, make sure you load the launchd.plist item to keep it running, then replace
check_policy_service unix:private/policy
with
check_policy_service inet:127.0.0.1:60000
in your main.cf file.
/opt/local/etc/postgrey/postgrey_whitelist_clients contains the default whitelist, and you can stick your own whitelist entries in /…/postgrey/postgrey_whitelist_clients.local
my local whitelist is tiny –
# we trust our backup MX
xxx.xxx.com.au
# optusnet.com.au have a stupid retry pattern
211.29.132
211.29.133
# mail.kellyhazell.com.au never bothers to retry? idiots…
220.244.184.56
Yeah, I tend to agree with you there – it’s not so much greylisting per-se that I have an issue with, but more that it’s on by default with no notification and no (easy) way to disable it in Snow Leopard Server – and no way to configure it.
The optusnet mail servers in particular are ones that I had big issues with – retries on the order of 12 hours or more…
greylisting rules …
… if implmented/configured properly.
other anti spam (apart from say dns black lists like spamhaus) give too many false positives.
PS, greylisting has the added bonus of blocking 99% of email borne virii
Kai – thank you SO MUCH for articulating this post so well!
I’ve got a recently deployed mail server that was a *perfect* implementation according to the Apple Engineer that I spoke to, and yet was having a mail delivery delay of an hour for all incoming mail. Again, just like you this is a business client, and this is an unacceptable delay. The fact that I can control blacklists but NOT greylists makes ZERO sense to me.
I thought I was losing it until I read your great post. Thanks again!!!
Fantastic! You saved me. I had this colleague whose email was being rejected and his server was set up to try just once and give up. It was driving me crazy. Then, I found your post and observed the telltale pattern of greylisting. Followed your suggestion and now all is well.
Thanks again!
Very useful, and I can confirm that if you follow the very well laid out step by step instructions it works fine.
Sites that we were affected/delayed from receiving emails from were ebay.com.au and also moshimonsters.com. We now receive emails from these sites immediately instead of about 12 hours later.
Thank you for taking the time to write the article.