On Sun, Aug 27, 2023 at 11:12:03AM -0700, Bill Sommerfeld via Postfix-users
wrote:
> On 8/27/23 00:13, Wietse Venema via Postfix-users wrote:
> > Would it be sufficient to never send more than 1 recipient per
> > mesage, thus never trigger their temporary "block all mail" strategy,
> > and avoid the need for the kludges described here?
>
> I set smtpserial_destination_rate_delay=60s to put a 60 message/hour
> ceiling on the instantaneous rate, but the documentation on that tunable
> says:
>
> With a corresponding per-destination recipient limit equal to 1,
> the rate delay specifies the time between deliveries to the same
> recipient. Different recipients are delivered in parallel, subject
> to the process limits specified in master.cf.
>
> which suggests that even with a 1-process limit for the slow mailer it
> might still deliver to different recipients back-to-back and only wait
> the full time between two deliveries to the same recipient.
That's exactly what it means.
> In other words, it is unclear from the documentation whether the
> destination_rate_delay is implemented in the transport (consuming a
> transport process while it waits) or in the queue manager.
All rate limits are in the queue manager, the process limit is just
that. It couldn't really be otherwise, and it makes no sense to hog an
idle process. Instead, the queue manager doesn't resume delivery to a
logical destination (nexthop or user@nexthop when the recipient limit is
equal to 1) until the rate delay timer expires. Meanwhile other
deliveries for the same transport may proceed if not also blocked by
either concurrency or rate limits.
I hope that Comcast will relax their limits to allow at least 2 (ideally
closer to 5 or 10) recipients per message so long as the sending system
does not have a "known bad" reputation.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
