[TriLUG] postfix security

skippy1 at hickorytech.net skippy1 at hickorytech.net
Sun Dec 12 08:57:28 EST 2004


> skippy1 at hickorytech.net wrote:
>
[snip]
>>
>>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).

Actually, milter-ahead has a flag to control whether or not it fails open.
 The problem we were trying to solve when I studied milters was on 2
servers which had different userbases and were secondary for each other. 
The one kept falling down and going boom and from the logs, it looked like
it was usually spammers hitting it as secondary for the other server. 
Milter-ahead while not ideal, let us kick in some of sendmail's other
features such as the one that slows the connection way down after too many
invalid users.

> 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.

The version of milter-ahead that I looked at has caching at least for
positive answers (I don't remember about the negative).  We chose to have
it fail open if the primary couldn't be readhed so I didn't see which
method it used to fail closed.

> 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.

This sounds like what I had originally hoped to find.  Unfortunately, the
boss had said "no" to investigating other server software.  Everything
I've heard or read about Postfix makes it sound like a better planned and
better written package than sendmail.  Especially since the verify
capability is written into the core.  Milter-ahead took several days of
frustration, doc reading, and a bit of code reading to get working.

> 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


Skippy





More information about the TriLUG mailing list