From: Jorey Bump (listjoreybump.com)
Date: Tue Jul 03 2007 - 11:27:01 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Joey wrote:

> So the main question is still how do I weigh everything I am doing and
> cut out the waste, so that we can add newer methods and not crash our
> server. I’m sure many of you deal with this as well, and I figured
> someone would have some ideas…

It's funny you bring this up just as I'm running stats for my use of
Nolisting on one of my servers. Here is an analysis on 10,000 packets:

# Total SMTP packets: 10000
# Total source hosts: 468 100% (DNSBL: 392 83%)
# Both MX: 92 19% (DNSBL: 36 39%)
# Single MX: 376 80% (DNSBL: 356 94%)
# Primary only: 235 50% (DNSBL: 226 96%)
# Secondary only: 141 30% (DNSBL: 130 92%)

This represents 468 hosts. Of the ones that try both MX hosts (the
primary is always unavailable) only 39% of them appear on the 12 RBLs
I'm checking (selected because they are good indicators of spam in *my*
environment). By contrast, 96% of the hosts that fire-and-forget at the
unavailable primary MX appear on these RBLs. Nolisting prevents these
hosts from ever connecting to Postfix. In this example, this represents
50% of all hosts, which could result in a significant reduction in load
on a mail server (note that the actual percentage of load reduction
depends on the number and type of connections, not the number of hosts,
so you wouldn't expect a precise 50% load reduction in this example).

Nolisting appears to be very safe, because compliant hosts will
immediately retry the secondary MX, which serves as the real MX. I'm not
suggesting that Nolisting will stop any more spam than your current
methods combined, just that it will reduce the amount of spam that you
*process*, thus freeing up resources and reducing the load on your server.

More information about Nolisting can be found at:

  http://nolisting.org/

Now we're left with the messages that need further processing. Since you
want to evaluate the effectiveness of your techniques, I highly
recommend Mike Capella's postfix plugin for logwatch (also capable of
running standalone without logwatch):

  http://www.mikecappella.com/logwatch/

This will give you a concise report of your rejections, and you can
increase the level of detail, if you wish. A quick check of yesterday's
log on one of my servers shows that 16% of rejections were rejected by
my HELO/EHLO checks, 22% were unknown users, 29% were rejected by a
*very* short list of RBLs I trust (the rest are scored in SpamAssassin),
and 33% were rejected by SpamAssassin (in a before-queue filter, with
the actual rejection done by a header check of the resulting
SpamAssassin score). The SpamAssassin filter is by far the most
resource-intensive method I use, and the other ones (accounting for the
majority of the rejections when combined) are relatively cheap.

I no longer actively maintain header/body checks, which can end up being
quite expensive. I used to construct an enormous body_check rule based
on the SURBL (similar to what you are doing). While it was effective at
the time, I no longer need it, and I think my servers were straining
pretty hard under the load of comparing those very long expressions. You
might consider retiring that approach in favor of something less taxing.
If you don't already use HELO/EHLO checks, I highly recommend adding at
least this expression to a check_helo_access map:

  /^[[:digit:]\.-]*$/ REJECT Unacceptable hostname in helo

It's an inexpensive check (it's a regex, but no lookups are required),
and it stops a significant amount of spam on my machines.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]