Connected, but no SMTP banner received within Xs

This Uptime Monitoring error appears in your Location Fail Log when you are using an SMTP monitor and our monitoring node was able to successfully open a TCP connection to your mail server, but the server did not send its initial SMTP greeting (the 220 banner) within X seconds.

When a mail client connects to an SMTP server, the server is expected to speak first by sending a greeting line such as:

220 mail.example.com ESMTP ready

Our SMTP monitors wait up to 30 seconds (or your monitor’s configured timeout, if you’ve set it higher) for this greeting to arrive. If the greeting does not arrive in time, the check is marked as failed, even though the TCP connection itself was successful. This is also why your server may appear reachable (ping OK, port open, connections visible in your mail logs) while the SMTP check is failing.

Possible causes

  • Anti-spam greeting delays. Many mail servers deliberately delay their greeting to catch spam bots that start talking before the banner is sent. Examples include Postfix postscreen’s greet_wait, sendmail’s greet_pause, and similar features in commercial mail filtering appliances. Short delays are fine, but if the delay (occasionally or always) exceeds 30 seconds, the check will fail.
  • Reputation-based throttling or rate limiting. Some mail servers and appliances (for example, the Host Access Table sender group policies on Cisco ESA devices) may tarpit, throttle, or delay sessions from IP addresses they don’t recognize. Since our monitoring nodes connect to your server every minute, they can end up rate-limited by such policies.
  • Server overload. A mail server that is at its connection limit or under heavy load may accept new TCP connections but take a long time to assign them a session and send the greeting.
  • Slow lookups at connection time. Some mail servers perform DNS, rDNS, or DNSBL lookups on each connecting IP before sending the greeting; if these lookups are slow or timing out, the greeting is delayed for every client.

Recommended solution

Your Location Fail Log contains the exact timestamp of each failed check and the monitoring IP address that performed it. Check your mail server’s logs for connections from that IP at those timestamps to see how the session was handled and why the greeting was delayed.

If your mail server uses greeting delays, throttling, or reputation-based connection policies, we recommend whitelisting our monitoring IP addresses in the mechanism itself, so that your server greets our monitoring nodes immediately. For example:

  • Postfix: add our monitoring IPs to postscreen_access_list with a permit action
  • Sendmail: add GreetPause:<monitoring IP> 0 entries to your access map
  • Cisco ESA and similar appliances: add our monitoring IPs to a trusted sender group with rate limiting and tarpitting disabled

Please note that whitelisting our IPs in your firewall or DNSBL exemptions alone is usually not enough, as it does not skip the pre-greeting delay itself.

Tagged: