At 07:09 PM 1/5/99 +0800, wrote:
>John R. Levine ([EMAIL PROTECTED]) wrote:
>: >Why not break the smtpd into two parts, the way qmail's pop3d
>
>: Doesn't break up very nicely, since it's quite common to do multiple
>
>Yah, that's true.
>
>: This seems to be a reasonable place to use an exit routine. That is,
>: each time you get a RCPT TO address, optionally fork and run a program
>: specified in a control file or environment variable. The program
>
>Assuming the cost of execs is not prohibitive, this loses state
>info, such as how many RCPTs in this MAIL. RN's got a good idea
Indeed. If we're talking about dealing with spam in an inprecise manner (the
only manner we currently have) then an interface such as this has to be able
to support techniques that are only know coming to the fore, such as
statistical analysis of traffic, distribution of recipients, white-lists,
tagging, per-user rules and so on.
Personally I favour an IPC method that allows state-full techniques a little
more readily than the relative statelessness of pipe/fork/exec
(Having said that a pipeline can of course include a program that does
interface with a more sophisticated spam-detector in any way it chooses.)
To my mind, 'state' is key. Much of the human spam detecting I see is
pattern matching of repeat occurences. Leaving spam filtering until user
delivery is past the point at which any commonality of inbound traffic can
be ascertained. If we accept this proposition, then spam detection has to be
done prior to user delivery. Now that need not be SMTP, it could be later in
the path. But personally, I much rather entry-policy implemented at my front
door.
Regards.
