Debugging Postfix SMTP AUTH Connection Drops: TLS Requirements and Rate Limiting Issues


3 views

When examining Postfix SMTP authentication issues, the following log pattern is particularly interesting:

Nov 29 12:09:38 mta postfix/smtpd[8362]: connect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: disconnect from unknown[183.13.165.14]
  • No SASL authentication failures are logged
  • Connection terminates immediately after AUTH command
  • IP address appears in rapid succession with new process IDs
  • System requires TLS before AUTH (per submission port 587 or SMTPS 465 standards)

From my experience troubleshooting similar issues, here are the most likely scenarios:

1. Missing or Improper TLS Handshake

Clients attempting to authenticate without proper encryption:

# Check your main.cf for these crucial settings:
smtpd_tls_security_level = encrypt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key

2. Client-Side Timeout Issues

Some mail clients have aggressive timeouts during the AUTH negotiation:

# Consider adjusting these values in main.cf:
smtpd_timeout = 300s
smtpd_proxy_timeout = 100s

3. Rate Limiting False Positives

Even with smtpd_client_connection_rate_limit set:

# Verify your current limits:
postconf smtpd_client_connection_rate_limit
postconf smtpd_client_message_rate_limit
postconf smtpd_client_event_limit_exceptions

Here's how I typically troubleshoot these cases:

# 1. Enable verbose logging
postconf -e debug_peer_level=2
postconf -e debug_peer_list=183.13.165.14

# 2. Check protocol-level interaction
tcpdump -i eth0 -n -s0 port 587 and host 183.13.165.14 -w auth_capture.pcap

# 3. Test with known-good client
openssl s_client -connect yourserver:587 -starttls smtp -crlf -quiet

For enterprise deployments, consider these additional measures:

# Require specific cipher suites
smtpd_tls_mandatory_ciphers = high
smtpd_tls_eecdh_grade = strong

# Implement proper greylisting
postconf -e smtpd_recipient_restrictions=permit_mynetworks,\
    check_policy_service inet:127.0.0.1:10023,\
    reject_unauth_destination

# Monitor AUTH attempts
postconf -e smtpd_sasl_authenticated_header=yes

Here's a working configuration snippet from a production server that resolved similar issues:

# /etc/postfix/main.cf excerpt
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes
smtpd_tls_security_level = encrypt
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 30
smtpd_error_sleep_time = 10s

When analyzing mail server logs, you might encounter connection drops immediately after AUTH:

Nov 29 12:09:38 mta postfix/smtpd[8362]: connect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: disconnect from unknown[183.13.165.14]

The key factor here is your security policy requiring encrypted connections:

# In main.cf
smtpd_tls_auth_only = yes
smtpd_tls_security_level = encrypt

This creates two possible scenarios:

  • Clients attempting plaintext AUTH get rejected (normal behavior)
  • Clients failing TLS negotiation during AUTH phase get logged differently

To verify if this is a TLS handshake issue:

# Check TLS negotiation in logs
grep "TLS handshake failed" /var/log/mail.log

Common causes include:

  • Outdated SSL/TLS protocols on client side
  • Incompatible cipher suites
  • Certificate validation failures

Add these diagnostic settings to main.cf:

# Enhanced logging
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes

# Protocol restrictions (modern best practice)
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1

Use OpenSSL to simulate client connections:

# Test STARTTLS negotiation
openssl s_client -starttls smtp -connect your.mail.server:25 -tlsextdebug

# Test direct SMTPS
openssl s_client -connect your.mail.server:465 -tlsextdebug

While you have smtpd_client_connection_rate_limit set, also consider:

# Prevent connection storms
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_client_message_rate_limit = 100

For deep troubleshooting, capture the TLS handshake:

tcpdump -i eth0 -s 0 -w postfix.pcap port 25 or port 465 or port 587

Analyze with Wireshark looking for:

  • ClientHello/ServerHello sequence
  • Certificate exchange
  • Alert messages (if any)

These connection attempts could indicate:

  • Legitimate clients with misconfigured encryption
  • Scanning/bot activity testing server responses
  • Potential dictionary attack preparation

Consider implementing fail2ban rules for repeated AUTH failures:

# In jail.local
[postfix-auth]
enabled = true
filter = postfix-auth
logpath = /var/log/mail.log
maxretry = 3
findtime = 3600
bantime = 86400