A company runs a Postfix mail server that relays mail for internal clients. Users report that emails to a specific external domain 'example.org' are delayed by several hours. The administrator checks the mail logs and sees entries like: 'status=deferred (connect to mx.example.org[203.0.113.10]:25: Connection timed out)'. What is the most likely cause?
Connection timed out suggests the remote server is not responding, often due to firewall or server issues.
Why this answer
The log entry 'Connection timed out' indicates that the company's Postfix server successfully resolved the MX record for example.org to the IP 203.0.113.10 but could not establish a TCP connection to port 25 on that host. This is consistent with the remote server explicitly blocking inbound connections from the company's IP, often via a firewall rule or access control list, rather than a DNS or rate-limiting issue.
Exam trap
The trap here is that candidates confuse 'deferred' with a relay authorization issue or a DNS problem, but the specific 'Connection timed out' error points to a network-layer block rather than an SMTP-level rejection or misconfiguration.
How to eliminate wrong answers
Option A is wrong because relaying authorization (e.g., permit_mynetworks, smtpd_relay_restrictions) controls whether Postfix accepts mail from clients for delivery, not whether it can connect to a remote server; the deferral occurs after the mail is accepted. Option B is wrong because the log shows a successful MX resolution to 203.0.113.10, meaning the DNS record is valid and points to an existing host; a misconfigured MX would cause a different error like 'Host not found' or 'Name service error'. Option D is wrong because rate limiting typically results in a connection being accepted but then throttled (e.g., '450 4.7.1 Service unavailable' or '421 Too many connections'), not a TCP-level timeout; a timeout suggests the remote host is not responding at all, which is characteristic of a firewall block.