{"id":1385,"date":"2013-09-30T20:50:59","date_gmt":"2013-10-01T00:50:59","guid":{"rendered":"https:\/\/lowtek.ca\/roo\/?p=1385"},"modified":"2013-09-30T20:50:59","modified_gmt":"2013-10-01T00:50:59","slug":"removing-greylisting","status":"publish","type":"post","link":"https:\/\/lowtek.ca\/roo\/2013\/removing-greylisting\/","title":{"rendered":"Removing Greylisting"},"content":{"rendered":"<p>This is a follow up article to my post on setting up <a href=\"https:\/\/lowtek.ca\/roo\/2011\/greylisting-with-postfix-and-ubuntu\/\">greylisting with postfix and Ubuntu<\/a>. While I really like the idea behind greylisting, it was resulting in legitimate email not arriving.<\/p>\n<p><strong>Why it wasn&#8217;t working<\/strong><\/p>\n<ol>\n<li>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.<\/li>\n<li>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. <em>[Specific servers from my logs: snt0-omc1-s8.snt0.hotmail.com, blu0-omc1-s36.blu0.hotmail.com, dub0-omc1-s5.dub0.hotmail.com]<\/em><\/li>\n<li>Other individual servers that failed to handle greylisting correctly. One important example would be the Interac email transfer email servers (notify@payments.interac.ca).<\/li>\n<\/ol>\n<p>The more I looked at the logs, the more legitimate email I found that wasn&#8217;t being delivered.<\/p>\n<p>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 &#8211; 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.<\/p>\n<p>Any spammer smart or lucky enough to send via my backup mail server would miss the greylisting as that server didn&#8217;t use greylisting and email was always accepted from the trusted backup server.<\/p>\n<p>Also, more spam software seems to be retrying now.<\/p>\n<blockquote class=\"twitter-tweet\"><p>Anyone else notice that <a href=\"https:\/\/twitter.com\/search?q=%23greylisting&amp;src=hash\">#greylisting<\/a> isn&#8217;t stopping spam much lately? My volume&#8217;s gone up by ~1000 spams\/day<\/p>\n<p>\u2014 Cory Doctorow (@doctorow) <a href=\"https:\/\/twitter.com\/doctorow\/statuses\/382833670421106688\">September 25, 2013<\/a><\/p><\/blockquote>\n<p><strong>Tools.<\/strong> It wasn&#8217;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&#8217;d recommend anyone using greylisting consider using this script to monitor what isn&#8217;t being delivered.<\/p>\n<p>I&#8217;ll <a href=\"http:\/\/bsdly.blogspot.no\/2013\/05\/keep-smiling-waste-spammers-time.html\">recommend an article<\/a> I came across while investigating some of these issues. It is supportive of greylisting (which I can&#8217;t agree with now) but it does touch on some other techniques. It&#8217;s based on OpenBSD \/ spamd &#8211; something not (easily) available on Ubuntu.<\/p>\n<p><!--more--><\/p>\n<p><strong>Actually removing it<\/strong><\/p>\n<p>As always, refer to the <a href=\"https:\/\/help.ubuntu.com\/community\/PostfixGreylisting\">community documentation<\/a>. It turns out removing it is very simple.<\/p>\n<ol>\n<li>Edit \/etc\/postfix\/main.cf<\/li>\n<li>Find the line:\u00a0smtpd_recipient_restrictions<\/li>\n<li>Remove &#8220;check_policy_service inet:127.0.0.1:60000&#8221; from this line<\/li>\n<li>Reload the postfix config &#8220;sudo \/etc\/init.d\/postfix reload&#8221;<\/li>\n<li>Verify it was working by looking at \/var\/log\/mail.log<\/li>\n<\/ol>\n<p>Looking at the log will make it very obvious that you&#8217;ve succeeded. There will not be any postfix config load errors, and when new email comes in you&#8217;ll not see any postgrey log entries.<\/p>\n<p><strong>Future<\/strong><\/p>\n<p>Postfix can be configured to move &#8216;spam&#8217; 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.<\/p>\n<p>Greytrapping looks really interesting, but it doesn&#8217;t look like it&#8217;s easy to configure on Ubuntu and I&#8217;m not sure I want to NOT deliver any email.<\/p>\n<p>Here is some useful looking <a href=\"http:\/\/ubuntuforums.org\/showthread.php?t=1698196\">Ubuntu mail server advice<\/a> (again, I&#8217;d suggest that you ignore the greylisting part).<\/p>\n<p>My parting thought will be a link to the <a href=\"https:\/\/help.ubuntu.com\/12.04\/serverguide\/mail-filtering.html\">Ubuntu community doc on mail filtering<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8217;t working Frustrating delay for any password reset, at least a 300 second (5 minute) delay for legitimate email from &hellip; <a href=\"https:\/\/lowtek.ca\/roo\/2013\/removing-greylisting\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Removing Greylisting&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-1385","post","type-post","status-publish","format-standard","hentry","category-computing"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1385","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=1385"}],"version-history":[{"count":3,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1385\/revisions"}],"predecessor-version":[{"id":1388,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1385\/revisions\/1388"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=1385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=1385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=1385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}