Web服务器SMTP邮件投递故障求助：队列阻塞连接被远程断开

Let's break down your issue: you've confirmed port 25 connectivity via telnet, but emails sit in the Pickup queue, Event Viewer logs show remote host disconnections, and SMTPDiag fails to get a 220 response. Here are targeted troubleshooting steps to nail down the root cause:

1. Validate HELO/EHLO Handshake Behavior #

Many Exchange and SMTP relays enforce strict checks on the client's HELO/EHLO identifier. If your web server's SMTP service sends a hostname that doesn't match reverse DNS (PTR) records, or violates the target server's SPF/DKIM policies, the connection will drop immediately after the initial handshake.

• Test manually via telnet on your web server:

  telnet <TARGET_IP> 25
  # After connecting, send:
  HELO your-web-server-hostname
  

  If the connection drops right after this command, the identifier is likely the issue. Adjust the SMTP service's "Hello" property in your server's SMTP settings to match a valid, reverse-resolvable hostname.

2. Check for Mandatory TLS/STARTTLS Requirements #

Modern mail servers often require encrypted connections via STARTTLS on port 25. While telnet can establish a basic TCP connection, it doesn't handle TLS negotiation—so your SMTP client might be failing to upgrade the connection, causing the remote host to disconnect.

• Test TLS connectivity from your web server using OpenSSL:

  openssl s_client -connect <TARGET_IP>:25 -starttls smtp
  

  Look for errors like "certificate verify failed" or "handshake failure". If this fails, enable TLS in your web server's SMTP configuration and ensure the client uses a valid certificate (if required by the relay).

3. Inspect Target Server's SMTP Receive Logs #

Your server's logs only tell half the story—the remote Exchange/relay server's receive logs will explicitly state why it dropped the connection. Common reasons include:

• Temporary IP block (due to previous failed attempts or spam reputation)
• Sender domain not allowed by the relay's acceptance policies
• Email content triggering spam filters (e.g., suspicious keywords, invalid headers)

Reach out to the team managing the target server to retrieve these logs—they'll give you a definitive answer.

4. Verify SMTP Service Queue & Pickup Directory Health #

Sometimes the queue stagnation isn't about delivery failures, but the SMTP service itself:

• Restart the SMTP service on your web server to rule out transient service glitches.
• Check if the Pickup directory has correct permissions (the SMTP service account needs read/write access).
• If the queue database is corrupted, back up all pending emails in the queue directory, clear it, and restart the service to rebuild the database.

5. Ensure SMTPDiag Tests Use the Same Source IP #

SMTPDiag results can be misleading if you run them from a different machine than your web server. The target server might have IP-based access controls that allow your local machine but block the web server's IP.

Run SMTPDiag directly on the web server with the exact sender/receiver domains you're using:

SMTPDiag.exe recipient@mydomain.com sender@yourwebserver.com /s:server.domain.com

The detailed output will highlight if the issue is specific to the web server's source IP.

内容的提问来源于stack exchange，提问作者kaotik169