On 9/12/2012 1:27 PM, DN Singh wrote: > > On Sep 11, 2012 8:43 PM, "Wietse Venema" <wie...@porcupine.org > <mailto:wie...@porcupine.org>> wrote: >> >> DN Singh: >> > We some trouble with rediff deliveries, and therefore were > trying this >> > combination. While searching the archives, we found that rediff > does not >> > like connection caching, and about the recipient_limit option. > The rate >> >> With recipient_limit=1, the Postfix scheduler will try to deliver >> different recipents in parallel. The concurrency is limited only >> by the process limit (in master.cf <http://master.cf>) for the > message delivery >> transport. >> >> You can set that process limit to 1, but that will not change how >> the rate delay works. As before, it will enforce the delay between >> deliveries for the same recipient. >> >> Wietse > Will transport_destination_concurrency work in this case? I am > asking because I had created this transport for the purpose of > throttling. >
The concurrency is automatically limited to 1 when rate_delay is non-zero. (Unless one has also set recipient_limit=1, which changes the delay+concurrency from per-destination to per-recipient, which is what started this discussion) -- Noel Jones