DCC - Postfix MTA mail hub implementation question

Vernon Schryver wrote:

>>From: Matt Armstrong <matt@lickey.com>
>>    
>>
>>...
>>Yes.  It'd be done with a postfix content filter. Basically postfix can 
>>be set up to pipe all mail it sees to a command or SMTP server running 
>>on a different port. .
>>
>The worrisome cost of such designs is that every mail message requires
>at least one fork() and exec() for dccproc and for all I know, more
>for however postfix gets the result from dccproc
>
For postfix the dominant cost is not fork/exec but management of the 
queue files. The postfix content filtering scheme involves the mail 
totally leaving the postfix universe (it is effectively "delivered" to 
the content filter), so the queue file is deleted. The content filter 
reinjects the message, so a new queue file is created and synced to 
disk. So the performance will be roughly cut in half given that disk I/O 
is the bottleneck for SMTP servers.

>What sort of interface could postfix, smtpd, qmail, and the rest use
>to talk to a permanent daemon?   Could they use a permanent daemon?
>
>The input to such a daemon needs to include
>
>  - envelope information equivalent to `dccproc -R -a ip-addr -f from`
>  - the SMTP body including headers
>
>For each mail message, the output needs to included 
>
>  - the modified body (i.e. X-DCC header added)
>  - whether the `dccproc -c` thresholds have been reached
>
>Possible mechanisms include
>
>  - a transient TCP or UNIX domain socket for message
>       (i.e. connect()/write()/close())
>
>  - a pair of interprocess communication streams such as a socket or a pipe
>       with the SMTP bodies prefixed by the envelope on input to the
>       daemon and the result on output, wand the bodies delimited
>       probably by a leading byte count.  (RFC 821 escaping sounds like
>       more trouble for all concerned.)
>
I think the SMTP protocol itself is sufficiently powerful. A permanent 
DCC daemon would run as a postfix content filter. Postfix would 
"deliver" the message via SMTP to the DCC daemon. The daemon would do 
its thing, possibly rejecting the message with a 5XX SMTP error or 
possibly a 4XX SMTP error (if, say, the DCC server isn't answering). If 
the message pases the DCC thresholds, the daemon would reinject the 
modified message back into postfix via SMTP on a different port.

SMTP command pipelining basically eliminates concerns about the 
efficiency of the protocol, especially when you consider that the 
dominant cost for postfix is disk I/O. Consider that many people run 
every message through a virus scanner already and many people have 
plenty of capacity on their SMTP servers. These folks would find this 
approach doable. Those that have a huge message volume already would 
have to add more hardware, though they may still find postfix+DCC 
content filter faster than sendmail+dccm (some claim that postfix is so 
much faster than sendmail that a 2x performance hit would still be 
acceptable).

Something like this has the best chance of getting accepted upstream 
because it has no chance of compromising postfix's security model. In 
fact it requires no changes to postfix so upstream's acceptance is moot.

The other option is to patch postfix to support a DCC specific protocol, 
but that has little chance of getting accepted upstream as it isn't a 
generic solution to the "I want to process, possibly modify, possibly 
reject all messages that pass through my server with algorithm Foo" problem.