This is a follow up article to my post on setting up greylisting with postfix and Ubuntu. While I really like the idea behind greylisting, it was resulting in legitimate email not arriving.
Why it wasn’t working
- Frustrating delay for any password reset, at least a 300 second (5 minute) delay for legitimate email from a properly configured email server. This was a known issue, but still annoying.
- Recently (mid-August 2013) some hotmail servers (impacting at least @hotmail and @sympatico.ca email addresses) were returning bounces to the user instead of properly handling the greylisting. [Specific servers from my logs: snt0-omc1-s8.snt0.hotmail.com, blu0-omc1-s36.blu0.hotmail.com, dub0-omc1-s5.dub0.hotmail.com]
- Other individual servers that failed to handle greylisting correctly. One important example would be the Interac email transfer email servers (notify@payments.interac.ca).
The more I looked at the logs, the more legitimate email I found that wasn’t being delivered.
It was also difficult for people to understand. If a friend sends you an email, it is then bounced back to them due to their sending server not handling the greylisting correctly – they then send you a follow up email some 5+ minutes later, that email will come through just fine because it looks like a second attempt to deliver the original email. The broken sending server will then kept on the auto-whitelist for 30 days or so and greylisting will not be applied.
Any spammer smart or lucky enough to send via my backup mail server would miss the greylisting as that server didn’t use greylisting and email was always accepted from the trusted backup server.
Also, more spam software seems to be retrying now.
Anyone else notice that #greylisting isn’t stopping spam much lately? My volume’s gone up by ~1000 spams/day
— Cory Doctorow (@doctorow) September 25, 2013
Tools. It wasn’t until very recently that I found the postgreyreport script, this is quite useful for generating a report on what was rejected by the greylisting your mail server is using. I’d recommend anyone using greylisting consider using this script to monitor what isn’t being delivered.
I’ll recommend an article I came across while investigating some of these issues. It is supportive of greylisting (which I can’t agree with now) but it does touch on some other techniques. It’s based on OpenBSD / spamd – something not (easily) available on Ubuntu.
Actually removing it
As always, refer to the community documentation. It turns out removing it is very simple.
- Edit /etc/postfix/main.cf
- Find the line: smtpd_recipient_restrictions
- Remove “check_policy_service inet:127.0.0.1:60000” from this line
- Reload the postfix config “sudo /etc/init.d/postfix reload”
- Verify it was working by looking at /var/log/mail.log
Looking at the log will make it very obvious that you’ve succeeded. There will not be any postfix config load errors, and when new email comes in you’ll not see any postgrey log entries.
Future
Postfix can be configured to move ‘spam’ directly into a folder, I plan to do this and invest time in figuring out better spam detection in the future. I think no matter what I do, always allowing email to arrive (but possibly be tagged and sorted differently) will be my approach.
Greytrapping looks really interesting, but it doesn’t look like it’s easy to configure on Ubuntu and I’m not sure I want to NOT deliver any email.
Here is some useful looking Ubuntu mail server advice (again, I’d suggest that you ignore the greylisting part).
My parting thought will be a link to the Ubuntu community doc on mail filtering.