MTA headers problem

[nemezis_rock]

Hi all,

We have started using MTA and faced problem with headers.

MTA forwards incoming mails to mail server that sits on local network.

We have configured SPF checks on mail server (which do not work on CP with Anti Spam enabled according to sk173972) and faced problem:

Checkpoint MTA puts its local address (192.168.0.1) to headers and sends it to local mail server 192.168.0.2.

SPF checks are failing (SoftFail or Fail), and every incoming email is not trusted and marked as a SPAM since every email has CP's local IP address in headers:
Received-SPF: SoftFail (mail-server.mydomain.loc: domain of transitioning
support@checkpoint.com discourages use of 192.168.0.1 as permitted sender)

R&D says that's normal behavior. Which is not. Those are not "healthy" emails.

Did anyone faced such problem and how it was handled?

[G_W_Albrecht]

This is a know issue; wikipedia gives three possible solutions that are not usable for you - Sender Rewriting Scheme (SRS) would be best, but the CP MTA would have to do SPF by itself (and it can not). So i would suggest to use SPF only for outgoing emails.

[nemezis_rock]

While analyzing the behavior, I noticed that the MTA Postfix is already receiving emails with a wrong source IP (127.0.0.1) in the headers. This makes me think that there is an internal process or inspection engine that sits *before* the MTA and handles SMTP sessions initially, modifies the headers (source IP – deletes it), and then relays the email to the Postfix instance via localhost (127.0.0.1).

If that's correct, then:

- Postfix configuration (editing mta_postfix_options.cf) cannot fix this, because it receives already altered headers

- SPF validation will always fail under any circumstances, since the original sender IP is completely lost before reaching Postfix

- The only real fix would be an architectural change or engine patch delivered via future Jumbo Hotfix

This means all incoming emails will always be marked as spam due to SPF failure, and there will be no reliable way to determine whether a message is spoofed or legitimately sent?

[G_W_Albrecht]

I would suggest to contact CP TAC - they could give you at least more information or will be able to resolve the issue!

[nemezis_rock]

I've already did it. TAC cannot help with that.

[Wolfgang]

@nemezis_rock TAC is right, this is how it works. Normally SPF check should be done on the first MTA in your environment receiving the mails from the world. This is now your Check Point gateway right ? There are some limitations if you're are using SPF checks described in the known sk. Your SPF-checks are done on the next mail-hop and this will be result in some problem, because Check Points MTA add some headers. This is how it works.

We had the same problem in the past and we could add some exceptions for SPF-checks on the second mail-hop. Exceptions are done for 127.0.0.1 and the IP addresses of the Check Point gateway. With these exception SPF-check was fine.

[nemezis_rock]

Those exceptions are bypasses and not a valid SPF-examination right?

What I am saying is that the MTA is already receiving altered header with wrong address. Look at mail route (email sent from gmail address):
Received: from localhost (localhost [127.0.0.1])
by mail.mydomain.com (Postfix) with ESMTP id 4Zj8skl4sdfhfghdf7QmPS
for <me@mydomain.com>; Wed, 23 Apr 2025
X-MTA-CheckPoint: {6809F-0-B8C0-778D}
Category=, control=Content Anti Spam
X-Control-Analysis: str=0001.0A00D.6808.0047,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
Received: from mail-eqwe-asd.google.com (localhost [127.0.0.1])
by mail.mydomain.com (Postfix) with ESMTPS id 4Zjasd11dfhg34z7QQmN
for <me@mydomain.com>; Wed, 23 Apr 2025
Received: by mail-eqwe-asd.google.com with SMTP id 4fb4d7f45sdfsdfd1cf-5f5bef591d6so1sdfsdf0459993a12.1
for <me@mydomain.com>; Tue, 22 Apr 2025 23:45:51 -0700 (PDT) 

First Received (the bottom one) is from Google - it is expected. The second (bold one) is MTA's - it received email from google.com with 127.0.0.1 address. This is first hop. That's what I am talking about.

[Wolfgang]

@nemezis_rock  

You wrote "Those exceptions are bypasses and not a valid SPF-examination right?  <= YES

We used Check Points MTA and AntiSpam solution for gateways a lot of years, but recently we moved to another vendor for securing on premise environments. The Threat Extraction feature is great but all other is worse to configure and to troubleshoot. I believe there is no development for the MTA solution right now. See my older post  SPF with MTA - Check Point CheckMates not much changed since then.

If you have a chance to go with HarmonyEmail and Collaboration (HEC) go on, this will be nice and has a good working SPF, DMARC etc.