Demo
Demo

Knowledge base

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

smtp-greeting-timeout

<domain>

How long to wait for the 220 greeting after the connection is established
in the configuration this is a linesmtp-greeting-timeout 5minside the block <domain>
The connection is established, the receiver is silent

The connection is established — which means connect-timeout has already done its part. Now the receiver must introduce itself with a 220 line. That wait is what this timeout measures.

Silence after connecting is a meaningful signal. Receivers deliberately delay the greeting: some check whether the sender starts talking too early (that is how spam bots are caught), others use it to slow down those they do not trust. A long greeting is often not a breakdown but an attitude toward you.

The vendor default is 5m. Five minutes of silence in a mail conversation mean nothing except a wasted connection slot.

The main trap is that the default masks slowing down. A receiver that delays its greeting by half a minute is telling you its attitude; with a five-minute timeout you do not notice it and keep sending at the same rate. A delayed greeting is an early sign of reputation deterioration, and losing it is a pity.
What the Hub does. It does not write it — the vendor 5m stays.

The Hub measures time to greeting only in the proxy check — the banner_ms field, including connection establishment — and uses it to grade the proxies themselves. It does not measure greeting delay on deliveries from the nodes, although this is the earliest signal: it appears before temporary refusals and before delivery rates drop.

Recommended values

A minute is more than enough. A receiver that takes more than a minute to say hello is either overloaded or deliberately slowing you down; waiting four more minutes for it is pointless.

Do not go below ten seconds. Receivers that check for premature talking deliberately hold a pause of a few seconds — too short a timeout will cut you off exactly where you are doing things right.

Count it together with the stream. Waiting for the greeting occupies a max-smtp-out slot just like any other wait.

The minute as a guideline, the lower bound of ten seconds and treating the delay as a signal are ours. From the manual come the 5m default and the fact that the timeout measures waiting for the 220 line after the connection is accepted.
Example configuration
# a receiver that takes more than a minute to say hello has nothing good to tell us
<domain gmail.com>
    connect-timeout 30s
    smtp-greeting-timeout 1m</domain>
Both timeouts run consecutively: first the first one completes, and only then does the second start counting.
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 and not noticing the slowing down

our experience

What it costsThe receiver delays its greeting, signaling that it does not like you. With a five-minute timeout this looks like a slow network, and nobody lowers the rate — and then temporary refusals follow.
How to spot itAttempt time has grown, there are no refusals yet.
How to do it rightCut it to a minute and treat a timeout trigger as a signal, not as a network error.

Setting a few seconds

our experience

What it costsReceivers that check the sender with a deliberate pause before the greeting are cut off entirely — even though you actually pass the check.
How to spot itSome domains stopped accepting mail right after the edit.
How to do it rightKeep it at no less than ten 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
smtp-greeting-timeout <time-interval>
Values
a time interval: a number and a letter — d days, h hours, m minutes, s seconds
Default
5m § 3.3.10.75
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 is merged 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 open connections.
⇄

Related directives

2 relations

Works together with

data-send-timeout<domain>The next wait in the same chain, when the conversation gets to the message body. § 3.3.10.76connect-timeout<domain>The previous wait in the same chain: first the connection, then the greeting. § 3.3.10.75

How to check on the node
The effective value is printed by the queue settings command; the greeting itself is visible in the log if conversation logging is on:
pmta show settings gmail.com/vmta1 | grep -i greeting-timeout
grep -F '220 ' /var/log/pmta/pmta.log | tail -10
Greeting delay is awkward to calculate from the log: the connection time and the greeting time are on different lines. The Hub does not collect this value from deliveries.
◇

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>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →