Testing the installation

After completing the installation, test it by sending email between legitimate SMTP clients and servers at various points within your network topology.

If the FortiMail unit is operating in gateway mode or transparent mode, you may also wish to test access of email users to their per-recipient quarantined email.

If the FortiMail unit is operating in server mode, you may also wish to test access to FortiMail webmail, POP3, and/or IMAP.

Connection test paths (gateway mode)

Connection test paths (transparent mode)

Connection test paths (server mode)

To verify all SMTP connections to and from your FortiMail unit, consider both internal and external recipient email addresses, as well as all possible internal and external SMTP clients and servers that will interact with your FortiMail unit, and send email messages that test the connections both to and from each of those clients and servers. For example:

Using an SMTP client on the local network whose MTA is the FortiMail unit or protected email server, send an email from an internal sender to an internal recipient.
Using an SMTP client on the local network whose MTA is the FortiMail unit or protected email server, send an email from an internal sender to an external recipient.
Send an email from an external sender to an internal recipient.
If you have remote SMTP clients such as mobile users or branch office SMTP servers, using an SMTP client on the remote network whose MTA is the FortiMail unit or protected email server, send an email from an internal sender to an internal recipient.
If you have remote SMTP clients such as mobile users or branch office SMTP servers, using an SMTP client on the remote network whose MTA is the FortiMail unit or protected email server, send an email from an internal sender to an external recipient.

If you cannot connect, receive error messages while establishing the connection, or the recipient does not receive the email message, verify your configuration, especially:

routing and policy configuration of intermediary NAT devices such as firewalls or routers
connectivity of the FortiMail unit with the Fortinet Distribution Network (FDN)
external email servers’ connectivity with and the configuration of the public DNS server that hosts the MX records, A records, and reverse DNS records for your domain names
the FortiMail unit’s connectivity with and the configuration of the local private DNS server (if any) that caches records for external domain names and, if the Use MX record option is enabled, hosts private MX records that refer to your protected email servers
access control rules on your FortiMail unit
configuration of MUAs, including the IP address/domain name of the SMTP and POP3/IMAP server, authentication, and encryption (such as SSL or TLS)

For information on tools that you can use to troubleshoot, see Troubleshooting tools.

Troubleshooting tools

To locate network errors and other issues that may prevent email from passing to or through the FortiMail unit, FortiMail units feature several troubleshooting tools. You may also be able to perform additional tests from your management computer or the computers of SMTP clients and servers.

This section includes:

Ping and traceroute
Nslookup
Telnet connections to the SMTP port number
Log messages
Greylist and sender reputation displays
Mail queues and quarantines
Packet capture

Ping and traceroute

If your FortiMail unit cannot connect to other hosts, you may be able to use ICMP ping and traceroute to determine if the host is reachable or locate the node of your network at which connectivity fails, such as when static routes are incorrectly configured. You can do this from the FortiMail unit using CLI commands.

For example, you might use ICMP ping to determine that 172.16.1.10 is reachable (commands that you would type are highlighted in bold; responses from the FortiMail unit are not bolded):

FortiMail-400 # execute ping 172.16.1.10

PING 172.16.1.10 (172.16.1.10): 56 data bytes

64 bytes from 172.16.1.10: icmp_seq=0 ttl=64 time=2.4 ms

64 bytes from 172.16.1.10: icmp_seq=1 ttl=64 time=1.4 ms

64 bytes from 172.16.1.10: icmp_seq=2 ttl=64 time=1.4 ms

64 bytes from 172.16.1.10: icmp_seq=3 ttl=64 time=0.8 ms

64 bytes from 172.16.1.10: icmp_seq=4 ttl=64 time=1.4 ms

--- 172.20.120.167 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max = 0.8/1.4/2.4 ms

or that 192.168.1.10 is not reachable:

FortiMail-400 # execute ping 192.168.1.10

PING 192.168.1.10 (192.168.1.10): 56 data bytes

Timeout ...

--- 192.168.1.10 ping statistics ---

5 packets transmitted, 0 packets received, 100% packet loss

Both ping and traceroute require that network nodes respond to ICMP ping. If you have disabled responses to ICMP on your network, hosts may appear to be unreachable to ping and traceroute, even if connections using other protocols can succeed.

If the host is not reachable, you can use traceroute to determine the router hop or host at which the connection fails:

FortiMail-400 # execute traceroute 192.168.1.10

traceroute to 192.168.1.10 (192.168.1.10), 32 hops max, 72 byte packets

1 192.168.1.2 2 ms 0 ms 1 ms

2 * * *

Nslookup

It is critical that FortiMail has good access to DNS services to properly handle SMTP sessions and apply antispam scans, including FortiGuard Antispam. If DNS queries fail, they will be recorded in the event log under Monitor > Log > System Event.

If a DNS query fails or resolves incorrectly, you may want to manually query your DNS server to verify that the records are correctly configured. You can do this from the FortiMail unit using CLI commands.

For example, you might query for the mail gateway of the domain example.com (commands that you would type are highlighted in bold; responses from the FortiMail unit are not bolded):

FortiMail-400 # execute nslookup mx example.com

example.com mail exchanger = 10 mail.example.com.

or query to resolve mail.example.com and service.fortiguard.net (the domain name of a FortiGuard Distribution Network server) into IP addresses:

FortiMail-400 # execute nslookup name mail.example.com

Name: mail.example.com

Address: 192.168.1.10

FortiMail-400 # execute nslookup name service.fortiguard.net

Name: service.fortiguard.net

Address: 212.95.252.120

Name: service.fortiguard.net

Address: 72.15.145.66

Name: service.fortiguard.net

Address: 69.90.198.55

For more information on CLI commands, see the FortiMail CLI Reference.

Like verifying DNS connectivity and configuration from the FortiMail unit, you may also be able to verify DNS connectivity and configuration from protected and external mail servers using similar commands. This can be necessary if the devices are configured to use different DNS servers. For details, see the documentation for those mail servers.

Telnet connections to the SMTP port number

Instead of using an SMTP client to verify SMTP connections, you can manually establish SMTP connections by using a Telnet client. Especially if your SMTP client or SMTP server is unable to establish a connection, manually attempting the connection may provide you with SMTP error codes or other insight into why the connection is failing.

Common SMTP error codes

SMTP error code number	Description
500	Syntax error, command unrecognized
501	Syntax error in parameters or arguments
502	Command not implemented (such as for ESMTP and other SMTP protocol extensions that are not enabled/installed on the SMTP server)
503	Bad sequence of commands

If extended SMTP error codes are installed and enabled on the target SMTP server, a manual Telnet connection may enable you to view additional error descriptions. For example, the enhanced error code 4.3.2 Please Try Again Later may notify you that a temporary condition exists preventing delivery, such as greylisting or service unavailability, and that the SMTP client should try delivery again later.

How you should establish the connection depends on the origin and destination of the SMTP connection that you want to test, either:

From the FortiMail unit to an SMTP server
To or through the FortiMail unit

From the FortiMail unit to an SMTP server

If you are not sure if the FortiMail unit can use SMTP to reach an SMTP server, you might use the execute telnettest <fqdn_str>:<port_int> CLI command.

For example, to test SMTP connectivity with mail.example.com on the standard SMTP port number, 25 (commands that you would type are highlighted in bold; responses from the FortiMail unit are not bolded):

FortiMail-400 # execute telnettest mail.example.com:25

Connecting to remote host succeeded.

To or through the FortiMail unit

If you are not sure if a MUA can use SMTP to reach a FortiMail unit that is operating in gateway mode or server mode, or not sure which SMTP commands the FortiMail unit was configured to accept, from the email user’s computer or an external SMTP server, you might open a command prompt and use the command line Telnet client.

For example, to send a test email message (commands that you would type are highlighted in bold; responses from the FortiMail unit are not bolded):

$ telnet fortimail.example.com 25

Trying fortimail.example.com...

Connected to fortimail.example.com.

Escape character is '^]'.

220 fortimail.example.com ESMTP Smtpd; Mon, 6 Oct 2008 14:47:32 -0400

EHLO mail.example.com

250-fortimail.example.com Hello [172.16.1.10], pleased to meet you

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-8BITMIME

250-SIZE 10485760

250-DSN

250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5

250-DELIVERBY

250 HELP

MAIL FROM: <user1@internal.example.com>

250 2.1.0 user1@example.com... Sender ok

RCPT TO: <user2@external.example.net>

250 2.1.5 user2@example.com... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

Subject: TEST

This is a test email message.

250 2.0.0 m96IlWkF001390 Message accepted for delivery

QUIT

221 2.0.0 fortimail.example.com closing connection

Connection closed by foreign host.

where:

fortimail.example.com is the fully qualified domain name (FQDN) of your FortiMail unit
the FortiMail unit is listening for SMTP connections on the default SMTP port number, 25
mail.example.com is the fully qualified domain name (FQDN) of a protected email server from which you are connecting, whose domain name resolves to the IP address 172.16.1.10
user1@internal.example.com is a email address of an sender that is internal to your protected domain, internal.example.com
user2@external.example.net is a email address of an recipient that is external to your protected domain

Log messages

Log messages often contain clues that can aid you in determining the cause of a problem. FortiMail units can record log messages when errors occur that cause failures, upon significant changes, and upon processing events.

Depending on the type, log messages may appear in either the history, event, antivirus, or antispam logs. For example:

To determine when and why an email was quarantined, you might examine the Classifier and Disposition fields in the history log.
To determine if an antiSpam scan query was able to reach the FDN, you might examine the Message field in the antispam log.

During troubleshooting, you may find it useful to reduce the logging severity threshold for more verbose logs, to include more information on less severe events.

For example, when the FortiMail unit cannot reach the FDN or override server for FortiGuard Antispam queries, the associated log message in the antispam log has a severity level of Notification. If your severity threshold is currently greater than Notification (such as Warning or Error), the FortiMail unit will not record that log message, and you will not be notified of the error. Often this error might occur due to temporary connectivity problems, and is not critical. However, if you are frequently encountering this issue, you may want to lower the severity threshold to determine how often the issue is occurring and whether the cause of the problem is persistent.

Similar to how the FortiMail unit will not record log messages below the severity threshold, if the FortiMail unit is not enabled to record event, history, antivirus, and antispam log messages, you will not be able to analyze the log messages for events of that type. During troubleshooting, be sure that log messages are enabled for the type of event that you want to analyze.

To configure the severity threshold, go to Log & Report > Log Setting and set the logging level on one or both of the tabs. To enable logging of different types of events, select applicable options under Logging Policy Configuration on either or both tabs.

If this menu path is not available, first select Advanced to switch to the advanced mode of the web UI.

Greylist and sender reputation displays

If an SMTP client is unable to send email despite being able to initiate SMTP connections to or through the FortiMail unit, and is receiving SMTP error codes that indicate temporary failure or permanent rejection, verify that the SMTP client has not been temporarily blocked by the greylist or sender reputation features.

To view the lists of SMTP clients and their statuses with those features, go to Monitor > Greylist > Display and Monitor > Reputation > Sender Reputation respectively.

These menu items are only available in the advanced mode of the web UI.

Mail queues and quarantines

If email has not successfully passed to or through the FortiMail unit, but you have been able to successfully initiate the SMTP connection and send the email and have not received any SMTP error codes, verify that delivery has not been delayed and that the email message has not been quarantined.

To view the mail queues, go to Monitor > Mail Queue, then select a mail queue tab. To view the per-recipient or system quarantine, go to Monitor > Quarantine, then select either the Personal Quarantine or System Quarantine tab.

These menu items are only available in the advanced mode of the web UI.

Packet capture

Packet capture, also known as sniffing, records some or all of the packets seen by a network interface. By recording packets, you can trace connection states to the exact point at which they fail, which may help you to diagnose some types of problems that are otherwise difficult to detect.

FortiMail units have a built-in sniffer. To use the built-in sniffer, go to System > Utility > Traffic Capture, or connect to the CLI and enter the following command:

diagnose sniffer packet <interface_str> '<filter_str>' <verbosity_level_int> <packet_count_int>

where:

<interface_str> is the name of a network interface, such as port1,or enter any for all interfaces.
'<filter_str>' is the sniffer filter that specifies which protocols and port numbers that you do or do not want to capture, such as 'tcp port 25',or enter none for no filters.
<verbosity_level_int> is an integer indicating the depth of packet headers and payloads to display.
<packet_count_int> is the number of packets the sniffer reads before stopping. Packet capture output is printed to your CLI display until you stop it by pressing Ctrl + C, or until it reaches the number of packets that you have specified to capture.

Packet capture can be very resource intensive. To minimize the performance impact on your FortiMail unit, use packet capture only during periods of minimal traffic, with a serial console CLI connection rather than a Telnet or SSH CLI connection, and be sure to stop the command when you are finished.

For example, you might selectively capture packets for FortiGuard Antispam queries occurring through port1 (commands that you would type are highlighted in bold; responses from the FortiMail unit are not bolded):

FortiMail-400 # diag sniffer packet port1 'udp port 8889' 3

2.685841 172.16.1.10.47319 -> 212.95.252.120.8889: udp 64

0x0000 0009 0f84 27fe 0009 0f15 02e8 0800 4500 ....'.........E.

0x0010 005c 0000 4000 4011 44ff ac14 78a5 d45f .\..@.@.D...x.._

0x0020 fc78 b8d7 22b9 0048 9232 6968 726a b3c5 .x.."..H.2ihrj..

0x0030 776c 2d2f 5a5f 545e 4555 5b5f 425b 545f wl-/Z_T^EU[_B[T_

0x0040 4559 6b6a 776b 646e 776c 6b6a 772b 646e EYkjwkdnwlkjw+dn

0x0050 776c 6b6a 776b 646e 776c 6b6a 776b 86a9 wlkjwkdnwlkjwk..

0x0060 db73 21e1 5622 c618 7d6c .s!.V"..}l

Instead of reading packet capture output directly in your CLI display, you usually should save the output to a plain text file using your CLI client. Saving the output provides several advantages. Packets can arrive more rapidly than you may be able to read them in the buffer of your CLI display, and many protocols transfer data using encodings other than US-ASCII. It is usually preferable to analyze the output by loading it into in a network protocol analyzer application such as Wireshark.

For example, you could use PuTTY or Microsoft HyperTerminal to save the sniffer output. Methods may vary. See the documentation for your CLI client.

Requirements

terminal emulation software such as PuTTY
a plain text editor such as Notepad
a Perl interpreter
network protocol analyzer software such as Wireshark

To view packet capture output using PuTTY and Wireshark

On your management computer, start PuTTY.
Use PuTTY to connect to the FortiMail appliance using either a local serial console, SSH, or Telnet connection. For details, see the FortiMail CLI Reference.
Type the packet capture command, such as:

diagnose sniffer packet port1 'tcp port 25' 3

but do not press Enter yet.

In the upper left corner of the window, click the PuTTY icon to open its drop-down menu, then select Change Settings.

A dialog appears where you can configure PuTTY to save output to a plain text file.

In the Category tree on the left, go to Session > Logging.
In Session logging, select Printable output.
In Log file name, click the Browse button, then choose a directory path and file name such as C:\Users\MyAccount\packet_capture.txt to save the packet capture to a plain text file (you do not need to save it with the .log file extension).
Click Apply.
Press Enter to send the CLI command to the FortiMail unit, beginning packet capture.
If you have not specified a number of packets to capture, when you have captured all packets that you want to analyze, press Ctrl + C to stop the capture.
Close the PuTTY window.
Open the packet capture file using a plain text editor such as Notepad.

Delete the first and last lines, which look like this:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2011.07.25 11:34:40 =~=~=~=~=~=~=~=~=~=~=~=

FortiMail-2000 #

These lines are a PuTTY timestamp and a command prompt, which are not part of the packet capture. If you do not delete them, they could interfere with the script in the next step.

Convert the plain text file to a format recognizable by your network protocol analyzer application.

You can convert the plain text file to a format (.pcap) recognizable by Wireshark (formerly called Ethereal) using the fgt2eth.pl Perl script.

The fgt2eth.pl script is provided as-is, without any implied warranty or technical support, and requires that you first install a Perl module compatible with your operating system.

To use fgt2eth.pl, open a command prompt, then enter a command such as the following:

Methods to open a command prompt vary by operating system.

On Windows 10, click Start (Windows logo) then enter cmd.

fgt2eth.pl -in packet_capture.txt -out packet_capture.pcap

where:

fgt2eth.pl is the name of the conversion script; include the path relative to the current directory, which is indicated by the command prompt
packet_capture.txt is the name of the packet capture’s output file; include the directory path relative to your current directory
packet_capture.pcap is the name of the conversion script’s output file; include the directory path relative to your current directory where you want the converted output to be saved

Converting sniffer output to .pcap format

Open the converted file in your network protocol analyzer application. For further instructions, see the documentation for that application.

Viewing sniffer output in Wireshark