Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.74

connect-timeout

<domain>

How long to wait for an outgoing connection to be established
in the configuration this is a lineconnect-timeout 2minside the block <domain>
The first wait in the conversation

A conversation with a receiver is a chain of waits, and this is the first of them. The node opens a connection to the recipient’s server and waits for it to be established. Not for a response, not for a greeting — for the connection itself.

Further along the chain come smtp-greeting-timeout (waiting for the 220 greeting), data-send-timeout (sending the message body) and smtp-data-termination-timeout (waiting for acceptance confirmation). Each has its own default, and together they add up to the maximum time of one attempt.

The vendor default is 2m. By today’s standards this is very long: a live server responds in fractions of a second, and an unavailable one will never respond. Two minutes is time the stream wastes on every dead address.

The main trap is that the default holds up the stream. A connection that will not be established occupies a slot in max-smtp-out for the full two minutes. At a receiver with a dozen MX records, half of which do not respond, the node spends minutes instead of seconds going through them — and the connection limit is occupied all that time.
What the Hub does. It does not write it — the vendor 2m stays. This is a candidate for an edit: at major mailbox providers a connection is either established in milliseconds or not at all, and half a minute is more than enough here.
Recommended values

Half a minute is enough for well-known mailbox providers. Their servers respond instantly; anything longer than a second is already a network fault, and there is no point waiting two minutes for it.

Count it together with the stream. A connection busy waiting occupies a max-smtp-out slot. A long timeout with a small connection ceiling turns into a stalled queue.

Do not confuse it with receiver unavailability. A short timeout does not bounce a message — it only ends the attempt; the next one will come on the retry-after schedule.

Half a minute as a guideline and the rule to count it together with the stream are ours. From the manual here come the 2m default and the fact that the timeout measures establishing the outgoing connection.
Example configuration
# a well-known mailbox provider: the connection is either instant or never
<domain gmail.com>
    connect-timeout 30s</domain>
Shortening it loses no messages: a failed attempt simply ends sooner, and the next one will come on the retry schedule.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Keeping the default with a small connection ceiling

our experience

What it costsEvery failed attempt holds a slot for two minutes. With a ceiling of ten connections and half of the MX records not responding, the queue stalls, although the receiver is alive.
How to spot itThere are connections, no deliveries, and the rate is noticeably below the configured one.
How to do it rightShorten it to half a minute and check it against max-smtp-out.

Shortening it to seconds for speed

our experience

What it costsA receiver behind a slow link or with a loaded load balancer does not manage to accept the connection in time. Attempts end for nothing, and it looks as if the receiver is unavailable.
How to spot itA rise in failed attempts while the receiver is alive and accepts a connection when tried by hand.
How to do it rightKeep it in the order of tens of seconds, not single seconds.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
connect-timeout <time-interval>
Values
a time interval: a number and a letter — d days, h hours, m minutes, s seconds
Default
2m § 3.3.10.74
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload; it does not affect connections already being opened — the new value takes effect from the next attempt.
⇄

Related directives

1 relation

Works together with

smtp-greeting-timeout<domain>The next wait in the same chain: the connection is established, and we wait for the greeting. § 3.3.10.74

How to check on the node
The effective value is printed by the queue settings command; how many connections are currently waiting is visible from the queue list:
pmta show settings gmail.com/vmta1 | grep -i connect-timeout
pmta show queues --connected=yes --no-rcpt-events
A queue with many connections and no deliveries is usually waiting right here. The Hub does not set conversation timeouts and does not collect connection establishment time.
◇

What else to read

3 articles

◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block <domain>:file-destinationauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →