• When should and MTA be used?
  

  • Scenario 1: Encrypted SMTP Traffic

    Some SMTP servers, such as Microsoft Exchange Server, force a connection from an SMTP client to be sent over TLS. The client can be another SMTP server or a mail client. Both are considered an SMTP client when sending an SMTP message.

    Example of the SMTP negotiation over TLS:

    Server: 220 smtp.example.com ESMTP SmtpService
    Client: HELO mail.company.com
    Server: 250 Hello mail.company.com
    Server: 250 STARTTLS
    Client: STARTTLS
    Server: 220
    Client & Server: <Start a TLS session>
    Client over TLS: EHLO mail.company.com
    Server over TLS: 250 Hello mail.company.com
    Client over TLS: MAIL FROM:<bob@company.com>
    Server over TLS: 250 Ok
    Client over TLS: RCPT TO:<alice@example.com>
    Server over TLS: 250 Ok
    

    When the connection is sent over TLS, it is encrypted and the Security Gateway cannot inspect the encrypted traffic, unless MTA is implemented.

    The Mail Transfer Agent allows the Security Gateway to intercept the encrypted connection between the SMTP client and the SMTP server and inspect the connection.

  
  

  • Scenario 2: Timeout for SMTP Traffic inspected by Threat Emulation

    It is possible that during file emulation, the email server cannot keep the connection open for the time needed for full emulation.

    When this happens, there is a timeout for the email. A Threat Emulation deployment with an MTA avoids this problem. The MTA completes and closes the connection with the source SMTP client and then sends the file for emulation. After the emulation is completed, the MTA sends the email to the mail server in the internal network.

• How does an MTA work?
  

  When an SMTP client searches for the mail recipient's server address, the SMTP client sends a DNS query for an MX (Mail eXchanger) record. The query is sent to a DNS server when trying to resolve the domain name that appears after the "@" sign in an email address (for example, the example.com in bob@example.com).

  The MX record on DNS server contains the SMTP server address in a domain name format (for example., smtp.example.com). The record appears as follows:
  example.com MX preference = 10, mail exchanger = smtp.example.com

  When the Mail Transfer Agent (MTA) is enabled on Security Gateway, the MX record is changed to the external IP address of te Security Gateway. This way, when an SMTP message is sent, the MX query is resolved to the IP address of the Security Gateway, and the message is received by the Security Gateway.

  When MTA is enabled, a Postfix service is enabled on the Security Gateway. The Postfix server on the Security Gateway enforces the TLS negotiation instead of the SMTP server and receives the message before the SMTP server. This allows the Security Gateway to inspect the message by the relevant Software Blades.

  After inspecting the message, the MTA either forwards the message to the next-hop SMTP server, drops the message if it is malicious, or extracts the malicious file. This depends on to the configuration of the Software Blades.

• How to configure an MTA?
  

  For more details, refer to sk109699 - ATRG: Mail Transfer Agent (MTA).

  1. Configure on the DNS server an MX record that points to the external IP Address of the Security Gateway.
     
     
  2. In SmartDashboard, open the Security Gateway or Cluster object.
     
     
  3. Enable either the Threat Emulation blade, or Anti-Spam & Email Security.
     
     
  4. Go to Mail Transfer Agent and select Enable as a Mail Transfer Agent (MTA).

  5. In the Mail Forwarding section, add one or more rules:

     1. Click the relevant button on the toolbar
        
        
     2. Right-click the Domain cell and select Edit.
        
        
     3. Enter the domain for the SMTP traffic for this rule.
        The default setting is to use the wildcard (*) to send all traffic.  To prevent spam, we recommend adding the managed domain name instead of keeping the default * .
        
        
     4. Click OK.
        
        
     5. Click the Next Hop cell and select the node object that represents the mail server for this rule.
     
     
     Optional: Check the box
     Sign scanned emails
     and enter the message to add at the bottom of inspected emails.

  6. If the mail server uses TLS inspection, follow these steps to configure the MTA to support it:

     1. Refer to the SMTP/TLS section.
        
        
     2. In Step 1, click Import certificate for SMTP/TLS link.
        1. The Import Outbound Certificate window opens.
           
           
        2. Click Browse and select the certificate file.
           
           
        3. Enter the Private Key password for the certificate.
           
           
        4. Click OK.
     3. In Step 2, check the box Enable SMTP/TLS.
        
        
     
     Optional: In the Advanced Settings section, click Configure Settings and configure the MTA interface and email settings.
     
     
  7. Click OK.
     
     
  8. Install the policy on Security Gateway or Cluster.

• On which Software Blades should MTA be enabled?
  

  Mail Transfer Agent (MTA) is supported by the following blades:

  • Threat Emulation
  • Threat Extraction
  • Anti-Spam & Email Security
  • Anti-Virus (supported in R80.10 an higher)

  Note: Scanning emails passing through MTA is only supported by the blades listed above. There are two ways to scan SMTP traffic:

  • Streaming (through the Firewall kernel. This works for all blades.
  • MTA (through user space and using postfix) - works for Threat Emulation, Threat Extraction, Anti-Spam & Email Security

  Note: Mail Transfer Agent (MTA) is not supported on Security Gateway in VSX mode R77 / R77.10 / R77.20 / R77.30.

 

Related documentation and solutions:

• R80.10 Threat Prevention Administration Guide
• R77 versions Threat Prevention Administration Guide
• sk109699 - ATRG: Mail Transfer Agent (MTA)