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.
On Dec 4, 2007 2:44 PM, W B Hacker <wbh@???> wrote:
> Peter Bowyer wrote:
> > On 04/12/2007, W B Hacker <wbh@???> wrote:
> >> Stephen Gran wrote:
> >>> On Tue, Dec 04, 2007 at 06:53:42PM +0000, W B Hacker said:
> >>>> Why wait until acl_smtp_data and invoke a perl script to do what Exim can do
> >>>> with much less workload in the acl_smtp_connect phase?
> >>> SURBL and URIBL are not what you think they are.
> >> Perhaps not.
> >>
> >> Can your tell me how they differ from the same-named ones included in SpamAssassin?
> >
> > They don't. But exim_surbl provides a more lightweight way of checking
> > them - and since many sites consider a SURBL or URIBL hit as a binary
> > result (ie a hit = treat as spam), you can avoid the expense of
> > running the message through SA.
> >
>
> Valid point.
>
> But only to the extnet that a SURBL or URIBL hit is likely to 'remain' as a
> possibe negative in a submission that has otherwise passed all 'solid' pre-SA
> (or whatever) tests.
>
> To wit:
>
> - Submitter obeys the raw communication parts of the protocol
>
> - Has a PTR RR
>
> - Has an 'acceptable' HELO/FQDN match (has to be some leeway here)
>
> - has not tried to impersonate us
>
> - is sending to a valid recipient
>
> - is NOT in an RBL we can check w/o doing string manipulation or perl.
>
> ---- and so on. The usual suspects, if you will. Nearly all before
> acl_smtp_data phase.
>
> I have no stats on that because - it seems - malicious URL/URI are very rare in
> otherwise-clean traffic form otherwise-RFC-compliant servers.
>
> FWIW, that absence may be exacerbated because we DO run ClamAV before deciding
> to invoke SA.
>
> And ClamAV is not particularly slow or resource-intensive.
>
> 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/
>
