On Tue, 4 Dec 2007, John Schmerold wrote:
> That, of course is one of the reasons I wrote, I suspect we could do
> better. An obvious area for our situation is to deny based on
> recipient email address (if we don't exist, why are we accepting mail
> for them).
>
> This box is a filter for several clients using mail servers that
> include Exchange, cPanel, Groupwise & Vmailmgr, so configuring
> recipient addresses is easier said than done.
>
> We're using several (probably too many) rbls, that helps, guess
> greylisting is next.
Greylisting can be somewhat complicated and needs some care; in the
meantime, have you considered some of the other easy lightweight basic
checks?
. enabling checks on protocol synchronisation
. test for lack of HELO
. test for HELO is one of your domains or your IP, or otherwise known to
be false (e.g., "friend" - have a look at the HELOs used by messages you
later find are spam)
. test for HELO is the local part of the current rcpt
. test for HELO contains underscores (but be prepared to make exceptions)
. consider requiring something that looks like an FQDN for HELO
. delays at various points in the SMTP transaction
. defer if DNS reverse dns lookup fails on connecting ip (ie, no dns
response from a server -- trying to match up forward- and reverse-dns for
a host is much more problematic)
The last one I recently implemented after wavering over it for years. My
users tell me it has made a considerable difference.
Jethro.
>
> On Dec 4, 2007 3:47 PM, W B Hacker <wbh@???> wrote:
> > John Schmerold wrote:
> > > The reason I like this approach is because it seems to be much
> > > thriftier with system resources. It checks the body of the message, if
> > > it finds an offensive URL, it rejects it. No chance of me giving up
> > > Spamassassin, or something similar anytime soon, but we can't afford
> > > to have our system resources drained on every message.
> > >
> > > I'm only in day one of this newfound tool, however since implementing
> > > it, I have yet to see memory utilization in excess of 512MB. Before
> > > using exim_surbl, we were routinely hitting 2GB.
> >
> > Ouch!
> >
> > But if exim_surbl works *that* well for you, as late in the game as it must be
> > applied, something is not as good as it could be elsewhere.
> >
> > You should be able to make very significant gains well ahead of it.
> >
> >
> > Bill
> >
> >
> > --
> > ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> > ## Exim details at http://www.exim.org/
> > ## Please use the Wiki with this list - http://wiki.exim.org/
> >
>
> --
> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK
