On 3/22/2011 8:33 AM, Kenneth Holter wrote: > Thanks for the quick reply. > > Your solution seems to be a very good one, but unfortunately that > default_destination_rate_delay parameter is not available in the > postfix version I'm running (2.3). I'm using the postfix > implementation shipped with RHEL 5, which is not the most current one. >
The most recent release of Postfix is 2.8.2. 2.3 is ancient and no longer supported for updates. Redhat now has RHEL 6 which, I believe, uses Postfix 2.7. There are reliable (S)RPM packages available for RHEL 5 that will get you to the parameters/functionality you need. The most common is by Simon Mudd referenced on http://www.postfix.org/packages.html at http://ftp.wl0.org/official/ Brian > - Kenneth > > On Tue, Mar 22, 2011 at 10:32 AM, Reindl Harald <[email protected]> > wrote: >> Am 22.03.2011 09:05, schrieb Kenneth Holter: >>> Hi all. >>> >>> I'm new to the list, and quite new to postfix. >>> >>> I'm running postfix 2.3 on one of my RHEL 5 servers, and have set up >>> postfix to forward all emails to our Microsoft Exchange >>> infrastructure. >>> On the server running postfix, I have an applications that >>> automatically generates emails. The issue I'm trying to solve is that >>> at times, the application generates enormous amounts of emails, >>> causing nearly a DoS attack on the Exchange servers. >>> >>> What I'd like to do is to have my postfix server rate limit the number >>> of emails it's forwarding to the Exchange servers. For example, if I >>> could get it to queue up emails, either on the inbound side or the >>> outbound side, and forward them on a steady rate, that would be great. >>> Note that all emails are generated locally on the server. >>> >>> Postfix seems to be a rather complex software, and I've not been able >>> to identify which component I should be tuning to accomplish rate >>> limiting. Any advice on this is greatly appreciated. >> we are using this setting to only send one message per destination and second >> the problem is that "default_destination_rate_delay" only accepts whole >> seconds as delay and it depends on the count of messages if you can >> live with this, with < 10.000 mails per day 1 second delay for every >> destination is ok >> >> initial_destination_concurrency = 5 >> smtp_destination_concurrency_limit = 5 >> default_destination_recipient_limit = 15 >> default_destination_concurrency_limit = 5 >> default_destination_concurrency_failed_cohort_limit = 5 >> default_destination_rate_delay = 1 >> transport_retry_time = 30 >> >> if there are too messages for wait a second maybe you >> should set concurrency even lower and disable rate_delay >> >>
