Mail Transfer Agent

In This Section: Using an MTA MTA Engine Updates MTA Monitoring

Using an MTA

You can enable the Security Gateway as an MTA (Mail Transfer Agent) to manage SMTP traffic. The MTA works with these blades: Threat Emulation, Threat Extraction, and Anti-Spam and Mail Security.

When a gateway scans SMTP traffic, sometimes the email client is not able to keep the connection open for the time that is necessary to handle the email. In such cases, there is a timeout for the email. An MTA deployment prevents this problem. The MTA first accepts the email from the previous hop, does the necessary actions on the email and then relays the email to the next hop. The MTA is able to scan SMTP encrypted traffic for the supported blades.

Note - MTA is also supported on VSX gateways. The MTA configuration is the same for VSX and non-VSX gateways.

To use the Security Gateway as an MTA:

1. Enable the Security Gateway as an MTA.
2. Configure the network to forward emails to the MTA.

Enabling MTA on the Security Gateway

When selected, the Security Gateway is an MTA for SMTP traffic. For a topology that uses TLS between the previous hop and the Security Gateway, you must import the mail server certificate to the Security Gateway.

To enable the Security Gateway as an MTA:

1. In SmartConsole, go to Gateways & Servers and double-click the Security Gateway.
2. From the navigation tree, select Mail Transfer Agent.

   The Mail Transfer Agent page opens.

3. Select Enable as a Mail Transfer Agent.
4. In the Mail Forwarding section, add one or more rules. These rules define traffic that is sent to the mail servers after the scanning is complete.
   1. Click the add rule button.
   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 accept all recipient domains.
   4. Click OK.
   5. Click the Next Hop cell and select the node object that is the mail server for this rule.

      Note - From R80.20, you can define a domain object as the Next Hop. This lets you use multiple mail servers based on a DNS name. This DNS configuration allows load balancing and high-availability capabilities based on DNS configuration.

      You can also configure the MTA to only scan the emails and not forward them to the mail server.

5. Optional: Select Add signature to scanned emails and enter the message to add to the end of the email body after it is successfully processed.
6. If the mail server uses TLS inspection, do these steps to enable the MTA to support it:
   1. Click Import.

      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.
   5. Select Enable SMTP/TLS.
7. Configure the MTA Implied Rule.

   By default, when you enable a gateway as an MTA, an implied rule is created at the top of the Access Control Policy, which opens port 25 for connections destined to the gateway. The default source in the implied rule is any source IP. You can configure the source column to allow traffic from specific sources.

   To disable this implied rule, clear Create an implied rule at the top of the Access Control Policy

8. Optional: In the Advanced Settings section, click Configure Settings and configure the MTA interface and email settings.
9. Click OK and then install the Threat Prevention policy.

An MTA rule is created at the top of the Threat Prevention Rule Base.

Configuring MTA Advanced Settings

The MTA Advanced Settings window lets you configure which interfaces on the Security Gateway are listening to SMTP traffic that is sent to Threat Emulation.

Use the Mail Settings section to define these settings:

• Maximum time that emails are kept in the MTA queue.
• The MTA hard drive limit. When this limit is reached, the MTA stops processing emails.
• Use the Troubleshooting section to generate a log or send an alert if emails are delayed in the MTA.

Emails that are in the MTA longer than the Maximum delayed time are blocked or allowed without processing. The Troubleshooting setting lets you receive a log or alert when one of the limits is exceeded.

To configure the MTA advanced settings:

1. Double-click the Security Gateway and from the navigation tree select Mail Transfer Agent.

   The Mail Transfer Agent page opens.

2. In the Advanced Settings section, click Configure Settings.

   The MTA Advanced Settings window opens.

3. To configure the interfaces for SMTP traffic, select one of these options:
   • All interfaces - SMTP traffic from all the interfaces is sent for scanning
   • All external - SMTP traffic from the external interfaces is sent for scanning
   • Use specific - SMTP traffic from the list of specified interfaces is sent for scanning. To add an interface to the list, click the plus sign ( + ). To remove a selected interface from the list, click the minus sign ( - ).
4. To change the maximum number of minutes that the MTA keeps emails, configure Maximum delay time.
5. To change the MTA hard drive limit, configure these settings:
   • % of storage - The percentage limit of MTA hard disk space.
   • MB - Total MB limit of MTA hard disk space.
6. To change the action and tracking settings when the specified Mail Settings are exceeded, configure these settings:
   • Allow - SMTP traffic is allowed
   • Block - SMTP traffic is blocked
   • None - No logs are generated
   • Log - A log is generated in the Logs & Monitor view
   • Alert - Logs the event and sends the configured alert
7. To change the MTA Troubleshooting settings, configure these settings:
   • When mail is delayed for more than - Set the maximum number of minutes that email is delayed in the MTA before the track option is done
   • Track - Select None (no logs are generated), Log (logs generated in the Logs & Monitor view), Alert (logs the event and sends the configured alert).
8. Click OK.
9. Install Policy.

Disabling the MTA

To disable the MTA:

1. Configure the network to disable the MTA.
2. Disable MTA on the Security Gateway.

Configuring the Network to Disable the MTA

The MTA address can be saved in the cache. If the MTA queue is not empty, or you disable the MTA first, it is possible to lose emails that are sent to the network.

To disable MTA for email that is sent to the internal mail server:

1. Connect to the DNS settings for the network.
2. Change the MX records, and define the mail server as the next hop.
3. Wait for 24 hours.
4. Disable the MTA on the Security Gateway.

To disable MTA for email that is sent to a different MTA:

1. Connect to the SMTP settings on the MTA that sends SMTP traffic to the internal mail server.
2. Change the SMTP settings and define the mail server as the next hop.
3. Make sure that the MTA queue is empty.
4. Disable the MTA on the Security Gateway.

Configuring the Network to Use an MTA

After you configure the Security Gateway as an MTA, change the settings to send SMTP traffic from external networks to the Security Gateway. Each organization has an MX record that points to the internal mail server, or a different MTA. The MX record defines the next hop for SMTP traffic that is sent to the organization. These procedures explain how to change the network settings to send SMTP to the Check Point MTA.

Important - If it is necessary to disable the MTA on the Security Gateway, change the SMTP settings or MX records first. Failure to do so can result in lost emails.

To configure an MTA for email that is sent to the internal mail server:

1. Connect to the DNS settings for the network.
2. Change the MX records, and define the Security Gateway as the next hop.

To configure an MTA for email that is sent to a different MTA:

1. Connect to the SMTP settings on the MTA that sends email to the internal mail server.
2. Change the SMTP settings and define the Security Gateway as the next hop.

Deploying MTA in Monitor Only Mode

You can use the Check Point MTA to only monitor SMTP traffic.

Configure the MTA to only scan the emails, but not to forward them to the mail server.

Note - Make sure that the mail relay in the network can send a copy of the emails to the Check Point MTA.

To configure the MTA not to forward emails:

1. In SmartConsole, create a new Host object.
2. Configure these settings:
   • Name - For example, No_Forward
   • IPv4 Address - Enter 0.0.0.0
3. In the Gateways & Servers view, double-click the Security Gateway.
4. From the navigation tree, click Mail Transfer Agent.

   The Mail Transfer Agent page opens.

5. Make sure to delete all the Mail Forwarding rules.
6. Click the Add rule button.
7. Double-click the Next Hop cell.
8. From the drop-down list, select the new Host object you created in Step 1.
9. Click OK.
10. Install the Threat Prevention policy.

MTA Engine Updates

The Mail Transfer Agent Engine Update is an accumulation of new features and bug fixes to the MTA engine. MTA updates are available to users of R80.10 with Jumbo HFA take 142 and up, and users of R80.20 GA.

It is delivered in the form of a CPUSE Hotfix and can be installed and upgraded manually through the CPUSE User Interface and CLISH commands. cpstop/cpstart or reboots are not required.

The updates do not conflict with the regular Jumbo HFAs (for example, R80_10_jumbo_hf) and can be updated independently.

To update the MTA engine:

Open the Gaia Portal > upgrades (CPUSE) > Status and Actions > MTA Engine Updates

For more information on the MTA engine updates, see sk123174.

To check the current version of Mail Transfer Agent Update, run this command:

cat $FWDIR/conf/mta_ver

MTA Monitoring

There are 3 new views for MTA monitoring in SmartView available for R80.10 gateways with Jumbo Hotfix take 142 or R80.20 gateways:

• MTA Live Monitoring
• MTA Overview
• MTA Troubleshooting

To see these views:

1. In SmartConsole, go to the Logs & Monitor view.
2. Click the + sign to open a new tab.
3. At the bottom left corner, click SmartView.

   SmartView opens.

4. Click the + sign to open a new tab.
5. In the navigation tree at the top left corner, select Views.
6. Select the relevant MTA Monitoring view from the list.

The views are based on logs that are updated with each email status change. You can change the time frame of the views in the upper left corner of the MTA Live Monitoring page. You can customize the views, create new widgets and export the views to Excel/PDF.

Here is a description of each one of the new views:

• MTA Live Monitoring - Shows the current status of the email traffic which passed through the MTA in the selected time frame.

  The left side shows the distribution of the emails in queue in a graph and a table. If you right-click the Action column in the table, you can do these actions on the email:

  • Retry - Try to handle the email again
  • Drop - Delete the email
  • Bypass - Do not perform the security inspection and send the email to the next hop

  The right side shows these views for the selected time frame:

  • Statistical information on the number of emails in the queue.
  • The number of emails delivered.
  • Email Status - a diagram which shows a distribution of the email traffic which passed through the MTA, based on these statuses:
    • Bounced - The MTA sent the Emails back to the sender.
    • Deferred - A temporary failure occurred. The MTA will retry to perform the applicable action again.
    • Dropped - The MTA did not transfer the emails to the next hop.
    • Skipped - The MTA bypassed the emails. No performance was performed.

    When you click a column in the diagram, a window opens with a list of the logs that the column is based on.

• MTA Overview - This view shows statistical data on the email traffic which passed through the MTA in 3 timelines:
  • Emails by Status Timeline.
  • Email Content Timeline.
  • Emails in Queue Timeline.

  You can use compare the 3 timelines to identify trends in email traffic and analyze the root cause for all kinds of situations. For example, if the emails in queue timeline shows many emails in the queue at a certain point in time, you can look at the other timelines to check the possible reasons for this. If the content timeline shows many emails with links and attachments at the same point in time, this could explain it, because they take longer to scan.

• MTA Troubleshooting

  This view shows the causes of failure and the number of failures for each cause. For example: too many parallel requests for scanning or exceeded operation timeout.

  The most common failure timeline shows the X top failures. The default is 5.

  The Email Failure timeline shows all failures.