- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- URL shorteners tagged as spam
- 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
URL shorteners tagged as spam
Since last week we've started having multiple spam false positives (from Content Anti Spam engine on a Checkpoint 5100 R80.10) using a cumbersome trial-and-error proces we've pinpointed the problem to url shorteners. Most of the messages being tagged as spam had them on their signatures. I'm guessing a recent engine or definitions update started causing this. I'm all for dumping those bad guys, and am more than happy that Checkpoint continuously improve their engines.
What I've been trying to find, however, is a way to both identify the reason for the spam tagging and how and where to fine-tune that.
After all, if the Anti Spam engine checks conditions A, B, C, D, E, F, why wouldn't the error message being logged was "Tagged as spam because of D" insted of "Spam Rejected"?
Having to tell my business partners that we are rejecting their messages just because is not a good way to keep that business relationship. Specially if they reply - you're the only one rejecting our messages.
Has anyone experienced this problem and if so, were you able to work around this?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After 12 days working with TAC on this, it turns out that the shortened URL was in fact the problem. Not per se but due to the unfortunate fact that it was recently inserted onto our email corporate signature and used company wide. Somehow this shortened URL in combination with the remainder signature matched one of the "spam patterns" Checkpoint uses to identify spam. As we are not checking outbound spam, everything went astray as soon as our business partners started replying to our messages, carrying along that dreaded spam pattern we unwilingly matched.
It is annoying that this may happen anytime, no one is able to prevent it (they are trade secrets after all, Dameon), there are no guidelines on how to avoid it and it takes forever to identify.
Anyhow, I'm sharing the explanation I've got for future reference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as I know, we do not provide the logic for why a particular message is scored the way it is.
False positives can be submitted through the TAC for review: How to submit a False Positive case for Anti-Spam protections
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not really looking for the logic behind it, which might as well be trade secrets. What I need is a reason code, a small hint on the criteria or even the reasoning behind why our applicances are blocking our partners communications. This is in my view a reasonable request.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To be clear, I'm only speaking to product capabilities.
Namely:
- The product does not disclose why a particular message is flagged as spam
- The product does not provide mechanisms to tune the spam-detection mechanisms
Again, the above is to the best of my knowledge.
The TAC may be able to tell you why your particular messages were flagged as spam.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Got it, thank you Dameon.
So, it's a product design flaw and I'll never be able to explain my stakeholders why Checkpoint is damaging our business relationships.
TAC is all fun and games, but in the real world no one has the time to go on a four day "investigation" on every message that bounces back in error.
I've opened a case with TAC two days ago and still have no answer. That's why I came here.
Meanwhile we had to work with our business partners on a trial-and-error process and found out what the problem was (it is in the header of this post).
Told TAC our conclusions.
Still no answer.
This is a déjà-vu. Last year we had to stop using TLS because Checkpoint doesn't know how to properly handle encryption.
Guess I'll go back to Fortinet. They also have a lousy product and support but at least verbosely tell me why.
EDIT: Truth be told, that was an idle threat, a simple quirk. Our investment on Checkpoint isn't fully amortized and it would be absurd to change path or manufacturer 9 months after. Throughout the years I've used several different providers and honestly these kind of problems are pervasive on the industry. Most of the times these security products world well or uneventfully but from time to time we get stuck on unanswered quests. Sincerily I was hoping Checkpoint would be different, for some reason.
With my past experiences most of the problems were about threats not being detected. Can't have it all, I guess
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Send me the TAC SR number as a private message, I'll see what I can do to move things along.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After 12 days working with TAC on this, it turns out that the shortened URL was in fact the problem. Not per se but due to the unfortunate fact that it was recently inserted onto our email corporate signature and used company wide. Somehow this shortened URL in combination with the remainder signature matched one of the "spam patterns" Checkpoint uses to identify spam. As we are not checking outbound spam, everything went astray as soon as our business partners started replying to our messages, carrying along that dreaded spam pattern we unwilingly matched.
It is annoying that this may happen anytime, no one is able to prevent it (they are trade secrets after all, Dameon), there are no guidelines on how to avoid it and it takes forever to identify.
Anyhow, I'm sharing the explanation I've got for future reference.
