Video Screencast Help

Scanning url in emails

Created: 04 Mar 2013 | 6 comments

Hi we have been pretty clean since switching from the Sophos solution to SMG. However Sophos blocked emails with suspisous links where SMG doesn't seem to be able to. There are some infected hosts outside our network (mostly old customers of ours) which are spamming email addresses held in their users address book. The emails contain nothing but a URL to some dodgy sites. Basically how do I get the SMG to scan these URLs?


Discussion Filed Under:

Comments 6 CommentsJump to latest comment

BenDC's picture

with version 9.5 and later there is now an option to scan for suspect urls. This can be found in Spam settings under Suspecious URL content.

You may need to enable the rule and assign a policy group to it.

theluketaylor's picture

A warning about the suspicious URL check: it is not great to use for deletion as the rules are not spam specific.

It's basically looking for url shortening services, not malicious or otherwise spammy links.  This means legimiate messages that embed tweets or newsletters that use are flagged as suspicious url when the email content shouldn't be blocked.

We've been very disappointed with SMG's inability to catch bad URLs.  There are 2 cases it's especially bad at:

email that contains little more than a single link to malware or ad networks

spoofed URLs in the form <a href=""></a>

If anyone has found effective ways to use SMG to block this I'd be interested.  We have a http proxy blocking most of the links that come in this way but it's very frustrating to get so much spam we're already blocking the content of.

Brecon57's picture

My experience is as yours Luke. I have turned on the suspicious URL scanning with action to modify the subject line "Caution this message contains suspicious URL content". A short while after doing this I received an email from this thread telling me I had a response. This email had been classified as having a suspicious url and it's subject line was modified. 

This is shotgun approach and next to worthless. Symantec describe themselves as industry leading in this field. If Sophos can stop this stuff (at twice the cost granted) why can't Symantec?

Art_P's picture

As mentioned, the Suspicious URL feature was poorly named and is mostly directed at URL shortners. Since SMG has historically been very careful against false positive detection, the Global Rules require an amount of reporting (from both end users and automated honeypots) before rules are created against particular signatures (the URLs).

The typical way to handle these in SMG would be to use the Customer Specific rules, which is a new feature to version 10:

Version 10 also introduced scanning within HTML tags, so direct rules can be written against HTML in messages, which is something that previous versions did not have:

As the malicious messages are submitted to Symantec Security Response in general (as well as through using the Customer Specific Spam Submissions), rules will be generated to catch them. If it is a targeted attack, it may take longer to generate a Global Rule, but this is the reason for the Customer Specific rules.

Submitting missed spam in general:

theluketaylor's picture

customer specific rules have been powerless against URL spam.

Spammers use redirects that change hourly, pad their spam with different other content and merrily spam away.  Customer specific signatures are looking for messages that don't exist anymore, meanwhile the same final link is delivered hundreds of thousands of times per day

Rose McGuigan's picture

In recent months we've added additional backend technology to enhance detection of URLs that redirects to malicious or spammy sites.  This is part of our link following technology which was developed by our .cloud email security team and is being intergrating for our messaging gateway customers.

If you're noticing an abnormal increase in missed detection against these types of attacks, please submit them. I would also recommend opening a support case to ensure you are configured optimately as an increase in missed detection can indicate a potential product side issue.

We've similiar reports of this and the result was typically due to product configuration issues.