Mail Transfer Agent

Using an MTA

You can enable the Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. as an MTA (Mail Transfer AgentClosed Feature on a Security Gateway that intercepts SMTP traffic and forwards it to the applicable inspection component. Acronym: MTA.) to manage SMTP traffic. The MTA works with these blades: Threat EmulationClosed Check Point Software Blade on a Security Gateway that monitors the behavior of files in a sandbox to determine whether or not they are malicious. Acronym: TE., Threat ExtractionClosed Check Point Software Blade on a Security Gateway that removes malicious content from files. Acronym: TEX., and Anti-SpamClosed Check Point Software Blade on a Security Gateway that provides comprehensive protection for email inspection. Synonym: Anti-Spam & Email Security. Acronyms: AS, ASPAM. 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 VSXClosed Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. gateways. The MTA configuration is the same for VSX and non-VSX gateways.

  1. Enable the Enabling MTA on the Security Gateway
  2. Configure the network to Configuring the Network to Use an 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.

Step

Instructions

1

In SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on., 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.

  1. Click add rule.

  2. Right-click the Domain cell and select Edit.

  3. Enter the domain for the SMTP traffic for this ruleClosed Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session.. 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 (see Deploying MTA in Backward Compatibility Mode).

5

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

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

In the Advanced Settings section, click Configure Settings and configure the MTA interface and email settings, (see Configuring the Network to Use an MTA).

9

Click OK, and then install the Threat Prevention policy.

A MTA rule is created at the top of the Threat Prevention Rule BaseClosed All rules configured in a given Security Policy. Synonym: Rulebase..

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.

  • 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.

Step

Instructions

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 Setting.

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

  1. Configuring the Network to Disable the MTA.
  2. Disable the 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.

Step

Instructions

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.

Step

Instructions

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, (see Disabling the MTA).

Step

Instructions

1

Connect to the DNS settings for the network.

2

Change the MX records, and define the Security Gateway as the next hop.

Step

Instructions

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 Backward Compatibility 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.

Step

Instructions

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 and from the navigation tree select Mail Transfer Agent.

The Mail Transfer Agent page opens.

4

Make sure that all the Mail Forwarding rules are deleted.

5

Click the add rule button.

6

Double-click the Next Hop cell.

7

From the drop-down list, select the new host you created in step 1.

8

Click OK, and 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 R80.10 Jumbo Hotfix AccumulatorClosed Collection of hotfixes combined into a single package. Acronyms: JHA, JHF, JHFA. Take 142 and up, and users of R80.20 and higher.

It is delivered in the form of a CPUSEClosed Check Point Upgrade Service Engine for Gaia Operating System. With CPUSE, you can automatically update Check Point products for the Gaia OS, and the Gaia OS itself. package and can be installed and upgraded manually through the CPUSE .The cpstop/cpstart or reboot are not required.

The updates do not conflict with the regular Jumbo HotfixClosed Software package installed on top of the current software version to fix a wrong or undesired behavior, and to add a new behavior. Accumulators and can be updated independently.

Open the Gaia PortalClosed Web interface for the Check Point Gaia operating system. > 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 three views for MTA monitoring in SmartView available for gateways R80.10 with Jumbo Hotfix Accumulator Take 142, and R80.20 and higher.

Step

Instructions

1

In SmartConsole, go to the Security Policies view > Threat Prevention > Profiles > double-click a profile > Mail > General > make sure that Enable MTA Live Monitoring is selected.

2

In SmartConsole, go to the Logs & Monitor view.

3

Click the + sign to open a new tab.

4

At the bottom left corner, click SmartView.

SmartView opens.

5

Click the + sign to open a new tab.

6

In the navigation tree at the top left corner, select Views.

7

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.

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 enforcement 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.

This view shows statistical data on the email traffic which passed through the MTA in three 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.

This view shows the causes of failure and the number of failures for each cause.

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.