- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Tracking spam false positives
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tracking spam false positives
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Precisely.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Completely understand, keep us posted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.