Wietse, Excellent — that's exactly the pattern I didn't know existed. Thank you for the additional context (and for catching the cut-and-paste in the first version). For our current scale we're not pressing the per-destination 60/min ceiling, so we'll stay on default_destination_* tuning for now. But the parallel-transports + randmap pattern is now logged in our internal documentation as the next throughput rung if and when we need it — between concurrency_limit tuning and provisioning a new MTA node. Good to have the option without leaving the single-server config. Thanks again for the patience walking us all the way through this thread. Closing on our side. Yoda


On 5/5/26 9:57 AM, Wietse Venema wrote:
Wietse Venema:
Yoda via Postfix-users:
  Our updated tuning rules:                                                                                            
                                                                  
    - Minimum rate_delay is 1s. Sub-second is architecturally                                                          
      impossible at the rate_delay knob, full stop.               
    - Always set time values at default_destination_* (qmgr fatals                                                     
It is possible if you can afford to configure multiple delivery transports
that have parallel rate delays.

Below is an old posting.

	Wietse

I'm working in an email marketing firm, we send more than 50 millions of
emails per month, and use postfix for that, and can't resolve a problem
with transport for gmail,  in destination_rate_delay, only
accepts integers,  why can not use a float?
The rate delay feature was implemented for end users with an ISP
that allows only a limited volume of outbound email (less than
3600/hour). It turned out to also help for sending mail to providers
such as Hotmail with very low rate limits.

The rate delay implementation does not work well for bulk mail,
because it limits the concurrency to only one delivery at a time.
So the proper fix is not changing ints to float, but allowing more
than one delivery at a time.
However, you can increase concurrency by using multiple SMTP
transports and random selection.
Damn!. Cut and paste error.

	Wietse

In /etc/postfix/master.cf:

    smtp1      unix  -       -       n       -       -       smtp
    smtp2      unix  -       -       n       -       -       smtp
    ...
    smtpN      unix  -       -       n       -       -       smtp

    smtp1_destination_concurrency_failed_cohort_limit = 10
    smtp2_destination_concurrency_failed_cohort_limit = 10
    ...
    smtpN_destination_concurrency_failed_cohort_limit = 10

In /etc/postfix/main.cf:

    smtp1_destination_rate_delay = 1
    smtp2_destination_rate_delay = 1
    ...
    smtpN_destination_rate_delay = 1

    transport_maps = 
        inline:{
                { $myhostname = $local_transport }
                { localhost = $local_transport }
                { localhost.$mydomain = $local_transport }
                # Other domains that don't deliver over SMTP...
        } randmap:{ smtp1:, smtp2:, ..., smtpN: }


_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to