Free Demo Contact Us Support Center Blo

PRODUCTS SOLUTION SUPPORT & SERVICES PARTNERS RESOURCES

Support Center > Search Results > SecureKnowledge Details

Search Support Center

ATRG: Mail Transfer Agent (MTA) Technical Level

Rate This My Favorites Email Pri

Solution ID sk109699

Technical Level

Product Harmony Email & Collaboration, Anti-Spam, Threat Emulation, Threat Extraction
Version R77.10 (EOL), R77.20, R77.30 (EOL), R80.10 (EOL), R80.20, R80.30, R80.40, R81
OS Crossbeam XOS, Gaia, SecurePlatform 2.6
Platform / Model All
Date Created 21-Feb-2016

Solution
Table of Contents:

1. Introduction
2. Configuration
3. Limitations
4. Postfix
5. E-mail flow in MTA
6. Control intervals and thresholds for MTA logs
7. CPview integration (Monitoring Threat-Emulation MTA related statistics)
8. Troubleshooting
9. Related documentation
10. Related solutions
11. Revision history

(1) Introduction

Mail Transfer Agent (MTA) can be enabled on the Security Gateway to manage the emulation of SMTP traffic.

It is possible that during file emulation, the e-mail server cannot keep the connection open for the time that is necessary for full emulation. When this happens, there
timeout for the e-mail. A Threat Emulation deployment with an MTA avoids this problem - the MTA completes and closes the connection with the source e-mail server
then sends the file for emulation. After the emulation is complete, the MTA sends the e-mail to the mail server on the internal network.

MTA deployment has various advantages:

Decryption of TLS traffic - Threat Emulation must use an MTA to decrypt e-mails for emulation.
Prevention of e-mail traffic - It is recommended to use Threat Emulation profile settings that prevent SMTP traffic. It is possible that during file emulation, the e
server cannot keep the connection open for the time that is necessary for full emulation. When this happens, there is a timeout for the e-mail, and 'Fail Mode' w
be used.
Removal of malicious attachments - When Threat Emulation identifies that an e-mail attachment is malicious, the MTA removes the attachment and sends the
mail.

(2) Configuration

This section describes how to configure MTA for Threat Emulation.

1. Configure the Security Gateway as an MTA:

A. Connect with SmartDashboard to Security Management Server / Domain Management Server.

B. Double-click on the Security Gateway object.

C. Click on the Mail Transfer Agent pane - check the box Enable as a Mail Transfer Agent (MTA).

Example:


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

i. Click on the add rule button.

ii. Right-click the Domain cell - select Edit...

iii. Enter the domain for the SMTP traffic for this rule (accepting all traffic by default). Add a rule with a wildcard ("*") as the domain to configure the N
Hop for all emails destined for non-configured domains. A common usage for a wildcard rule is to control bounced emails sent back to the origina
sender. 

iv. Click on OK.

v. Left-click in the Next Hop cell - select the node object that represents the mail server for this rule.

Example:

E. Optional: Check the box Sign scanned e-mails and enter the message to add to each e-mail when emulation is finished.

F. In the SMTP/TLS section, configure the MTA to support TLS inspection:

 i. In Step 1, click on Import certificate for SMTP/TLS link. (Important Note: The imported certificate should be a trusted certificate.)

ii. Click on Browse - select the certificate file.

iii. Enter the Private Key password for the certificate.

iv. Click on OK.

v. In Step 2, check the box Enable SMTP/TLS. 

G. Click on OK to close Security Gateway properties.

H. Install the policy.

2. Configure the network to forward e-mails to the MTA:

After configuring the Security Gateway as an MTA, there are 3 options to configure it in the existing topology.

Choose the correct option according to the topology of the organization and the security needs.

Check Point MTA as the organization MX record

Each organization has an MX record that points to the internal mail server, or to a different MTA.

The MX record defines the next hop for SMTP traffic that is sent to the organization.

In this configuration, the MTA receives all e-mails directed to the organization and sends them to the internal mail server.

After configuring the Security Gateway as an MTA, change the settings to send SMTP traffic from external networks to the Security Gateway.

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

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

A. Edit the DNS settings for the network.

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

Traffic flow and logical topology:

Cloud Emulation Private Cloud Emulation

Check Point MTA as an internal MTA

The MTA receives e-mails from a preliminary MTA and sends them to the next hop, usually the internal mail server.

If there is an existing MTA used as the preliminary MTA (e.g., as an Anti-Spam solution), then this configuration will suit the best.

To configure an MTA for e-mail that is sent to a different MTA:

A. Edit the SMTP settings on the MTA that sends e-mails to the internal mail server.

B. Change the SMTP settings and define the Security Gateway as the next hop.

Traffic flow and logical topology:

Check Point MTA in BCC Mode

The MTA can be used for monitoring the SMTP traffic. Configure the MTA to send e-mails only for emulation, 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 e-mails to the Check Point MTA.

To configure the MTA not to forward e-mails:

A. Double-click on the Security Gateway object.

B. Click on the Mail Transfer Agent pane.

C. Delete all Mail Forwarding rules (right-click on each rule - go to Rule Actions menu - click on Delete Rule - confirm)

D. Create a new rule:

 Domain cell - leave the default asterisk (*)

Next Hop cell - left-click in the cell - click on New... button - assign a desired name (e.g., No_Forward) - assign IPv4 address 0.0.0.0 -
click on OK

E. Click on OK.

F. Install the policy.

(3) Limitations

Threat Prevention rule base

The Threat Prevention rule that is matched for the MTA will be the first rule with “Any” source, that matched the IP address of the MTA in its Protected Scope /
Destination column (“Any” will also match).

Notes:

The match is static, and the MTA will use the same rule for all e-mails.
The matched rule must include Threat Emulation/Threat Extraction inspection. Otherwise, the attachments will not be scanned.
The MTA rule must be rule 1 in the Threat Prevention ruleset. 

Single certificate

There is no option to use multiple certificates for different mail servers.

Anti-Virus over MTA

Anti-Virus is supported on MTA in R80.10 and R80.20 with the latest engine update. Refer to sk123174 to see if your Take supports Anti-Virus. 

Dynamically resolved next hop for the MTA

By default, in versions R80 and lower, there is no option to dynamically resolve the next hop for redundancy/load sharing.

The next hop should be a host with a static IP address.

Refer to sk110369 - How to configure load balancing / high availability based on the DNS configuration for Mail Transfer Agent (MTA) .

Anti-Spam over MTA

MTA can function as an Anti-Spam starting in R77.10 - Check Point Security Gateway takes the role of the Exchange Server, and, therefore, is able to decrypt the
encrypted e-mails.

For performance reasons, it is recommended to use different Security Gateways - one as MTA for Anti-Spam and another as MTA for Threat Emulation and Extr
MTA is used by Threat Emulation and Threat Extraction blades for TLS decryption, better threat prevention, etc.

Related solution: sk105482 - Some spam e-mails pass through the Security Gateway even when the Anti-Spam blade is enabled.

MTA over cluster deployment

Do not select Cluster Virtual Interface(s) in MTA "Advanced Settings" (when clicking on "Configure Settings..." button - in "Select on which interfaces to listen"
section, selecting "Use specific").

Refer to sk107093 - E-mails do not reach the client after selecting Cluster Virtual Interface(s) in MTA "Advanced Settings".

(4) Postfix

Postfix is an open source mail server that is used by Check Point software to route and deliver e-mails in the MTA implementation.

Postfix is configured using two main configuration files:

Note: Both files are generated on Security Gateway during policy installation by the process in.emaild.mta.

/opt/postfix/etc/postfix/master.cf

This file configures the communication between Postfix processes and Check Point processes, ports, protocols, and so on.

This file should not be changed.

/opt/postfix/etc/postfix/main.cf

Administrator must be fully aware of implications resulting from manual configuration of Postfix (refer to http://www.postfix.org/postconf.5.html).

Related solution: sk101870 - How to change Postfix configuration for Threat Emulation MTA
 Important note regarding main.cf: main.cf is not editable, as it will be overwritten on policy install. Use this procedure:
From the Security Gateway CLI, create the file: touch $FWDIR/conf/mta_postfix_options.cf
Edit the file and add the definitions.
Save the file.
Install the Threat Prevention policy.

(5) E-mail flow in MTA

A. An e-mail is sent to the MTA on Security Gateway to TCP port 25. (Port 25 is no longer the the only supported port, see sk142932).

B. Postfix on Security Gateway receives all e-mails (clear and encrypted) and responds to the sender.

C. Postfix on Security Gateway decrypts the e-mail (if needed) and saves on the incoming queue (marked as PF1 on the diagram below).

D. The in.emaild.mta process is configured to be Postfix content filter.

Each e-mail is sent by Postfix to in.emaild.mta process to TCP port 10025.

The e-mail is parsed by the MIME parser and the attachments (if any) are sent to Threat Emulation Daemon ted for emulations.

Note: All e-mails are handled by Postfix - regardless whether they contain attachments, or not.

E-mail flow through the MTA components:

(6) Control intervals and thresholds for MTA logs

Administrator can configure the desired intervals and thresholds for logs from the Mail Transfer Agent (MTA) when processing e-mails. This will allow to generate log
the following cases:

too many e-mails are waiting to be processed

e-mails are being delayed
e-mails are deferred
e-mails are bounced

Note: This feature (ID 02009776) is available only in the following Security Gateways:

R77.30 with Take_221 and higher of R77.30 Jumbo Hotfix Accumulator

R80.10 and higer

The configuration is performed on the Security Gateway configured as Mail Transfer Agent (MTA) in the $FWDIR/conf/mail_security_config file by setting the desired v
for the corresponding parameters (described below).

Important Notes:

Before any change - Backup the current file

After any change in the file - it is mandatory to restart Check Point services with the "cpstop ; cpstart" commands.

Note: In cluster, this will cause a fail-over.

In cluster environment, the procedure must be performed on all members of the cluster.

The following tables provide the description of the most relevant configuration parameters.

Configuring log intervals:

Note: These parameters are located in the $FWDIR/conf/mail_security_config file in the "[mta_log_alerts]" section - under the comment "#Log alerts interva

Default
Parameter Description
value

queues_check_interval Controls how often to check the incoming e-mails in Postfix queues. These checks might result in 8

the new System Alert logs from Mail Transfer Agent (MTA) being displayed in SmartView Tracker / minutes
SmartLog.

alerts_mode_queues_check_interval Controls how long to wait from the time of sending one of the MTA System Alert logs until the next 14

check of the incoming e-mails in Postfix queues. minutes

Configuring log thresholds:

Note: These parameters are located in the $FWDIR/conf/mail_security_config file in the "[mta_log_alerts]" section - under the comment "#Log alerts thresho
 Parameter Description Default Notes
value

num_of_waiting_mails_low_svr_th 250

Controls the minimal number of e-mails System Alert log will be generated with
e-mails
that are waiting to be processed - if at least Severity "Low" as long as the number of e-
this number of e-mails are waiting, then a mails that are waiting to be processed is
corresponding System Alert log is between this value and the value of next
generated with Severity "Low". threshold parameter
"num_of_waiting_mails_med_svr_th".
Example of a System Alert log with Severity
"Low" when e-mails are waiting to be If the number of e-mails that are waiting to be
processed: processed decreases below the value of this
parameter, then a Control log is generated
From R8x SmartLog after setting the
("relax" message).
value of 4:
Example of a log when there are no more e-
mails waiting to be processed:

From R8x SmartLog:

From R77.x SmartView Tracker after
setting the value of 5:

From R77.x SmartView Tracker:

num_of_waiting_mails_med_svr_th Controls the minimal number of e-mails 500

System Alert log will be generated with Severity
that are waiting to be processed - if at least e-mails "Medium" as long as the number of e-mails that are
this number of e-mails are waiting, then a waiting to be processed is between the value of this
corresponding System Alert log is parameter and the value of next threshold parameter
generated with Severity "Medium". "num_of_waiting_mails_hgh_svr_th".

num_of_waiting_mails_hgh_svr_th Controls the minimal number of e-mails 1000

System Alert log will be generated with Severity
that are waiting to be processed - if at least e-mails "High" as long as the number of e-mails that are
this number of e-mails are waiting, then a waiting to be processed is between this value and any
corresponding System Alert log is larger number.
generated with Severity "High".

delay_time_low_svr_th 10

Controls how long to wait from the time of System Alert log will be generated with
minutes
receiving at least one e-mail before Severity "Low" as long as the waiting time is
generating a System Alert log with Severity between this value and the value of next
"Low" about a delay in the mails queue (e- threshold parameter
mails are waiting to be processed). "delay_time_med_svr_th".

Example of a System Alert log with Severity If the waiting time decreases below the value of
"Low" when there is a delay in mails queue: this parameter, then a Control log is generated
("relax" message).
From R8x SmartLog after setting the
value of 5: Example of a log when there is no more delay
in mails queue:

From R8x SmartLog:

From R77.x SmartView Tracker after

setting the value of 6:

From R77.x SmartView Tracker:

delay_time_med_svr_th Controls how long to wait from the time of 15

System Alert log will be generated with Severity
receiving at least one e-mail before minutes "Medium" as long as the waiting time is between this
generating a System Alert log with Severity value and the value of next threshold parameter
"Medium" about a delay in the mails queue "delay_time_hgh_svr_th".
(e-mails are waiting to be processed).

delay_time_hgh_svr_th Controls how long to wait from the time of 20

System Alert log will be generated with Severity
receiving at least one e-mail before minutes "High" as long as the waiting time is between this
generating a System Alert log with Severity value and any larger number.
"High" about a delay in the mails queue (e-
mails are waiting to be processed).

num_of_deferred_mails_low_svr_th 1

 Controls how many e-mails should be e-mail System Alert log will be generated with
determined by Postfix as Deferred before Severity "Low" as the number of deferred e-
generating a System Alert log with Severity mails is between this value and the value of
"Low" about deferred mails. next threshold parameter
"num_of_deferred_mails_med_svr_th".
Example of a System Alert log with Severity
"Low" when there are deferred mails: If the number of deferred e-mails decreases
below the value of this parameter, then a
From R8x SmartLog:
Control log is generated ("relax" message).

Example of a log when there are no more

deferred mails:
From R77.x SmartView Tracker:
From R8x SmartLog:

From R77.x SmartView Tracker:

num_of_deferred_mails_med_svr_th Controls how many e-mails should be 10

System Alert log will be generated with Severity
determined by Postfix as Deferred before e-mails "Medium" as long as the number of deferred e-mails
generating a System Alert log with Severity is between this value and the value of next threshold
"Medium" about deferred mails. parameter "num_of_deferred_mails_hgh_svr_th".

num_of_deferred_mails_hgh_svr_th Controls how many e-mails should be 50

System Alert log will be generated with Severity
determined by Postfix as Deferred before e-mails "High" as long as the number of deferred e-mails is
generating a System Alert log with Severity between this value and any larger number.
"High" about deferred mails.

num_of_bounced_mails_low_svr_th 1

Controls how many e-mails should be System Alert log will be generated with
e-mail
determined by Postfix as Bounced before Severity "Low" as the number of bounced e-
generating a System Alert log with Severity mails is between this value and the value of
"Low" about bounced mails. next threshold parameter
"num_of_bounced_mails_med_svr_th".
Example of a System Alert log with Severity
"Low" when there are bounced mails: If the number of bounced e-mails decreases
below the value of this parameter, then a
From R8x SmartLog:
Control log is generated ("relax" message).

Example of a log when there are no more

bounced mails:
From R77.x SmartView Tracker:
From R8x SmartLog:

From R77.x SmartView Tracker:

num_of_bounced_mails_med_svr_th Controls how many e-mails should be 10

System Alert log will be generated with Severity
determined by Postfix as Bounced before e-mails "Medium" as long as the number of bounced e-mails
generating a System Alert log with Severity is between this value and the value of next threshold
"Medium" about deferred mails. parameter "num_of_bounced_mails_hgh_svr_th".

num_of_bounced_mails_hgh_svr_th Controls how many e-mails should be 50

System Alert log will be generated with Severity
determined by Postfix as Bounced before e-mails "High" as long as the number of bounced e-mails is
generating a System Alert log with Severity between this value and any larger number.
"High" about deferred mails.

(7) Mail Transfer Agent (MTA) - CPview integration (Monitoring Threat-Emulation MTA related statistics)

This feature reflects MTA internal statistics via the CPview utility.  

Under CPVIEW.Software-blades.Threat-Emulation, a new MTA tab has been added. This tab contains 2 sections:

1. Queues Section:
 

Active Queue - Number of emails currently waiting in MTA queue.

Deferred Queue - Number of emails temporarily failed. Those emails need to be retried to be processed.
Emaild Queue - Number of emails currently being processed by MTA.

2. Monitoring Section

Mails Received - Number of emails received by MTA

Mails With TE Supported Attachments - Number of emails that contain at least one Threat-Emulation supported attachment
Mails Processed - Number of emails that have completed MTA processing
Mails Limits Exceeded - Number of emails that failed due to timeout or exceeded disk quota
Mails Modified - Number of emails that contain attachments that were stripped by Threat-Emulation
Mails Deferred - Number of emails temporarily failed
Mails Blocked - Number of emails prevented
Mails Skipped Due To Excluded Recipients - Number of emails excluded from scanning as all their recipients are in the excluded list
Mails Skipped Due To Excluded Sender - Number of emails excluded from scanning as their sender is in the excluded list
Mails With TE Failures - Number of emails that encountered TE failure during their processing
Mails With MTA Failures - Number of emails that encountered MTA failure during their processing

Note: All the counters listed display the amount of emails in the last x seconds, where x is the CPView refresh interval (two seconds by default). To change the CPView
refresh interval, under CPview, press the "r" key and enter the desired interval in seconds.

(8) Troubleshooting

Postfix log file:

/var/log/maillog
How to monitor and manage Postfix queue:

Refer to relevant manual pages listed in the "Related documentation" section.

Action Command

Show current queue [Expert@HostName:0]# /opt/postfix/usr/sbin/postqueue -c /opt/postfix/etc/postfix/ -p

Show one mail from queue:

(5632E28B0044 is an example
[Expert@HostName:0]# /opt/postfix/usr/sbin/postcat -c /opt/postfix/etc/postfix/ -q 5632E28B0044 | less
Queue ID from the current queue)

Attempt immediate delivery of queue content [Expert@HostName:0]# /opt/postfix/usr/sbin/postqueue -c /opt/postfix/etc/postfix/ -f

Delete one message from queue:

(5632E28B0044 is an example
[Expert@HostName:0]# /opt/postfix/usr/sbin/postsuper -c /opt/postfix/etc/postfix/ -d 5632E28B0044
Queue ID from the current queue)

Delete all messages in queue [Expert@HostName:0]# /opt/postfix/usr/sbin/postsuper -c /opt/postfix/etc/postfix/ -d ALL

Show postfix configuration [Expert@HostName:0]# /opt/postfix/usr/sbin/postconf -c /opt/postfix/etc/postfix/

Get postfix version [Expert@HostName:0]# /opt/postfix/usr/sbin/postconf -c /opt/postfix/etc/postfix/ | grep mail_version

Restart postfix [Expert@HostName:0]# /opt/postfix/usr/sbin/postfix -c /opt/postfix/etc/postfix reload

E-mail is stuck in Postfix queue:

Example of an e-mail being stuck in postfix queue:

[Expert@HostName:0]# /opt/postfix/usr/sbin/postqueue -c /opt/postfix/etc/postfix/ -p

-Queue ID- --Size-- ----Arrival Time---- Sender/Recepient-------

28EC212002E 4528659 Mon Dec 28 16:37:29 sender.example@domain.example.com

(connect to 127.0.0.1[127.0.0.1]: Connection refused)

recepient.example@domain.example.com

Possible reasons for an e-mail being stuck in the queue:

Reason Status in postfix queue

The e-mail was received by in.emaild.mta process,

but there was an error during the inspection of the e-mail.

451 Temporary failure, please try again later
As a result, the e-mail was categorized as deferred by postfix.

(delivery temporarily suspended: lost connection with 127.0.0.1[127.0.0

The e-mail was not delivered to the content-filter (in.emaild.mta).
while sending end of data -- message may be sent more than once)

This is usually a result of high load. (mail transport unavailable)

(connect to 127.0.0.1[127.0.0.1]: Connection refused)

Latency in e-mail deliveries:

Suggested action plan:

A. Locate the e-mail in postfix queue (according to recipient):

[Expert@HostName:0]# /opt/postfix/usr/sbin/postqueue -c /opt/postfix/etc/postfix/ -p

B. Monitor the postfix queue and try to find a reason for the delay from the postfix queue

[Expert@HostName:0]# /opt/postfix/usr/sbin/postcat -c /opt/postfix/etc/postfix/ -q <Relevant_Queue_ID>

C. Locate the e-mail in in.emaild.mta process:

i. Start the relevant debugs:

[Expert@HostName:0]# fw debug in.emaild.mta on TDERROR_ALL_MAIL_SECURITY=5

[Expert@HostName:0]# tecli debug set TE all TE_IS all TE_CLOUD all

ii. Resend the problematic e-mail:

[Expert@HostName:0]# /opt/postfix/usr/sbin/postqueue -c /opt/postfix/etc/postfix/ -i <Relevant_Queue_ID>

iii. Stop the debugs:

[Expert@HostName:0]# fw debug in.emaild.mta off

[Expert@HostName:0]# tecli debug defaults

iv. Analyze the debug output:

[Expert@HostName:0]# grep -n 'TEScanParal::AddRequest: email is to' $FWDIR/log/emaild.mta.elg*

Between all of the requests, locate the recipient name.

If there is no request sent with the recipient name, then the e-mail did not contain attachments.

This means that the delay is caused only because of the communication between postfix and in.emaild.mta process.

 Stop following this e-mail.

Check the CPU load on the Security Gateway (refer to "CPU" sections in sk98348).

Collect throughput and number of users behind the MTA.

Check the size of postfix queue.

Collect the contents of the current postfix queue for later investigation.

If there is a request sent with the recipient name, then go to the line number that matches the request that was sent to that recipient.

At the line below you should see the following message:

TEScanParal::AddRequest: Added request for <Name_of_Attachment>, request ID is <Request_ID>

If this message does not appear, then the communication with Threat Emulation Daemon ted was not initialized.

Check that ted process is up ("ps auxw | grep -w ted") and is responding ("tecli show").

If ted process is down, then:

check if it crashed with core dump files ("ls -l /var/log/dump/usermode/ | grep ted")
collect $FWDIR/log/ted.elg* files
collect $FWDIR/log/fwd.elg* files
CPinfo file from the Security Gateway
CPinfo file from the Security Management Server

If ted process is up and responding, then:

use the Appliance Sizing Tool to check that this appliance matches the current throughput and number of users:

go to UserCenter - go to "QUOTING TOOLS" menu at the top - click on "Appliance Sizing Tool"

(in addition, refer to sk93598 - Threat Emulation Sizing Mode: how to measure the required inspections at an organization)
collect Threat Emulation statistics ("tecli show statistics")
collect Threat Emulation throughput ("tecli show throughput")

Check of ted process has responded with the verdict to the request - search for this line:

TEScanParal::ReplyToReq: Reply for request <Request_ID> is <verdict>

Run:

[Expert@HostName:0]# grep -n 'TEScanParal::ReplyToReq: Reply for request' $FWDIR/log/emaild.mta.elg*

If this message does not appear, then look for the attachment in Threat Emulation (proceed to the next step).

D. Locate the attachment in Threat Emulation

From the $FWDIR/log/in.emaild.mta.elg* log files you have the name of the attachment file.

Search for this attachment in the ted process debugs (collected in the previous step):

[Expert@HostName:0]# grep 'Handling new file "<Name_of_Attachment>"' $FWDIR/log/ted.elg*

At the beginning of the line, there is a UUID of the attachment in the format {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.

Follow the UUID through the ted.elg files.

If there is no apparent error, then collect the following information:

UUID number of the involved attachment

$FWDIR/log/ted.elg*
Output of "tecli show downloads all" command
Output of "tecli advanced schema all" command
Output of "tecli advanced engine version" command
CPinfo file from the Security Gateway
CPinfo file from the Security Management Server

Analyze Postfix bottlenecks using the cpqshape utility:

Background:

Postfix built-it queue monitoring abilities are lacking, which makes it very hard to analyze Postfix bottlenecks.

Check Point provides the improved Postfix "qshape" utility - /opt/postfix/usr/sbin/cpqshape.

The "cpqshape" utility helps understand the Postfix queue message distribution in time and by sender / recipient domain.

Note: The "cpqshape" utility (ID 02002951) is available only in the following Security Gateways:

R77.30 with Take_221 and higher of R77.30 Jumbo Hotfix Accumulator

R80.10 and higher

Syntax:

cpqshape [-s] [-p] [-m min_subdomains]

[-b bucket_count] [-t bucket_time]

[-l] [-w terminal_width]

[-N batch_msg_count] [-n batch_top_domains]

[-c config_directory] [queue_name ...]

Documentation:
 For more information about this utility, refer to:

"qshape" manual page

Postfix Bottleneck Analysis document

(9) Related documentation

Threat Prevention Administration Guide (R77.X, R80, R80.10 / R80.10)

postqueue manual (Postfix queue control)

postcat manual (Postfix queue file contents)

postsuper manual (Postfix superintendent)

postconf manual (Postfix configuration utility)

postfix manual (Postfix control program)

qshape manual (Prints Postfix queue distribution)

All Postfix Manual Pages

(10) Related solutions

Configuration

sk108553 - Mail Transfer Agent (MTA) - FAQ

sk93505 - How to change the default size of the /var/log/maillog file when using Mail Transfer Agent (MTA)
sk110369 - How to configure load balancing / high availability based on the DNS configuration for Mail Transfer Agent (MTA)
sk120415 - Mail Transfer Agent (MTA) - How to configure desired text in the e-mail attachment replacement file
sk97638 - Check Point Processes and Daemons

Troubleshooting

sk120260 - MTA Debugging and Performance Troubleshooting Toolkit

sk108878 - E-mails are delayed for several hours when Threat Emulation blade and Mail Transfer Agent (MTA) are enabled
sk109198 - E-mail client receives timeout error, e-mails do not reach their destinations, and SmartView Tracker shows duplicated Threat Emulation logs
cluster
sk102494 - Check Point gateway rejects malicious attachments in email instead of stripping attachment in MTA environment
sk103752 - "There are (N) files in the remote emulation queue that have failed to send for more than (X) minutes" log in SmartView Tracker
sk105164 - Threat Emulation issues caused by non-ASCII characters
sk108073 - IP Reputation on Anti-Spam Blade does not work when MTA (Mail Transfer Agent) configured on Gateway
sk98973 - Encrypted mail traffic (SMTP TLS) is bypassed
sk109339 - MTA used as outgoing mail relay
sk105482 - Some spam e-mails pass through the Security Gateway even when the Anti-Spam blade is enabled
sk108074 - SandBlast Parallel Extraction Hotfix
sk93598 - Threat Emulation Sizing Mode: how to measure the required inspections at an organization
sk115020 - "<Name of Security Gateway> has MTA enabled, but it is not in the scope of any of the Threat Prevention policy rules" error during the installa
Threat Prevention policy

(11) Revision history

Show / Hide this section

Applies To:
This SK replaces sk118412

Give us Feedback Please rate this document [1=Worst,5=Best]

Enter your comment here

Comment 

SECURE YOUR EVERYTHING ™ Follow Us    

©1994-2022 Check Point Software Technologies Ltd. All rights reserved.

Copyright | Privacy Policy