> -----Original Message----- > From: Jo Rhett [mailto:[EMAIL PROTECTED] > Sent: donderdag 19 oktober 2006 20:36 > To: Mark > Cc: users@spamassassin.apache.org > Subject: Re: ALL_TRUSTED creating a problem > > > > I reckon the focus of SA on "post-SMTP" is due to the fact that it > > operates, by nature, post DATA phase.
> Huh? It operates when I ask it to. What are you trying to say here? Exactly what I said: SA works on examining a message (headers + body); that makes it, per definition, a post-DATA phase operation. > > I agree that milters, or any other stuff done during the SMTP > > dialogue, are a preferable first line of defense. But since full SA > > checks need to be done post-DATA anyway, you lose much of the > > advantage of a milter (e.g. pre-DATA phase early-outs). > Huh? I don't get you. What exactly about SA *requires* that it be > done post-SMTP...? Not post-SMTP per se, but post-DATA phase. And since the end of the DATA completes the SMTP dialogue, you might as well do it post-SMTP then (which is what I said: that you then lose much of the advantage of porting it to a milter environment; save the ability to reject during the SMTP dialogue). > And if that's true, why isn't there a major effort to overhaul it? spamd/spamc + spamassassin have always been post-SMTP operations. Only later a milter was written, too. > > A milter gives you the advantage of REJECT-ing during the SMTP > > dialogue (which really is a boon). But unless you close the connection > > first (thus losing the aforementioned advantage), SA checks can be > > quite time-consuming, especially with much RBL stuff done. Hence, > > these days I choose to let the LDA do SA checks. That way a spamd > > processcan chew away for a whole minute or so (an eternity within an > > SMTP dialogue), without anything being at risk of timing out. > Perhaps, but SMTP isn't interactive so who cares? Not interactive? It's full well interactive; the whole process is sending command codes, and waiting for reply codes (and acting based upon that communication). A timeout in that session is undesireable. > And hell, I'm running SA on a very ancient 1g system and scan times are > only 9-12 seconds. You'd have to be running on a 486 or on the other > side of a modem to see 1 minute scan times. (and I'm running the entire > set of SARE rulesets and few dozen others as well). But I specifically mentioned RBL checks. Those can take a while. Things like Razor2, Pyzor, and dcc checks can take a good while, too. I have Razor2 and Pyzor timeouts set to 30 seconds. And sometimes they really need that, too. - Mark
