(no email)
Date: Fri Mar 01 2002 - 16:21:53 EST
>
> This is certainly good information. My problem would be minimizing the
> increased overhead. If there was a way to conditionally route via
> the filter, based on sender address then we're fine but that brings us
> back to sender based routing which is not what postfix is all
> about, as you point out.
The factor can be reduced to a factor of two if the script avoids
both writing the message to disk and injecting into the "maildrop" using
the command line sendmail. Specifically a script that uses direct "SMTP"
submission can stream the input doing RFC2821 transparency (leading "." ->
"..") into the backend SMTP listener (port 10025 w/o content_filter per
FILTER_README), terminate it with a "." and return the remote response
converted to an equivalent "sendmail" exit code. The response to exit code
mappings can be found in any good Sendmail reference.
The correspoding pipe transport may need a recipient limit of 1 and
needs to be configured to abort the transmission (not send DATA) and fail
for all the recipients if *any* are rejected. (All or nothing semantics,
this is a reasonable configuration because invalid recipients will have
been filtered out in prior stages of processing, the only pitfall is
local_recipient_maps which needs to be empty in the back end SMTP
listener).
This eliminates two extra copies. Note that not all the performance
cost is in the I/O and not all systems are I/O bound, although most
Postfix installations will run out of disk bandwidth before they run out
of CPU or memory. This can change if one adds virus scanning to the job
description of the content_filter.
-- Viktor. - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|