> Source: [sk180346](https://support.checkpoint.com/results/sk/sk180346)

# sk180346 - High latency in email delivery through a Security Gateway in the MTA mode

| Property | Value |
|----------|-------|
| Solution ID | sk180346 |
| Date Created | 2022-12-03 |
| Last Modified | 2024-11-20 |
| Technical Level | Advanced |
| Products | Security Gateway |
| Versions | R82, R81.20, R81.10 (EOS), R81 (EOS) |
| OS | Gaia |

## Symptoms

- * High latency in email delivery through a Security Gateway in the MTA mode.  

* Output of the "`/opt/postfix/usr/sbin/cpqshape incoming`" command shows emails that are stuck.  

* Output of the "`/opt/postfix/usr/sbin/cpqshape active`" command does not show any latency/delay.  

* MTA debugs do not show any errors/reasons for this issue.   

* The `/var/log/maillog` file (Postfix log) shows that all the emails are delayed in the message transmission stage.  

  Example:  
  `[date, time] postfix/smtp[46116]: 4MHdZr4G8dz57fNj: to=xxxxx, relay=1.1.1.1[1.1.1.1]:25, delay=523, delays=523/0/0.01/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4MHdkP5s6Fz50ZSV)`   

* When the number of emails per minute reaches a certain value (depending on the Security Gateway's capabilities), there is high latency in email delivery.  

* The Check Point appliance has sufficient hardware specifications for the number of emails it needs to handle in the MTA mode.

## Cause

The machine that transfers emails to the gateway is not in the same subnet as the gateway's interface.  
This issue occurs because there are several sequential checks that postfix does on the mail (with several commands (RCPT TO, HELO, etc.). These include ***smtpd_relay_restrictions*** , and ***smtpd_recipient_restrictions*** . Postfix checks these restrictions in the mentioned order: it checks ***relay_restrictions*** , and only after enforcing them, it continues to enforce ***recipient_restrictions*** .Therefore, if a mail is sent from a machine that is in "***mynetworks*** " (a parameter in Postfix that includes the networks under the gateways' subnets), it is more "privileged" in terms of client authentication, but does not bypass the ***recepient_restrictions*** , according to which we only allow specific domains.  

This issue occurs when the machines that send the emails to the MTA gateway are not configured under ***my_networks**.* Therefore, they must pass the authentication process on each connection. This causes a high load on the postfix process, which prevents it from handling these emails.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content