I've been wanting this for years. I believe I've even got an open enhancement request on it.
If you haven't logged a product enhancement request to add a log onto the "me too!" fire, please do.
Enhancement requests are submitted at https://mcafee.acceptondemand.com/ and you need to use IE. If you haven't used it before, there's a link for mcafee customers to register.
https://kc.mcafee.com/corporate/index?page=content&id=KB60021 documents the process with more words.
Assuming that you have our SaaS feature, and are willing to configure it, there may be a solution ready for you soon. We are curently working on an upcoming version of the product which is supposed to have our ClickProtect feature present in it. Currently, Clickprotect is only available for our SaaS customers, but it will become available for Hybrid customers as well. Basically, this replaces suspect URLs in messages with a link to the SaaS servers, which would then tell users that the link they have clicked is suspect and may be malicious, and ask them if they really wish to continue.
I wish I could say with certainty in which version this feature will be added or when that version might be released. Suffice it to say that I understand that it's currently under work, and that you should look forward to it within the next year or two. Unfortunately, I am not currently aware of a "standalone" version of this which does not require that an admin at least have the SaaS services provisioned. If you would like this, please submit a PER as described above.
Thanks eplossl. I recall talking with some folks at FOCUS about this click protect feature.
I checked and I actually didn't have a PER on it, but we do now. :-)
In our case, we really want it in the standalone product in the present environment. Here, we need another link in the email chain that could fail like we want a hole in the head. Granted for some environments the hybrid deployment or SaaS is great, but alas, SaaS Clickprotect won't solve our problem.
Curious do Exchange versions beyond 2010 have such a feature I wonder?
Regarding the need for "standalone" vs. "SaaS" with regards to this particular feature:
The reason for the convergence of the platforms for this individual feature is that as the URLs come in, they get rewritten to redirect back to cloud services. This is done to block loading the URL in case it's blacklisted, or in case it isn't blacklisted to be checked again. This feature takes care of malware that attempts to exploit the delta period between when an email is delivered and when it is opened. To illustrate this concept, say I'm a malware purveyor and spammer who puts up a clean site or references one, sends you an email with the link to that site embedded, let it get past your email defenses, then deliberately infect the site. That link was clean when I sent it; it wasn't when you opened the email and clicked it. The solution to that scenario is to check it again as it's being opened. The best place to do this isn't on a local appliance, it's in the cloud so that the most accurate and up to date reputation information on a URL can be obtained. It's either this "link in the email chain that could fail" or introduce a link called "update all URL reputation info to standalone appliances in the field" that could fail. If ClickProtect were solely appliance-based, the latter is what you would have to do. In my opinion, this would be problematic.
The counter argument however goes something like: "Local appliance should be able to have equally up to date threat information because... GTI."
No doubt it will involve a separate engineering effort, but I don't see how the problem is necessarily any more difficult at the local appliance level with GTI real time lookups available.
Also, what I want is for ALL links to be disabled from being clickable through to live sites. If I can in policy either remove the hyperlinking (which attackers would probably figure out a way to bypass), and/or rewrite the url.hostname appending DISABLEDFOR.mydomain.com making users manually fix that in their browesr URL bar after a 404 if the resulting url passes some sanity test for them, I'm okay with that level of ugliness.
That this problem is kinda difficult is no execuse, in my opinion to do nothing on this front for standalone appliances. The threat of these is serious, and currently the email gateway product is impotent against them. The amount of spam that gets through that are obvious phishes where there are URL links that display one URL and a href= to something entirely different should be at least as much of an embarassment to product management as it is to someone like me who has shrug when someone says "your fancy mail gateway didn't block THIS?!"
In short, I really do think product management should get click protection capabilities into standalone boxes too.