Thanks for your prompt responses.
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?
That's unclear. I'm trying to both avoid the quirks of Comcast's
observed behavior and stay well away from their documented limits at
http://postmaster.comcast.net/smtp-error-codes.php#RL000001
where their lowest-tier rate limit is 120 messages/hour.
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.
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.
On 8/27/23 00:58, Wietse Venema via Postfix-users wrote:
> I think that the 'slow' example should handle this:
Indeed, as that is close to what I ended up with. Thanks for the
pointer -- I hadn't noticed the "slow" example in QSHAPE_README.html as
the file seemed geared only to large-volume sites which I emphatically
am not.
I'd be happy to write up a section on coping with rate limiting for
inclusion in SOHO_README if it would help others.
- Bill
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
