Should the MTA send a NDR (Non delivery report) to the sender if the mail was not delivered? Is there documentation about this? Can this be set up using postfix in CheckPoint?
According to this SK, it seems it should do so: Anti-Spam blade sends Non-Delivery Report (NDR) when Mail Transfer Agent (MTA) is enabled on Security Gateway
It is the default behavior.
Thanks. I also saw this sk, but can there be experts in the community, who uses this function? Because this function has never worked by default. Or are there any nuances of her work? MTA not generating the "undeliverable message" when an email is rejected is not relevant for me, I think. The situation is as follows: it is necessary that the MTA send a NDR if the internal mail server is unavailable.
If I'm reading this SK correctly, it seems we're only generating NDR messages if we reject the message.
That said, if the remote server is unreachable, it seems reasonable that we should generate an NDR message.
If I am assuming it correctly, you are expecting an NDR from CP gateway(MTA) device to be send to original sender(internet).
sk109339 says that Mail Transfer Agent (MTA) can be configured on the Check Point Security Gateway only as an incoming relay.
I also had a scenario, wherein the TE appliance was deployed in MTA mode and an NDR was sent out to the original sender(internet) by relaying it through the mail server.
Tell me, please, in more detail, how you organized such scheme, and what settings are needed.
In my case, the scenario was Internet>>Email gateway>>>TE appliance(MTA)>>Exchange Mail server.
and the exchange email server decided to reject the message due to attachment size limit. NDR was sent to the original user(internet) by check point MTA because there was a forwarding rule in check point MTA allowing to send the NDR to that sender domain. In my case it was (*) hence I guess it worked.
Also I believe the settings in the email server is also to be considered while sending out this kind of reject messages.
Whether the email server wish to sent the NDR directly or through our MTA just before it.
1. An email is being bounced in case of an unrecoverable error. So in case of an attachment size limit, it is considered by the mail server/MTA next hop as an unrecoverable error, while "mail server unavailable" is considered as temporary failure.In case of temporary failure, the email would be kept on "deferred" queue for 5 minutes, and then MTA will try to communicate with the next hop again. In case of another failure, the "penalty" of this email to be left on queue would be doubled (10 minutes), and would exponentially grow with any additional failure.The maximal time an email would be reside on MTA queue is 5 days by default.
2. As a bounce email is actually a new email sent back to the sender, we should have a relevant rule on MTA forwarding rules for the sender domain. This is why a common practice is to use "*" as another rule, which would be the rule for relaying all the rest of domains, including the sender domain.
Hope it clarifies things.
Let me know if something isn't clear or missing.
Mail security Team Leader
Thanks a lot for reply!
Few questions for you:
1. Where can I change default parameters, which you described? I mean time of "penalty" and the maximal time an email would be reside on MTA queue.
2. How should my rules for mail look if I need to:a. Decrypt the mail for the test.com domain (SMTP over TLS) and forward it to the internal mail server. Inspect these emails with Threat Emulation.b. Do not touch mail from other domains, don't emulate them.c. Have the ability to send a NDR.
1. The "penalty" is being controlled by Postfix starting with "minimal_backoff_time" (5 minutes by default), up to "maximal_backoff_time" (~66 minutes by default)The maximal time an email would reside in queue is "maximal_queue_lifetime" (5 days by default)You could manually configure Postfix parameters using sk101870.
2. In case the MTA receives the emails directly from internet, you should configure the MTA with the DNS server, so that it would be able to relay bounce emails according to the sender domain.In this case the only rule should be used is of test.com as the domain with the required next hop.
In case the MTA is internal, receives the emails from a preliminary MTA (e.g. Anti Spam), then it is the preliminary MTA responsibility to reject emails with recipient other than "test.com", and in this case you could either use the same rule from above, so that bounce emails would be relayed based on DNS queries, or create another rule with "*" as the domain, for directing all other emails (that are only bounce emails in this case) to a specific next hop.
Retrieving data ...