Date: Wed, 19 Feb 2014 17:05:24 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43989 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402191705.s1JH5OuR068282@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Feb 19 17:05:24 2014 New Revision: 43989 URL: http://svnweb.freebsd.org/changeset/doc/43989 Log: Editorial pass through spamd section. The last step on using spamd-setup should be expanded at some point. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 22:23:51 2014 (r43988) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 17:05:24 2014 (r43989) @@ -1176,63 +1176,59 @@ pass inet proto tcp from any to $localne <title>Protecting Against <acronym>SPAM</acronym></title> <para>Not to be confused with the - <application>spamd</application> daemon which comes - bundled with <application>spamassassin</application>, the - <application>PF</application> companion - <application>spamd</application> was designed to run on a - PF gateway to form part of the outer defense against spam. - <application>spamd</application> hooks into the - <application>PF</application> configuration via a set of + <application>spamd</application> daemon which comes bundled + with <application>spamassassin</application>, + <package>mail/spamd/</package> can be configured with + <application>PF</application> to provide an outer defense against <acronym>SPAM</acronym>. + This <application>spamd</application> hooks into the + <application>PF</application> configuration using a set of redirections.</para> - <para>The main point underlying the - <application>spamd</application> design is the fact that - spammers send a large number of messages, and the - probability that you are the first person receiving a - particular message is incredibly small. In addition, - spam is mainly sent via a few spammer friendly networks - and a large number of hijacked machines. Both the - individual messages and the machines will be reported to - blacklists fairly quickly, and this is the kind of data - <application>spamd</application> can use to our advantage - with <firstterm>blacklists</firstterm>.</para> - - <para>What <application>spamd</application> does to SMTP - connections from addresses in the blacklist is to - present its banner and immediately switch to a mode - where it answers SMTP traffic one byte at the time. This + <para>Spammers tend to send a large number of messages, and + <acronym>SPAM</acronym> is mainly sent from a few spammer friendly networks + and a large number of hijacked machines, both of which + are reported to + <firstterm>blacklists</firstterm> fairly quickly.</para> + + <para>When an <acronym>SMTP</acronym> + connection from an address in a blacklist is received, + <application>spamd</application> + presents its banner and immediately switches to a mode + where it answers <acronym>SMTP</acronym> traffic one byte at a time. This technique, which is intended to waste as much time as - possible on the sending end while costing the receiver - pretty much nothing, is called + possible on the spammer's end, is called <firstterm>tarpitting</firstterm>. The specific - implementation with one byte SMTP replies is often + implementation which uses one byte <acronym>SMTP</acronym> replies is often referred to as <firstterm>stuttering</firstterm>.</para> <para>This example demonstrates the basic procedure for setting up <application>spamd</application> with - automatically updated blacklists:</para> + automatically updated blacklists. Refer to the man pages + which are installed with <package>mail/spamd/</package> for + more information.</para> <procedure> + <title>Configuring <application>spamd</application></title> + <step> - <para>Install the <package>mail/spamd/</package> port. - In particular, be sure to read the package message - and act upon what it says. Specifically, to use + <para>Install the <package>mail/spamd/</package> package or port. + In order to use <application>spamd</application>'s greylisting - features, a file descriptor file system (see <link - xlink:href="http://www.freebsd.org/cgi/man.cgi?query=fdescfs&sektion=5">fdescfs(5)</link>) - must be mounted at <filename>/dev/fd/</filename>. - Do this by adding the following line to + features, &man.fdescfs.5; + must be mounted at <filename class="directory">/dev/fd</filename>. + Add the following line to <filename>/etc/fstab</filename>:</para> <programlisting> fdescfs /dev/fd fdescfs rw 0 0</programlisting> - <para>Make sure the <filename>fdescfs</filename> code - is in the kernel, either compiled in or by loading - the module with &man.kldload.8;.</para> + <para>Then, mount the filesystem:</para> + + <programlisting>&prompt.root; mount fdescfs</programlisting> + </step> <step> - <para>Next, edit the ruleset to include</para> + <para>Next, edit the <application>PF</application> ruleset to include:</para> <programlisting>table <spamd> persist table <spamd-white> persist @@ -1241,42 +1237,44 @@ rdr pass on $ext_if inet proto tcp from rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025</programlisting> - <para>The two tables <spamd> and - <spamd-white> are essential. SMTP traffic - from the addresses in the first table plus the ones - which are not in the other table are redirected to a + <para>The two tables <literal><spamd></literal> and + <literal><spamd-white></literal> are essential. <acronym>SMTP</acronym> traffic + from an address listed in<literal> <spamd></literal> but not in + <literal><spamd-white></literal> is redirected to the <application>spamd</application> daemon listening at port 8025.</para> </step> <step> - <para>The next step is to set up - <application>spamd</application>'s own configuration - in <filename>/usr/local/etc/spamd.conf</filename> - supplemented by <filename>rc.conf</filename> + <para>The next step is to configure + <application>spamd</application> + in <filename>/usr/local/etc/spamd.conf</filename> and to + add some <filename>rc.conf</filename> parameters.</para> - <para>The supplied sample file offers quite a bit of - explanation, and the man page offers additional - information, but we will recap the essentials - here.</para> + <para>The installation of <package>mail/spamd/</package> + includes a sample configuration file + (<filename>/usr/local/etc/spamd.conf.sample</filename>) and a + man page for <filename>spamd.conf</filename>. Refer to + these for additional configuration options beyond those + shown in this example.</para> - <para>One of the first lines without a - <literal>#</literal> comment sign at the start + <para>One of the first lines in the configuration file that does not begin with a + <literal>#</literal> comment sign contains the block which defines the <literal>all</literal> list, which specifies the - lists actually used:</para> + lists to use:</para> <programlisting>all:\ :traplist:whitelist:</programlisting> - <para>Here, all the desired black lists are added, - separated by colons (<literal>:</literal>). To use - whitelists to subtract addresses from the blacklist, - add the name of the whitelist immediately after the - name of each blacklist, i.e., + <para>This entry adds the desired blacklists, + separated by colons (<literal>:</literal>). To use a + whitelist to subtract addresses from a blacklist, + add the name of the whitelist <emphasis>immediately</emphasis> after the + name of that blacklist. For example: <literal>:blacklist:whitelist:</literal>.</para> - <para>Next up is a blacklist definition:</para> + <para>This is followed by the specified blacklist's definition:</para> <programlisting>traplist:\ :black:\ @@ -1284,56 +1282,49 @@ rdr pass on $ext_if inet proto tcp from :method=http:\ :file=www.openbsd.org/spamd/traplist.gz</programlisting> - <para>Following the name, the first data field - specifies the list type, in this case - <literal>black</literal>. The + <para>where the first line is the name of the blacklist and the second line + specifies the list type. The <literal>msg</literal> field contains the message to - display to blacklisted senders during the SMTP + display to blacklisted senders during the <acronym>SMTP</acronym> dialogue. The <literal>method</literal> field - specifies how spamd-setup fetches the list data, - here <literal>http</literal>. The other options are - fetching via <literal>ftp</literal>, from a - <literal>file</literal> in a mounted file system or + specifies how <application>spamd-setup</application> fetches the list data; + supported methods are <literal>http</literal>, + <literal>ftp</literal>, from a + <literal>file</literal> in a mounted file system, and via <literal>exec</literal> of an external program. - Finally the <literal>file</literal> field specifies - the name of the file spamd expects to receive.</para> + Finally, the <literal>file</literal> field specifies + the name of the file <application>spamd</application> expects to receive.</para> - <para>The definition of a whitelist follows much the - same pattern:</para> + <para>The definition of the specified whitelist is + similar, but omits the <literal>msg</literal> field since a + message is not needed:</para> <programlisting>whitelist:\ :white:\ :method=file:\ :file=/var/mail/whitelist.txt</programlisting> - <para>but omits the message parameters since a - message is not needed.</para> - <tip> <title>Choose Data Sources with Care</title> <para>Using all the blacklists in the sample - <filename>spamd.conf</filename> will end up - blacklisting large blocks of the Internet, - including several Asian nations. Administrators - need to edit the file to end up with an optimal - configuration. The administrator is the judge of - which data sources to use, and using lists other - than the ones suggested in the sample file is - possible.</para> + <filename>spamd.conf</filename> will + blacklist large blocks of the Internet. Administrators + need to edit the file to create an optimal + configuration which uses applicable + data sources and, when necessary, uses custom lists.</para> </tip> - <para>Put the lines for spamd and any startup - parameters desired in <filename>/etc/rc.conf</filename>, - for example:</para> - - <programlisting>spamd_flags="-v" # for normal use: "" and see spamd-setup(8)</programlisting> - - <para>When done with editing the setup, reload the - ruleset, start <application>spamd</application> with the - options desired using the - <filename>/usr/local/etc/rc.d/obspamd</filename> - script, and complete the configuration using + <para>Next, add this entry to <filename>/etc/rc.conf</filename>. + Additional flags are described in the man page specified + by the comment:</para> + + <programlisting>spamd_flags="-v" # use "" and see spamd-setup(8) for flags</programlisting> + + <para>When finished, reload the + ruleset, start <application>spamd</application> by typing + <command>service start obspamd</command>, + and complete the configuration using <command>spamd-setup</command>. Finally, create a &man.cron.8; job which calls <command>spamd-setup</command> to update the tables @@ -1342,7 +1333,7 @@ rdr pass on $ext_if inet proto tcp from </procedure> <para>On a typical gateway in front of a mail server, - hosts will start getting trapped within a few seconds to + hosts will soon start getting trapped within a few seconds to several minutes.</para> <sect4 xml:id="pftut-spamd-greylist">
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402191705.s1JH5OuR068282>