Troubleshoot MTA issues
SMTP clients receive the message
550 5.7.1 Relay access denied.
This indicates rejection due to lack of relay permission.
- For incoming connections, relay will be allowed automatically unless explicitly rejected through the access control list (see Configuring access control rules).
- For outgoing connections, relay will be allowed only if explicitly granted by authentication (see Controlling email based on IP addresses) or by the access control list (see Configuring access control rules). If authentication is required, verify that the SMTP client is configured to authenticate.
If you receive a 5.7.1 error message that does not mention relay access, and sender reputation or endpoint reputation is enabled, verify that the SMTP client has not exceeded the reputation score threshold for rejection.
The FortiMail unit is bypassed.
FortiMail units can be physically bypassed in a complex network environment if the network is not carefully planned and deployed. Bypassing can occur if SMTP traffic is not correctly routed by intermediary NAT devices such as routers and firewalls.
If your FortiMail unit will be performing antispam scans on outgoing email, all outgoing email must be routed through the FortiMail unit. If your email users and protected servers are configured to relay outgoing mail through another MTA such as that of your ISP, the FortiMail unit will be bypassed for outgoing email.
Spammers can easily determine the lowest priority mail server (highest preference number in the DNS MX record) and deliver spam through that lower-priority MX in an attempt to avoid more effective spam defenses.
To ensure that spammers cannot bypass the FortiMail unit
- Configure routers and firewalls to route SMTP traffic to the FortiMail unit for scanning.
- If the FortiMail unit is operating in gateway mode, modify the DNS server for each protected domain to keep only one single MX record which refers to the FortiMail unit.
- Verify that all possible connections have a matching policy. If no policy matches, the connection will be allowed but will not be scanned (to prevent this, you can add a policy to the bottom of the IP policy list that rejects all connections that have not matched any other policy).
- Verify that you have selected an antispam profile in each policy, and have enabled antispam scans.
Both antispam and antivirus scans are bypassed.
If email is not physically bypassing the FortiMail unit, but is not undergoing both antispam and antivirus scans, verify that access control rules are not too permissive. Also verify that a policy exists to match those connections, and that you have selected antispam and antivirus profiles in the policy. Scans will not be performed if no policy exists to match the connection.
Antispam scans are bypassed, but antivirus scans are not.
If antivirus scans occur, but antispam scans do not, verify that safe lists are not too permissive and that you have not safelisted senders in the protected domains. Safelist entries cause the FortiMail unit to omit antispam scans.
Additionally, verify that either the Bypass scan on SMTP authentication option is disabled, or confirm that authenticated SMTP clients have not been compromised and are not a source of spam.
Recipient verification through SMTP fails.
If you have enabled the Recipient Address Verification option with a protected domain’s SMTP server, but recipient verification fails, possible causes include:
- The SMTP server is not available.
- The network connection is not reliable between the FortiMail unit and the SMTP server.
- The server is a Microsoft Exchange server and SMTP recipient verification is not enabled and configured.
When the SMTP server is unavailable for recipient verification, the FortiMail unit returns the 451 SMTP reply code. The email would remain in the sending queue of the sending MTA for the next retry.
SMTP clients receive the message
451 Try again later.
There are several situations in which the FortiMail unit could return the
451 Try again later SMTP reply code to an SMTP client. Below are some common causes.
- The greylist routine has encountered an unknown sender or the greylist entry has expired for the existing sender and recipient pair. This is an expected behavior, and, for legitimate email, will resolve itself when the SMTP client retries its delivery later during the greylist window.
- Recipient verification is enabled and the FortiMail unit is unable to connect to the recipient verification server. There should be some related entries in the antispam log, such as
Verify <email@example.com> Failed, return TEMPFAIL. If this occurs, verify that the server is correctly configured to support recipient verification, and that connectivity with the recipient verification server has not been interrupted.
The FortiMail unit replies with a temporary failure SMTP reply code, and the event log shows
Milter (fas_milter): timeout before data read.
The timeout is caused by the FortiMail unit not responding within four minutes.
Slow or unresponsive DNS server response for DNSBL and SURBL scans can cause the FortiMail unit’s antispam scans to be unable to complete before the timeout. When this occurs, the FortiMail unit will report a temporary failure. In most cases, the sending MTA will retry delivery later. If this problem is persistent, verify connectivity with your DNSBL and SURBL servers, and consider providing private DNSBL/SURBL servers on your local network.
The event log shows
Milter (mailfilterd): timeout before data read, where=eom.
This may be caused by the following reason:
If an email message contains a shortened URL that redirects to another URL, the FortiMail unit is able to send a request to the shortened URL to get the redirected URL and scan it against the FortiGuard AntiSpam database. By default, this function is enabled. To use it, you need to open your HTTP port to allow the FortiMail unit to send requests for scanning the redirected URL.
This also means, if the upstreaming device (firewall, router, etc.) does not allow HTTP traffic from the FortiMail unit, FortiMail’s HTTP request to FortiGuard servers will get timeout.
To solve this problem
- Allow HTTP/HTTPS outbound traffic from the FortiMail unit on the upstreaming device.
- Run the following CLI commands on FortiMail to disable the feature:
config system fortiguard antispam
set uri-redirect-lookup disable
When recipient verification is enabled on the Microsoft Exchange server, all email is rejected.
By default, Microsoft Exchange servers will not verify the recipient. With an Microsoft Exchange server as the MTA, it is recommended to configure the FortiMail to use LDAP to do recipient verification using the Microsoft Active Directory service. Alternatively, you can configure Microsoft Exchange to enable SMTP recipient verification.
To configure recipient verification on a Microsoft Exchange server
- Open the Microsoft Exchange system manager and go to Global settings > Message Delivery > Properties.
- Enable Recipient Filtering.
- Click Filter recipients who are not in the Directory.
- Go to Administrative Groups > First Administrative Group > Servers > [your server] > SMTP > the default SMTP virtual server > Properties.
- Click Advanced.
- Click Edit.
- Click Apply Recipient Filter.
- Click OK.
To test the configuration, open a Telnet connection to port 25 of your Microsoft Exchange server.