Troubleshoot MTA issues

Problem

SMTP clients receive the message 550 5.7.1 Relay access denied.

Solution

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.

Problem

The FortiMail unit is bypassed.

Solution

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

1. Configure routers and firewalls to route SMTP traffic to the FortiMail unit for scanning.
2. 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.
3. 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).
4. Verify that you have selected an antispam profile in each policy, and have enabled antispam scans.

Problem

Both antispam and antivirus scans are bypassed.

Solution

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.

Problem

Antispam scans are bypassed, but antivirus scans are not.

Solution

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.

Problem

Recipient verification through SMTP fails.

Solution

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.

Problem

SMTP clients receive the message 451 Try again later.

Solution

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 <user@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.

Problem

The FortiMail unit replies with a temporary failure SMTP reply code, and the event log shows Milter (fas_milter): timeout before data read.

Solution

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.

Problem

The event log shows Milter (mailfilterd): timeout before data read, where=eom.

Solution

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.

or

• Run the following CLI commands on FortiMail to disable the feature:

config system fortiguard antispam

set uri-redirect-lookup disable

end

Problem

When recipient verification is enabled on the Microsoft Exchange server, all email is rejected.

Solution

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

1. Open the Microsoft Exchange system manager and go to Global settings > Message Delivery > Properties.
2. Enable Recipient Filtering.
3. Click Filter recipients who are not in the Directory.
4. Go to Administrative Groups > First Administrative Group > Servers > [your server] > SMTP > the default SMTP virtual server > Properties.
5. Click Advanced.
6. Click Edit.
7. Click Apply Recipient Filter.
8. Click OK.

To test the configuration, open a Telnet connection to port 25 of your Microsoft Exchange server.