Client-server connections in SMTP
Client-server connections and connection directionality in SMTP differ from how you may be familiar with them in other protocols.
For example, in the SMTP protocol, an SMTP client connects to an SMTP server. This seems consistent with the traditional client-server model of communications. However, due to the notion of relay in SMTP, the SMTP client may be either:
- an email application on a user’s personal computer
- another SMTP server that acts as a delivery agent for the email user, relaying the email to its destination email server
The placement of clients and servers within your network topology may affect the operation mode you choose when installing a FortiMail unit. If your FortiMail unit will be operating in gateway mode or server mode, SMTP clients — including SMTP servers connecting as clients — must be configured to connect to the FortiMail unit.
Terms such as MTA and MUA describe server and client relationships specific to email protocols.
MTA
A Mail Transfer Agent (MTA) is an SMTP server that relays email messages to another SMTP server.
Not all MTAs are full email servers: some MTAs exist solely to relay email, and do not host email user accounts.
FortiMail units operating in gateway mode function as an MTA. FortiMail units operating in server mode function as an MTA and full (SMTP, IMAP, POP3, webmail) email server.
To deliver email, unless the email is incoming and the email server has no domain name and is accessed by IP address only, an MTA must query a DNS server for the MX record and the corresponding A record. For more information, see DNS role in email delivery.
MUA
A Mail User Agent (MUA), or email client, is software such as Microsoft Outlook that enables users to send and receive email.
FortiMail units support SMTP connections for sending of email by a MUA.
FortiMail units operating in server mode support POP3 and IMAP connections for retrieval of email by a MUA. For email users that prefer to use their web browsers to send and retrieve email instead of a traditional MUA, FortiMail units operating in server mode also provide FortiMail webmail.
Connection directionality versus email directionality
Many FortiMail features such as proxies and policies act upon the directionality of an SMTP connection or email message.
Incoming SMTP connections consist of those destined for the SMTP servers that are protected domains of the FortiMail unit. For example, if the FortiMail unit is configured to protect the SMTP server whose IP address is 192.168.0.1, the FortiMail unit treats all SMTP connections destined for 192.168.0.1 as incoming.
Outgoing connections consist of those destined for SMTP servers that the FortiMail unit has not been configured to protect. For example, if the FortiMail unit is not configured to protect the SMTP server whose IP address is 10.0.0.1, all SMTP connections destined for 10.0.0.1 will be treated as outgoing, regardless of their origin.
Incoming versus outgoing SMTP connections
Incoming versus outgoing email
Incoming email messages consist of messages sent to the protected domain recipients (RCPT TO:). For example, if the FortiMail unit is configured to protect the SMTP server whose domain name is example.com, the FortiMail unit treats all email messages sent to example.com as incoming email.
Outgoing email messages consist of messages sent to recipients (RCPT TO:) on domains that the FortiMail unit is not configured to protect. For example, if the FortiMail unit is not configured to protect the domain example.com, all email messages sent to recipients at example.com will be treated as outgoing email, regardless of their origin.
Directionality at the connection level may be different than directionality at the level of email messages contained by the connection. It is possible that an incoming connection could contain an outgoing email message, and vice versa.
For example, in the above figure, connections from the internal mail relays to the internal mail servers are outgoing connections, but they contain incoming email messages. Conversely, connections from remote MUAs to the internal mail relays are incoming connections, but may contain outgoing email messages if the recipients’ email addresses (RCPT TO:) are external.
Because directionality is considered separately at the network layer and the application layer, the directionality of an SMTP connection can be the opposite of the directionality of an email message: the connection may be destined for an SMTP server that is not associated with a protected domain, while the recipient email address is associated with a protected domain, or vice versa.