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.
> - 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.
> - 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? 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
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).
--
Viktor.
