Peter Bowyer wrote: > On 04/12/2007, W B Hacker <[EMAIL PROTECTED]> 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/
