On Wed, Feb 02, 2011 at 05:56:23PM +0100, St?phane MERLE wrote: > Reading this page (English and French), http://www.email-way.com/ > I decided to create a specific transport for the orange destination. > > I just cannot find out which parameters I need to set to comply with : > **- The maximum number of simultaneous connections is limited to 3 per MX
Postfix cannot reliably implement this constraint. A Postfix destination is a *domain*, not an MX host. The queue-manager does not know how many MX hosts a domain has, or even whether a domain is delivered via SMTP. Nor does the queue-manager know which domains are served by the same set of MX hosts, so if multiple domains are hosted, the per-domain concurrency limit will mean a greater limit in total. > is this with orange_tr_destination_concurrency or > orange_tr_destination_concurrency_limit ?? http://www.postfix.org/postconf.5.html#transport_destination_concurrency_limit > **- Do not request more than a 1000 connections per hour No such control, but this is ~1 connection per 3 seconds, but if you are willing to space out message deliveries 3 seconds apart, then: http://www.postfix.org/postconf.5.html#transport_destination_rate_delay The concurrency will then always be "1" and the concurrency limit setting is ignored when a non-zero delay is specified. The rate delay applies to *messages* not connections. > **- Send over a 100 emails per open connection This is not supported by Postfix, rather Postfix has a connection re-use time-limit, the default is 300s, with connections purged after 2s of idle time. If you have a steady stream of mail less than 2s apart a connection may deliver 300s/D messages, where <D> is the time to deliver one message. You could try to lower: http://www.postfix.org/postconf.5.html#smtp_connection_reuse_time_limit to ~30s, if you don't expect an overloaded MX host (for this destination) to ever exhibit transaction latencies larger than ~30s. The recipient's requirements place severe architectural constraints on the sending system's queue scheduler. It is best to ignore them, and the let the recipient suffer the folly of its policies. With Postfix 2.5 (the latest patch level) or higher, there are more advanced rate controls that can be set to react in a more stable manner to "negative feedback" (4XX banners, or EHLO responses or 421 disconnects). If the recipient's systems provide timely feedback to exceeding their limits, you can just let Postfix send as fast as it can, and back-off when that's too fast. http://www.postfix.org/postconf.5.html#default_destination_concurrency_negative_feedback http://www.postfix.org/postconf.5.html#default_destination_concurrency_positive_feedback http://www.postfix.org/postconf.5.html#default_destination_concurrency_failed_cohort_limit http://www.postfix.org/postconf.5.html#transport_initial_destination_concurrency You can try: orange_tr_initial_concurrency = 2 orange_tr_destination_concurrency_limit = 3 orange_tr_destination_concurrency_failed_cohort_limit = 5 orange_tr_destination_concurrency_positive_feedback = 1/5 orange_tr_destination_concurrency_negative_feedback = 1/8 -- Viktor.
