On Thu, 2008-12-11 at 18:36 +0100, Matus UHLAR - fantomas wrote:
> > > Ned Slider wrote:
> > > > Yes, additional DNSBLs such as psbl and uceprotect can be integrated
> > > > into SA
>
> > On Thu, 2008-12-11 at 15:19 +0100, Marcin Krol wrote:
> > > Well, isn't it better to use them before SA, provided your MTA does have
> > > this feature (I recommend Exim to everyone)?
>
> On 11.12.08 17:55, Karsten Bräckelmann wrote:
> > No -- unless you ultimately trust the RBL to produce a *negligible*
> > amount of FPs. Every single RBL does have FPs to a highly variable
> > degree. Instead ob outright blocking on a hit, it is a good idea to
> > assign a score for the hit only, and see what the result is after all
> > tests have been performed...
>
> However, using blacklists before SA saves much of bandwidth and CPU time.
> Our company's servers refuse daily ~3x more clients than mails that are
> daily processed.
That may very well be. My point is, that you better *carefully* (to
avoid the word "paranoid") verify, whether you can trust an RBL for
outright blocking at SMTP level. Hence the "unless" part. The RBLs
mentioned aren't, say, ZEN...
This branch of the thread discusses adding more RBLs, which aren't even
part of stock SA for scoring.
> > Exactly the SA approach. A single (or even a few) rules and RBLs can
> > misfire, without affecting the overall deliverability of a particular
> > mail.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
