Tracking spam false positives

[Rui_Meleiro]

Hi

On R80.10, we are using the MTA/Postfix mail gateway. There are some legitimate messages that are being tagged as spam and are registered on the logs. Nevertheless, we cannot find an absolute reason for those as the detailed log does not show all information - namely, the SMTP headers and the sender IP is "masked" by Postfix. Is there any way to get that specific information using SmartConsole, or even on the MTA/Postfix logs?

Regards

Rui Meleiro

[Rui_Meleiro]

After no answers and a lot of work with Support, I got the conclusion that the Checkpoint Postfix integration does not allow that, as the gateway receives the SMTP traffic from Postfix and loses most of the SMTP headers in the process, go figure.

[PhoneBoy]

Postfix is there, but it's used for Threat Emulation and DLP, and not meant to be generally configurable.

We generally don't use it for anti-spam.

Where is "spam" indicated? Can you maybe include a screenshot?

[Rui_Meleiro]

All of our inbound SMTP traffic is delivered to the MTA and then to the Exchange server. Then it is flagged as spam, although it shouldn't. This flow removes some of the original SMTP header, such as X-Originating-IP.

[PhoneBoy]

If I understand, the Anti-Spam blade on the Security Gateway is blocking email that goes through the MTA on the same Security Gateway?

Or is this a different Security Gateway that's flagging this?

[Rui_Meleiro]

No, that's the very same 5100 gateway. Mind you that blocking the message might not be wrong, our problem is on the logs and methods available to verify and confirm that. The senders are bona fide partners whose messages are sometimes flagged as spam. In some situations we are able to identify the reason - one of them had an employee sending mail from their home via SMTP without server validation (i.e. the originating IP address was in the dynamic space and there was no SPF compliance).

Hence the need to get more info on the logs. There are options to change Postfix main.cf settings to increase the log level, but I really wanted to look at all the other alternatives first.

[PhoneBoy]

Just to confirm I understand the situation:

• The Anti-Spam blade is flagging some messages as spam, but isn't giving you enough information about why.
• The Threat Emulation MTA (which uses Postfix) is stripping away some of the SMTP headers that might help you make this determination on your own.

[Rui_Meleiro]

Precisely.

[Rui_Meleiro]

Getting back to this, if I may.

As I was trying to check why some of the SMTP traffic we're receiving had been Bypassed i.e.not scanned by any Threat... blades, found something rather odd. Two reasons for messages being bypassed were apparent - "Temporary scan failure" and "Encrypted session". The former being a policy issue, the latter is undoubtedly TLS related. Yes TLS is properly configured on the MTA and a valid certificate is installed.

Could TLS then also be the reason to the SMTP headers "tampering"?

I've now disabled TLS temporarily and will keep it that way for a few days until enough SMTP traffic flows and events are collected.

[PhoneBoy]

An encrypted session should terminate on the MTA (particularly if you've configured it properly) unless there was a TLS error.

I wonder if there are any logs on the gateway that might indicate what actually happened with this particular session.

[Rui_Meleiro]

I agree MTA should initiate TLS, encrypt the session and then deliver the message to Threat E&E already unencrypted. But, it that were the case, then Threat E&E shouldn't bypass it as being encrypted.

What I can tell you is that by deactivating TLS I now have fewer false positives (although SMTP headers still are obfuscated), no Bypass actions for any of the two reasons ("Encryption" and "scan failures").

Will take a closer look at TLS (wait, I still need the Postfix logs).

[PhoneBoy]

There's a process to follow with the TAC to better understand false positives with Anti-Spam.

Refer to the following sk: How to submit a False Positive case for Anti-Spam protections 

It'd also be useful to get some of the impacted emails as well. 

Generally speaking neither Postfix with Threat Emulation or Anti-Spam should modify the general SMTP headers (confirmed with R&D). 

One exception to this is X-Forwarded-For, which might be modified when Anti-Spam and the MTA interact. 

It might also modify headers of specific attachments, but not the general SMTP ones.

Either way, we need to get more information.

Open a TAC case and gather the following recommended debugs.

Please send me the ticket number in a PM and I'll make sure R&D assists.

For gathering debugs while this issue reproduces:
· Enable AS & MTA debugs
fw_debug in.emaild.mta on TDERROR_ALL_ALL=5
fw_debug in.emaild.smtp on TDERROR_ALL_ALL=5

· Reproduce the issue
· Disable debugs
fw_debug in.emaild.mta off
fw_debug in.emaild.smtp off

· Provide the following files:
$FWDIR/log/emaild.mta.elg* files
$FWDIR/log/emaild.smtp.elg* files
/var/log/maillog*
/opt/postfix/etc/postfix/main.cf
/opt/postfix/etc/postfix/master.cf

[Rui_Meleiro]

Thank you, Dameon, for your feedback. I really appreciate your availability on this. As I've said, I've narrowed down the problem to the TLS encryption process, which seems (and I underline seems) to cause these problems with both false positives (tagged in the content based anti-spam feature) and bypassed messages due to encryption.

As you would agree, I'm sure, this is not a straightforward process, as I don't want to force anything on the sender side as they would eventually change the environment on a controlled test.

So, what I'm going to do is to monitor these issues in the coming days keeping TLS off and turn it back on later on to collect the data you've suggested.

I'll get back on this as soon as I have that info.

[PhoneBoy]

Completely understand, keep us posted.

[Perry_McGrew]

This is one of the features we have licensed but not really implemented yet.  Will likely to continue hold off until we understand how this issue is addressed.  Reliable email delivery and easy debugging are critical for us.  We also need some sort of quarantine feature -- as we are in health care industry and often receive email that will get held up due to language used -- we need to be able to release the email if needed.   I don't believe CP has this quarantine feature yet in their Anti-Spam blade.