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
