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 <[EMAIL PROTECTED]> 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 -- ## 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/
