Mark wrote:
Exactly what I said: SA works on examining a message (headers + body);
that makes it, per definition, a post-DATA phase operation.

Ah, gotcha.  But not 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

No, you might as well not. If you reject post DATA, then the right behind happens. If you accept the message, then you have to either discard a potential FP or create backscatter. You *should not* do it post-smtp if you can possibly avoid it!

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).

Again, what advantage is lost?  Advantage is only gained...

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.

Look up interactive. It's a batch process. Nobody is watching it and waiting unless they're using telnet to deliver mail by hand.

 > 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.

I have all of those, all of the default RBLS and 12 RBLs that aren't in the list. Scan times average 9 seconds on ancient hardware.

--
Jo Rhett
Network/Software Engineer
Net Consonance

Reply via email to