topic Re: MTA "Received:" header in Firewall and Security Management

MTA "Received:" header

benko2 — Thu, 18 Jan 2024 15:22:13 GMT

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.

Re: MTA "Received:" header

PhoneBoy — Wed, 24 Jan 2024 22:57:03 GMT

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

Re: MTA "Received:" header

benko2 — Mon, 07 Oct 2024 08:32:59 GMT

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.

Re: MTA "Received:" header

benko2 — Wed, 30 Oct 2024 13:07:45 GMT

At the moment I resolved my problem by:

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

Re: MTA "Received:" header

benko2 — Thu, 31 Oct 2024 10:14:54 GMT

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)