Postfix间歇性邮件投递失败（连接超时）问题排查及无问题证明需求求助

Hey there, let's walk through your problem systematically—we'll cover how to diagnose those intermittent connection timeouts and how to gather evidence that your Postfix setup isn't the root cause.

First, let's recap the key details to make sure we're on the same page #

• Your setup: Oracle Linux server running Postfix, receiving emails from another Postfix instance, then relaying outbound through Fortinet Cloud Email Security Gateway
• Symptom: Intermittent "Connection timed out" errors when trying to connect to abc.fortimailcloud.com:25 (both Postfix deliveries and manual telnet attempts fail), but delivery resumes automatically after a few minutes
• Context: You're sending bulk promotional emails, and your list includes many invalid addresses/domains; Fortinet's team claims no issues on their end and that they don't validate recipient addresses

Step 1: Diagnose the root cause of intermittent timeouts #

Since timeouts are often network-related, start here to narrow down where the issue lies:

Network Layer Checks #

• Capture traffic during timeouts
  Use tcpdump to record network traffic to the Fortinet IP when issues occur. Run this command on your Postfix server:

  sudo tcpdump -i any host x.x.x.x and port 25 -w fortimail_timeout.pcap
  

  Let it run until you hit a timeout, then stop it. Analyze the PCAP:

  • If you see SYN packets sent from your server but no SYN-ACK response from x.x.x.x, the issue is either with Fortinet's end or the network path between you two
  • If no SYN packets are sent, that points to a local network/Postfix block

• Continuous connectivity monitoring
  Use mtr (combines ping + traceroute) to track packet loss over time. Run:

  mtr --report-cycles 100 x.x.x.x
  

  This will show you which network hop is dropping packets during timeouts. If loss only happens at the final hop (Fortinet's IP), that's strong evidence their end is the problem.

• Local firewall/SELinux validation
  Check if your Oracle Linux firewall (firewalld/iptables) is intermittently blocking outbound port 25:

  • For firewalld: sudo firewall-cmd --list-all to confirm outbound port 25 is allowed
  • For SELinux: Check audit logs with sudo grep -i deny /var/log/audit/audit.log to see if it's blocking Postfix's outbound connections. You can temporarily set SELinux to permissive mode (sudo setenforce 0) to rule it out (just remember to set it back to enforcing afterward if it doesn't help).

• DNS resolution consistency
  Verify that abc.fortimailcloud.com always resolves to the correct IP. Run dig +short abc.fortimailcloud.com multiple times over a period—if you get different IPs, intermittent resolution to a faulty IP could cause timeouts.

Postfix Configuration & Resource Checks #

• Concurrency/rate limits
  Bulk email can trigger unintended limits. Check your Postfix concurrency settings:

  postconf | grep -E 'concurrency_limit|connection_limit|rate_delay'
  

  If smtp_connection_limit or default_destination_concurrency_limit is set very high, you might be hitting Fortinet's unstated rate limits. Try lowering these temporarily to see if timeouts decrease.

• Queue & resource health
  A backlog of invalid emails could strain Postfix resources. Check your queue with:

  postqueue -p
  

  If you see thousands of stuck messages, clean up invalid addresses from your list first to reduce queue pressure. Also, monitor Postfix's resource usage during timeouts with top or htop—if CPU/memory is maxed out, that could cause connection delays, but this is less likely if manual telnet also fails.

• Enhanced Postfix logging
  Enable debug logging for the Fortinet peer to get more details on connection attempts. Add these lines to main.cf:

  debug_peer_list = x.x.x.x
  debug_level = 3
  

  Then reload Postfix (sudo systemctl reload postfix). The next timeout will generate detailed logs showing exactly what Postfix is doing when the connection fails—this will prove if Postfix is correctly initiating the connection or hitting an internal error.

Step 2: How to prove Postfix is not the issue #

To demonstrate your Postfix setup is working as intended, gather these pieces of evidence:

1. Postfix log evidence
   Extract logs from the timeout window. Look for entries like:

   "Delivery temporarily suspended: Connect to abc.fortimailcloud.com[x.x.x.x]:25: connection timed out."
   This shows Postfix is actively trying to connect but isn't getting a response—clearing Postfix of blame.

2. PCAP capture evidence
   As mentioned earlier, a PCAP showing your server sending SYN packets but receiving no SYN-ACK proves the problem is outside Postfix's control.

3. Cross-test with other tools
   During a timeout, try connecting to another public SMTP server (e.g., smtp.gmail.com:587—note: you might need to allow outbound 587 in your firewall) using telnet or nc:

   nc -zv smtp.gmail.com 587
   

   If this connection succeeds but connecting to Fortinet's IP fails, it confirms the issue is specific to Fortinet's service, not your server or Postfix.

4. Resource monitoring data
   Collect CPU, memory, and file handle stats during timeouts (using top, vmstat, or lsof -p $(pidof postfix/smtp)). If Postfix has plenty of available resources, it shows the server isn't overwhelmed and Postfix is operating normally.

Final Recommendations #

• Clean up your email list: Even if Fortinet doesn't validate addresses, sending thousands of invalid emails can trigger behavioral limits from cloud providers (even if they don't explicitly state it). Use a tool to pre-validate domains and addresses before sending.
• Share evidence with Fortinet: If your logs and PCAPs show the issue is on their end or the network path, present this data to their support team—it's hard to argue with concrete packet-level evidence.

备注：内容来源于stack exchange，提问作者Diads