MTA "Received:" header

[benko2]

I'm running Check Point MTA version 8120.991002021 on active-standby cluster (R81.20 JHF Take 41). It runs as the organization MX record. Only myhostname=gw.example.com configured in $FWDIR/conf/mta_postfix_options.cf. No changes in $FWDIR/conf/mail_security_config.

MTA is working as expected. But for every email from internet to our organization MTA adds headers like this:

Received: from localhost (localhost [127.0.0.1])
by gw.example.com (Postfix) with ESMTP id 4T7zDy6xdyz6PXZ
for <info@example.com>; Mon, 8 Jan 2024 16:56:02 +0100 (CET)
X-MTA-CheckPoint: {659C1B12-0-F35B6A0A-33EA}
Category=, control=Content Anti Spam
X-Control-Analysis: str=0001.0A682F22.659C1B13.0003,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
Received: from mail-il1-f170.google.com (localhost [127.0.0.1])
by gw.example.com (Postfix) with ESMTPS id 4T7zDy5jnKz6PXY
for <info@example.com>; Mon, 8 Jan 2024 16:56:02 +0100 (CET)
Received: by mail-il1-f170.google.com with SMTP id e9e14a558f8ab-3608bd50cbeso4579985ab.3
for <info@example.com>; Mon, 08 Jan 2024 07:56:02 -0800 (PST)

The problem for me is the red text. Why MTA doesn't fill the real IP address of the google mail server and uses the localhost [127.0.0.1] instead?

Emails with such headers are marked as spam when they are forwared to Office 365.

[PhoneBoy]

If I had to guess, it's because of how traffic is directed to Postfix (the underlying MTA used).
In any case, this is probably worth a TAC case: https://help.checkpoint.com 

[benko2]

This is the response from the Check Point Support case:

The MTA header is modified because of the AntiSpam blade, it cannot inspect the encrypted emails, AntiSpam cannot process encrypted emails and instead forwards them to the gateway at 127.0.0.1 and it is a limitation.

The AntiSpam flow is as follows

Internet -> Gateway AntiSpam -> MTA -> next hop

AntiSpam inspects the mail before it gets decrypted by MTA.

The R&D team confirmed this requirement needs to be addressed over an RFE [Ref: sk71840]. You can contact your Local Sales Engineer/Team, who may help submit a Request for Enhancement (RFE), per sk71840.

[benko2]

At the moment I resolved my problem by:

• turning off the Anti-Spam & Email Security blade and
• activating the SPF according to sk146412

[benko2]

One day later (after turning off the Anti-Spam and using the SPF) I realized that

• in MTA blade logs (Email Headers tab) string (localhost [127.0.0.1]) doesn't occur anymore
• but the gateway still adds the (localhost [127.0.0.1]) string to email header when sending it to the next hop (this can be easily checked by showing the email header on the next hop)