Re: [exim] exim_surbl

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