<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>The BFC Computing Weblog: Reducing Spam with SMTP Validation on Postfix</title>
    <link>http://blog.bfccomputing.com/articles/2009/05/06/reducing-spam-with-smtp-validation-on-postfix</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>My God, It's Full of Source!</description>
    <item>
      <title>Reducing Spam with SMTP Validation on Postfix</title>
      <description>&lt;p&gt;This is a neat enhancement to postfix for reducing spam by attacking its economics: making sure it speaks SMTP properly.&lt;/p&gt;

&lt;p&gt;A spammer gets paid by the message delivered. So, it's in his interest to flood them out as quickly as possible.  Because of this, they rarely implement mailers which negotiate the SMTP connection politely - they simply open the TCP connection and start sending.&lt;/p&gt;

&lt;p&gt;When an SMTP client doesn't respect the proper-back-and forth postfix expects, it'll flag it as unauthorized 'pipelining' - for example when multiple messages are sent in succession, but which would otherwise be OK.&lt;/p&gt;

&lt;p&gt;We can take advantage of this by forcing the issue, and increasing the odds a spammer will make this mistake by waiting just a second between establishing the TCP connection and telling the spammer we're ready to take mail.  A loaded mail server may behave this way anyway, so it's not outside the norm and the resource consumption is minimal, but it attacks the economics of spamming.&lt;/p&gt;

&lt;p&gt;In your main.cf file, you would add to &lt;code&gt;smtpd_client_restrictions&lt;/code&gt; something like this:&lt;/p&gt;

&lt;pre&gt;
&lt;code&gt;smtpd_client_restrictions =
        permit_sasl_authenticated,
        permit_mynetworks,
        check_client_access hash:/etc/postfix/access-client,
        sleep 1,
        reject_unauth_pipelining
&lt;/code&gt;
&lt;/pre&gt;

&lt;p&gt;We accept all of our own users' connections (interactive ones, perhaps) right away, and if the sender is totally unknown to us, we wait for just a second.  Then we reject any unauthorized pipelining.  The log will show something like this:&lt;/p&gt;

&lt;p&gt;&lt;code&gt;May  6 10:49:00 mailhub postfix/smtpd[8965]: NOQUEUE: reject: RCPT from unknown[10.1.2.3]: 403 4.5.0 &lt;a href="&amp;#x6D;&amp;#x61;&amp;#105;l&amp;#116;&amp;#x6F;:&amp;#x73;&amp;#x70;&amp;#097;&amp;#109;&amp;#x74;&amp;#097;&amp;#x72;g&amp;#x65;&amp;#116;&amp;#x40;&amp;#x65;&amp;#x78;&amp;#x61;&amp;#x6D;&amp;#112;&amp;#x6C;&amp;#101;&amp;#046;&amp;#x63;&amp;#x6F;&amp;#109;"&gt;&amp;#x73;&amp;#x70;&amp;#097;&amp;#109;&amp;#x74;&amp;#097;&amp;#x72;g&amp;#x65;&amp;#116;&amp;#x40;&amp;#x65;&amp;#x78;&amp;#x61;&amp;#x6D;&amp;#112;&amp;#x6C;&amp;#101;&amp;#046;&amp;#x63;&amp;#x6F;&amp;#109;&lt;/a&gt;: Recipient address rejected: Improper use of SMTP command pipelining&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;when the spammer attempts to just send.&lt;/p&gt;

&lt;p&gt;It's worth noting that this method may not scale to very large installations, as those one second delays may be too much.  But for the average-sized postfix install, it can make yet another dent in the spam deluge.  Where it does consume 'too many' resources, one must weight the cost of computing resources vs. the time cost of dealing with yet another spam.&lt;/p&gt;</description>
      <pubDate>Wed, 06 May 2009 10:50:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:8d2b1675-60f9-473c-b48a-9b9d317add3d</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/05/06/reducing-spam-with-smtp-validation-on-postfix</link>
      <category>Internet</category>
      <category>Open Source</category>
      <category>Security</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4806</trackback:ping>
    </item>
    <item>
      <title>"Reducing Spam with SMTP Validation on Postfix" by Bill McGonigle</title>
      <description>&lt;p&gt;'Large' is probably north of 10 messages a second.&lt;/p&gt;</description>
      <pubDate>Wed, 06 May 2009 13:04:19 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:820f464a-6ab0-4af8-ad17-63b5680581cd</guid>
      <link>http://blog.bfccomputing.com/articles/2009/05/06/reducing-spam-with-smtp-validation-on-postfix#comment-30531</link>
    </item>
    <item>
      <title>"Reducing Spam with SMTP Validation on Postfix" by glen.page@thet.net</title>
      <description>&lt;p&gt;Would TA fit your definition of an "average-sized postfix install"? If yes, is this something we might implement in addition to or in place of the grey-listing?&lt;/p&gt;</description>
      <pubDate>Wed, 06 May 2009 11:26:02 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:fe860171-e6a6-45fd-a913-f49de0f93b9b</guid>
      <link>http://blog.bfccomputing.com/articles/2009/05/06/reducing-spam-with-smtp-validation-on-postfix#comment-30530</link>
    </item>
  </channel>
</rss>
