SPF with MTA

[Wolfgang]

Dear CheckMates,

has anyone running SPF with MTA following MTA support for Sender Policy Framework (SPF)  ?

After enabling, all messages from senders with configured SPF are bounced. Only messages without or with "allow all" or "neutral" SPF record are passing through MTA.

Looks like something replaces the senders IP with 127.0.0.1 and these is checked against SPF, which failed.

### log from Dasboard:
Interface Direction: inbound
Interface Name: MTA
Sequencenum: 83
Source: 127.0.0.1                      << should be the sending mailserver
Destination: 192.168.XXXXX    << internal IP of the gateway running MTA
Destination Port: 25
IP Protocol: 6
Email Spam Category: Spam
Email Control: SPF
Email Control Analysis: SPF failure
Email Session ID: 5ECBADD7-0-FBE99C50-4B48
Email ID: 1
Sender: XXX@XXXX.de
Email Recipients Number:0
Action: Reject
Type: Log
Policy Name: Standard
Db Tag: {F7B72303-65BF-914E-ABED-46EC62E402D3}
Blade: Anti-Spam and Email Security
Service: TCP/25
Product Family: Network
Marker: @A@@B@1590357600@C@5864361
Log Server Origin: 192.168.XXXXXOrig Log Server Ip: 192.168.XXXXX
Interface: MTA
Description: Spam Rejected

Any help appreciated,

Wolfgang

[PhoneBoy]

Guessing a TAC case might be in order.

[liorj]

Hi, 

several questions:

a. which MTA take/update are you using and which blades are currently enabled.

b. could you copy paste here the spf configuration you used in $FWDIR/conf/mail_security_config file.

c. The scenario where emails are being bounced because of SPF check failure shouldn't happen - instead those emails should be dropped. Neither the 'source' field in the log should be 127.0.0.1 as you said. Could you follow sk139892 and enable the debugs with debug toppic 'ALL'. Then send one email for example to replicate the issue and send over the mta debugs(located under $FWDIR/log/mtad.elg*) and files named maillog under '/var/log'. 

I'll go over the debugs and try to find out what is the reason for the issue you are experiencing.

d. in addition, if you have a"special "environment or any additional information you can add about your environment(changes you did maybe lately) it would be good to know.   

[Wolfgang]

@liorj ,

the answers:

a. which MTA take/update are you using and which blades are currently enabled.

MTA Version => 8030.991002055

blades => ASPAM, AntiBot, URLF, APPLC, AntiVirus, IPS, Firewall, VPN, MOB, HTTPS inspection (no ThreatPrevention, no ThreatEmulation)

b. could you copy paste here the spf configuration you used in $FWDIR/conf/mail_security_config file.

[spf]
enforce=1
action_spam=reject
action_suspected_spam=monitor-only
track_non_spam=log
track_spam=log
track_suspected_spam=log

c. The scenario where emails are being bounced because of SPF check failure shouldn't happen - instead those emails should be dropped. Neither the 'source' field in the log should be 127.0.0.1 as you said. Could you follow sk139892 and enable the debugs with debug toppic 'ALL'. Then send one email for example to replicate the issue and send over the mta debugs(located under $FWDIR/log/mtad.elg*) and files named maillog under '/var/log'. 

We had TAC involved and case is open. These debugs are done, I'll PM you the SR number.

d. in addition, if you have a"special "environment or any additional information you can add about your environment(changes you did maybe lately) it would be good to know.   

no special configuration there

Wolfgang

[Benedikt_Weissl]

We have the same issue, did you ever find a solution?

Regards

[Wolfgang]

Hello @Benedikt_Weissl ,

the problem still exists. SPF-checking does not really work on the gateway. TAC case is open since some month, they found the problem and they're able to replicate. But the solution needs a lot of new coding. 

We tried the same with R81but same problem. If you want I can provide the case number.

Wolfgang

[Benedikt_Weissl]

Thanks for the update, I've also raised a ticket.

Lets hope for the best.

Regards,

[muhannad]

Is there a solution for this issue with R81 T392 ? can you please the SK or SR ?

Thanks a lot

[Wolfgang]

@muhannad SPF check is working now. But limitation exists if you run MTA in ClusterXL environment.

MTA Issues with SPF (Sender Policy Framework) 

[Jean-Francois_G]

Hello @Wolfgang im in the same situation as you 

Im running a cluster environment R81.30 Take 30 with MTA and Anti-Spam blade enabled.  I would like to add SPF protection but it seem impossible ?  That is weird that we cannot have Anti-Spam Blade and SPF enable both at same time.  Do you have any information if they will fix this ? 

Thanks ! 

[Wolfgang]

@Jean-Francois_G  as I know there is no  development to fix this issue and no plan for the future doing this. There is no really ongoing for the mail security solution running on GAiA appliances. The catch rate is perfect and only from a security view this is a nice solution, but the configuration and debug in case of error is worse. The configuration between old SmartDashboard, ThreatPrevention via SmartConsole and local files for postfix changes is a nightmare….Looks like only 3 guys at Check Point are having enough knowledge to support MTA issues.  Yes, there are some nice new features like URL-rewriting or AntiPhishing… but configuration is worse and they are all in beta.
We are on a way migrating our customers to another solution for mail security.

[Jean-Francois_G]

@Wolfgang thanks for sharing this information