On Tue, Jul 10, 2012 at 10:06:54AM +0200, Thomas Spycher wrote:

> Uhhh, this is a much more [sic] better Solution than getting this done
> by the content filter.  I've set smtp_destination_recipient_limit = 1

I did point out that this should be a "dedicated" transport used
only for sending mail to the content filter. So generally, it should
NOT be the "smtp" transport. Even if in practice all mail leaving 
your system is single recipient as a result of the content filter.

I used to call the filter transport "scan", and in my case adjust
the "scan_destination_recipient_limit = 1000" (higher than the
default 50) so as to avoid wasting CPU on multiple scans of a single
messages sent to 1000 recipients (the smtpd_recipient_limit).

Your case is the other extreme, but make the intent of the setting
clear to others looking at your configuration by choosing a suitably
descriptive transport name for the content fitler stage.

This has the side-effect of changing the round-robin strategy when
volume is high from one queue per nexthop to one queue per recipient
address. Thus with:

        content_filter = smtp:[127.0.0.1]:10025

with the recipient limit > 1 there is a single queue with FIFO
delivery, but with the limit = 1, there are multiple queues with
messages going out round-robin by recipient and FIFO for a given
recipient. Because the queues are now per-recipient you probably
should reduce the "concurrency" limit, which now controls how many
simultaneous deliveries are bound for a single recipient, for example:

        <transport>_destination_concurrency_limit = 2

is the concurrency limit for the "local" transport, which is by
default a one recipient per delivery transport.

The above description of the scheduling strategy is only approximate
because the now default "new" queue manager implements a rather
complex pre-emption strategy to prevent a single message with lots
of recipients hogging the queue. So you have a substantial volume
of messages with large recipient counts (mailing list traffic)
mixed in with smaller messages, the scheduler is too complex to
explain here see

        http://www.postfix.org/SCHEDULER_README.html#jobs

if you're feeling brave (this is perhaps developer design documentation
rather than user documentation and is not an easy read).

> > For example:
> > 
> >     main.cf:
> >             content_filter = cf_smtp
> >             cf_smtp_destination_recipient_limit = 1
> > 
> >     master.cf:
> >             cf_smtp unix ... smtp

Do use a sensible custom transport such as "scan", "cf_smtp", ...
whatever makes most sense in your environment.

-- 
        Viktor.

Reply via email to