Fri Aug 23 15:53:10 UTC 2002
Vernon Schryver wrote: >>From: Matt Armstrong <email@example.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.
More information about the DCC