Transparent-Mode Relay Denial for an Internal Application
A manufacturer runs Exchange 2019 for 2,400 mailboxes and has inserted a FortiMail 7.2 appliance in transparent mode between its edge SMTP gateway and Exchange. MX records still point at the edge gateway, so inbound mail traverses FortiMail and is delivered to Exchange at 10.30.8.20. FortiMail's management address is 10.30.8.10; the transparent bridge pair is 192.0.2.10 and 192.0.2.11. Exchange outbound mail reaches the internet through FortiMail because the edge gateway routes SMTP to it. A Java application server at 10.40.5.40 sends automated order confirmations to smtp.partner.example, an external relay. Those messages are rejected by FortiMail with '553 Relaying denied,' while ordinary Exchange outbound mail is delivered. The administrator added an access control rule with source 10.40.5.40 and action Relay but placed it below a rule that matches Any source and rejects relay. Nothing in the FortiMail queue shows the application's messages. The business needs the application mail sent without allowing open relay.
1. Why does FortiMail reject the application server's mail while Exchange outbound mail succeeds, and what change would you make?
Read the worked answer
Transparent mode does not create an implicit relay permission. FortiMail evaluates access control rules top-down and stops at the first match. Exchange outbound succeeds because its session matches an earlier rule that permits relay to external destinations; the application's session hits the broad Any-source reject rule before the specific rule is ever evaluated. That is also why no queue entry exists: rejection happens during the SMTP session, before a message is accepted. Move the 10.40.5.40 rule above the broad reject, set the service to SMTP, set the destination to the partner relay's IP if that is known, and use action Relay. Keep authentication off only if the source IP is tightly scoped and monitored; otherwise require SMTP AUTH for the application. Verify by checking the SMTP session log for the new rule match and by confirming the message appears in the mail queue or delivery log.
2. What is the operational risk of simply changing the broad rule to Allow/Relay for Any, and how would you constrain the exception?
Read the worked answer
Changing an Any-source rule to relay turns FortiMail into an open relay. Spammers and compromised internal hosts could then send arbitrary mail through the appliance, damaging its reputation and likely getting the public IP blocked. Instead, constrain the exception by source IP, service, and destination. If the application only sends to smtp.partner.example, limit the rule to the partner's published IP addresses and, where possible, require TLS or SMTP AUTH. Place the specific rule above the general reject and leave the general reject in place for everything else. Log matches to the rule and alert on volume anomalies. If the application cannot authenticate, use a dedicated source IP and a firewall rule that prevents that host from sending anywhere except FortiMail on port 25.
3. If the company later moves MX records to FortiMail and changes to gateway mode, which design elements must be revisited?
Read the worked answer
Changing from transparent to gateway mode changes the traffic path and the policy model. FortiMail becomes the public SMTP endpoint, so the MX records, NAT/firewall rules, and SMTP banner must point to the FortiMail public address instead of the old edge gateway. Protected domains must be defined so inbound recipients are accepted, and the domain mail server must point to Exchange. Outbound relay should be controlled with outgoing policies and a relay host rather than relying on transparent-mode access control behavior. The application's relay rule must be revalidated because session matching and policy direction differ in gateway mode. Plan a maintenance window, lower DNS TTLs in advance, test inbound and outbound mail, and keep the old path available briefly for rollback. Do not simply copy every access control rule without checking rule order and direction.