Discussion:
initial_destination_concurrency and too many sessions
(too old to reply)
Alex
2016-07-29 21:41:25 UTC
Permalink
Hi, I have a fedora23 system with postfix-3.0.4 configured as a mail
relay and having some difficulty reaching some destinations due to
apparent problems with too many concurrent connections.

I'm trying to solve the problem where this relay receives mail from
one of the corporate servers where it is scanned on this relay server
before being sent on to user's mailboxes.

279628D68138D 33026 Fri Jul 29 17:09:21 ***@example.com
(host mailstore1.secureserver.net[72.167.238.32] refused to talk to
me: 421 p3plibsmtp01-06.prod.phx3.secureserver.net bizsmtp Connection
refused, too many sessions from 66.104.132.100. Please lower the
number of concurrent sessions. IB007 <http://x.co/rlbounce>)

I've tried to configure destination concurrency, but I must not be
doing it correctly. Can someone review my changes and let me know what
I'm doing wrong?

transport_maps = regexp:/etc/postfix/transport_limit
default_destination_concurrency_limit = 10

turtle_initial_destination_concurrency = 1
turtle_destination_concurrency_limit = 1
turtle_destination_rate_delay = 4s
turtle_destination_recipient_limit = 2

/etc/postfix/transport_limit:
/secureserver\.net$/ turtle:

I realize that by setting initial_destination_concurrency to 1 it's on
a per-domain basis, which is what I believe I need.

I've read the TUNING_README (a number of times over the years), but
perhaps it was written before sites like secureserver.net have chosen
to restrict inbound connections, not because of load, but instead for
spam protection?

Can someone make some recommendations on what the suggested/acceptible
number of concurrent connections to sites like secureserver.net and
others would be?

Thanks,
Alex
Wietse Venema
2016-07-29 21:58:06 UTC
Permalink
Post by Alex
I realize that by setting initial_destination_concurrency to 1 it's on
a per-domain basis, which is what I believe I need.
That is not what the documentation says. First, it is a different
parameter name that causes the switch in concurrency scheduling,
and second, the behavior is the exact opposite of what you say.

With a per-destination recipient limit of 1, the concurrency
limit is per-recipient instead of per domain.

Wietse
Viktor Dukhovni
2016-07-29 22:15:51 UTC
Permalink
Post by Alex
(host mailstore1.secureserver.net[72.167.238.32] refused to talk to
me: 421 p3plibsmtp01-06.prod.phx3.secureserver.net bizsmtp Connection
refused, too many sessions from 66.104.132.100. Please lower the
number of concurrent sessions. IB007 <http://x.co/rlbounce>)
Note that the nexthop domain "example.com" is not
"mailstore1.secureserver.net", which the MX host for the nexthop
domain.
Transport lookups are by nexthop domain, not MX hostname. Also
the regexp is not sufficiently specific, but that's not important,
since you'll end up deleting this transport table.
Post by Alex
I've tried to configure destination concurrency, but I must not be
doing it correctly. Can someone review my changes and let me know what
I'm doing wrong?
transport_maps = regexp:/etc/postfix/transport_limit
This is useless unless you're sending a lot of mail to recipients
in domains that end in "secureserver.net". This is likely not your
problem.
Post by Alex
turtle_initial_destination_concurrency = 1
turtle_destination_concurrency_limit = 1
turtle_destination_rate_delay = 4s
Once you set "destination_rate_delay", the concurrency is automatically
set to 1.
Post by Alex
turtle_destination_recipient_limit = 2
The lower you set this, the more mail you end up sending when you
have messages with multiple recipients. For RFC 5321 interoperability,
they are required to accept 100 recipients. Surely they accept at
least 10 or even 50 (which is what Postfix sends by default).
Post by Alex
I realize that by setting initial_destination_concurrency to 1 it's on
a per-domain basis, which is what I believe I need.
The two are unrelated. Wietse's comment was hasty, he misread your
message to say a *recipient* concurrency of 1, but that's 2.

Postfix has no per-MX-host rate limits, the scheduler (qmgr) is
not MX-aware.
--
Viktor.
Loading...