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