[TriLUG] postfix security

[Aaron S. Joyner]

skippy1 at hickorytech.net wrote:

>Even without seeing the headers, its a pretty common thing for spammers to
>send their spam through secondary mail servers.  From the volume of this
>that I've seen I assume that a fairly large percentage of the spam
>software does this automatically.
>
>The problem for the mail admin is of course that in a standard setup, the
>secondary has no idea what accounts are on the primary and so blindly
>accepts everything for the domain.
>
>In sendmail its possible to set up a mail filter that accepts the spam
>connection and holds it open while it queries the primary to see if its a
>valid address.  If it isn't the secondary refuses the spam right then and
>never queues it.  The package I've used for that is milter-ahead from
>www.milter.org.  I don't know if a similar setup is possible with postfix.
>
>
>Skippy
>  
>
Unfortunately, it's my understanding that milter-ahead doesn't do much 
to gracefully handle situations where the primary MX is down (it goes 
back to accepting all mail if it can't connect to the primary) and it 
doesn't reduce that load from the primary server, in fact it increases 
the total connection count on your machines (as normally the spammer 
would only be making one connection to one machine, now he's making one, 
and you're making another for him).  I'm not a big fan of the 
milter-ahead-style solutions, especially since Postfix has such better 
options.  :)  If your domain is relatively low traffic (as I believe 
Mike's is), you can experiment with Postfix's verify(8) option, which 
allows a similar functionality to milter-ahead, but it caches 
information about which usernames are valid and are not valid, and only 
makes queries when it has to.  In a situation where the primary can't be 
reached, it relies on it's cache, and gives temporary 400-level errors 
to users it doesn't know about.  This works reasonably well, and is a 
good step up from milter-ahead, but under sufficient load the extra 
connections made (even with the caching) are undesirable.

In a more load-friendly, scalable solution, you can setup a 
relay_recipients_map entry in main.cf, which points to either a file, or 
a database.  That file (or table in the database) can contain a list of 
valid users in the domain.  All other recipients will be rejected with 
an error.  When ever you add a user to the mail server, pop over to the 
secondary, and add it to the file there.  In the case of a database, 
it's entirely possible that you can have your back end mail server 
looking at that same database, so when you add the user there, all 
servers are immediately aware of the change (or when replication happens 
to the local database living on each slave, in a truly large / highly 
available scenario).  This obviously requires a little bit more hand 
work, or a lot more setup, on the part of the admin, and that's why the 
milter-ahead and verify options are available.

So in short, use the tools available in Postfix already, and the problem 
is easy to handle.  If you run into snags, or find a solution that you 
like, let us know.  :)

Aaron S. Joyner