New DR Appliance Joins Cluster but Rejects Valid Recipients
Global manufacturer with 4,200 mailboxes runs two ESAs in a cluster: esa01 in Chicago and esa02 in a new Frankfurt DR site. The inbound listener uses an LDAP accept query against a single Active Directory domain controller in Chicago. After esa02 is added and committed, about 8% of inbound messages addressed to the Frankfurt subsidiary are rejected by esa02 with '550 5.1.1 User unknown', while the same recipients are accepted by esa01. Message tracking shows the upstream load balancer is routing those messages to esa02. The firewall team confirms SMTP 25 and HTTPS 443 are open between sites, but LDAP 389 and 636 were never opened from Frankfurt. The administrator wants to disable LDAP recipient validation on esa02 to restore mail flow, and asks whether cluster replication should have copied the LDAP profile.
1. What is the most likely cause of the recipient rejections on esa02, and what checks would you perform before changing any configuration?
Read the worked answer
The likely cause is that the LDAP accept query is evaluated locally by each appliance, but esa02 cannot reach the Chicago domain controller on LDAP 389/636. Cluster replication copies configuration objects such as the LDAP server profile and listener settings; it does not copy network reachability, firewall state, or directory availability. Confirming checks:
- Run the LDAP test from esa02 using the same server profile and query used by the listener.
- Check
mail_logson esa02 for LDAP timeouts, connection refused, or bind failures at the same timestamps as the 550 rejections. - Verify the listener's LDAP accept query and server profile are identical across the cluster after commit.
- Confirm routing and firewall rules from the Frankfurt subnet to the Chicago DC, not just SMTP/HTTPS ports.
If the LDAP test fails from esa02 while succeeding from esa01, the fault is connectivity or directory access, not the cluster configuration.
2. Evaluate the proposal to disable LDAP recipient validation on esa02. What would you recommend instead, and why?
Read the worked answer
Disabling LDAP accept on esa02 would stop the 550 errors, but it would turn that listener into an open recipient gate for the Frankfurt path: the ESA would accept recipients it cannot verify, then generate backscatter or relay rejects later. That is especially risky because the upstream load balancer can send any inbound message to esa02.
Better options, in order:
- Open LDAP 389/636 from the Frankfurt appliance to the Chicago domain controller and re-test.
- If WAN latency or firewall policy makes that unacceptable, deploy a read-only domain controller or LDAP replica in Frankfurt and point esa02's LDAP profile at it. Keep the accept query aligned with the Chicago query.
- If neither is possible, route Frankfurt-bound mail only to esa01 until directory access is available; do not silently disable validation.
After any change, commit the cluster and verify with test recipients that esa02 accepts valid users and rejects invalid ones.