Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Rui_Meleiro
Contributor
Jump to solution

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?

0 Kudos
1 Solution

Accepted Solutions
Rui_Meleiro
Contributor

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.

View solution in original post

0 Kudos
6 Replies
PhoneBoy
Admin
Admin

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 

0 Kudos
Rui_Meleiro
Contributor

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.

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Rui_Meleiro
Contributor

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 

0 Kudos
PhoneBoy
Admin
Admin

Send me the TAC SR number as a private message, I'll see what I can do to move things along. 

0 Kudos
Rui_Meleiro
Contributor

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events