On 31/03/2011 18:39, Victor Duchovni wrote: > On Thu, Mar 31, 2011 at 10:15:55AM +0200, Ultrabug wrote: > >> Dear list, >> >> I'm facing a problem where I have to adapt and optimize my smtp servers >> to a host's constraints which are as follow : >> >> - maximum 3 connections to each MX of the host (he has 10 MX so >> potentially I should be able to make 30 connections) > > What happens if you happen to exceed the limit on particular host > among the 10? If it just quickly returns a 4XX code, and does not > penalize future connections, ignore this limit and let Postfix do > what it does by default. >
The result is pretty much that they deny any further email with 4XX codes AND penalize further connections. It just stops accepting any new mail. >> - maximum 1000 connections per MX per hour > > Connection caching should help if volume is high enough to worry about > this. Note this is just less than one connection every 3 seconds, but > Postfix caches idle connections for 2 seconds, so if your output rate > is 1200 messages spaced perfectly 3 seconds apart, you lose, but this > is fairly unlikely. > Ok, connection caching I do already and I don't think to fall into this limitation. >> - maximum 100 emails sent per connection > > Postfix has no such limit, instead a connection is retired if idle > for more than 2 seconds, or after 300s (tunable). Again the site > should just return a 4XX response to RSET, and Postfix will drop > the connection and build a new connection, probably to another host. > >> My problem is that this setup is far from optimal compared to the >> limitations and it slows down a lot my email delivery rate to these domains. >> >> Anyone have any tips on how I could do this better please ? > > The receiving sites policies are stupid if they don't implement > them sensibly by just returning 4XX responses without penalizing > subsequent transactions. > > Have you in fact observed that default Postfix settings run into trouble > with this site? Oh yes, it ends up with thousands of mails deferred which in turn would try again at a too high rate so the pile remains deferred etc etc Have you considered the less aggressive concurrency > feedback controls in Postfix 2.5? > > slow_initial_concurrency = 2 > slow_destination_concurrency_limit = 15 > slow_destination_concurrency_failed_cohort_limit = 5 > slow_destination_concurrency_positive_feedback = 1/5 > slow_destination_concurrency_negative_feedback = 1/8 > This sounds interesting indeed, I didn't understand fully these cohort/feedback options, I'll give them a try ! > and if absolutely necessary, in master.cf: > > slow unix - - n - - smtp > -o smtp_connection_reuse_time_limit=30s > > (the remote side starts rejecting traffic consistently instead of > sending 421 for the 100th RSET over a given connection). > Many tanks for your time and help
