Editorial pass through spamd section.

The last step on using spamd-setup should be expanded at some point.

Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-19 17:05:24 +00:00
parent 73c10cce60
commit 2072f49e18
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43989

View file

@ -1176,63 +1176,59 @@ pass inet proto tcp from any to $localnet port $tcp_services \
<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>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>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>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&amp;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 &lt;spamd&gt; persist
table &lt;spamd-white&gt; persist
@ -1241,42 +1237,44 @@ rdr pass on $ext_if inet proto tcp from &lt;spamd&gt; to \
rdr pass on $ext_if inet proto tcp from !&lt;spamd-white&gt; to \
{ $ext_if, $localnet } port smtp -&gt; 127.0.0.1 port 8025</programlisting>
<para>The two tables &lt;spamd&gt; and
&lt;spamd-white&gt; 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>&lt;spamd&gt;</literal> and
<literal>&lt;spamd-white&gt;</literal> are essential. <acronym>SMTP</acronym> traffic
from an address listed in<literal> &lt;spamd&gt;</literal> but not in
<literal>&lt;spamd-white&gt;</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 !&lt;spamd-white&gt; to \
: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>
<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" # for normal use: "" and see spamd-setup(8)</programlisting>
<programlisting>spamd_flags="-v" # use "" and see spamd-setup(8) for flags</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>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 !&lt;spamd-white&gt; to \
</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">