//
you're reading...
Security

Antispam: Aggressive False Positives

Here’s a discussion point.

Some rules in almost all antispam solutions (indeed in some software almost all rules) cannot be turned on or off.
Some can be desensitised or their aggression lowered but they still remain active.
What do you do if they still collect false positives? Even worse, what if those false positives relate directly to your financial arm, credit control or remittence?

Support
First thing, of course is to escalate the issue through whatever support you have available for the product. You never know, there are often hidden features or obscure switches that control all sorts of things in software. Of course this is far less likely if your solution is SaaS based.
Workaround
If the product support are unable to provide a solution, ask them about workarounds.
The chances are you will be asked to use some sort of whitelist. Probably a sender whitelist, or approved senders.
On the face of it this seems a reasonable solution. But it has repercussions.
Problems with Whitelists
I can see three primary issues with whitelisting:

  1. Spoofing
    The domain or addresses can be directly spoofed by spammers and your new approved sender rule bypasses all your checks.

  2. Domain Trusts
    The vendor/customer has now been completely trusted by your domain. If they get hijacked and become a source of spam you won’t be blocking it. Indeed, you may never be aware if it, unless your users complain.

  3. IP Trusts
    Even worse than whitelisting a domain can be whitelisting an IP Subnet. Now any mail from that array of machines will bypass your antispam. This is a favourite of marketing firms as it allows mail for all their customers through your filters.

Viruses
Don’t be afraid of viruses, though. Malware of all types should still be blocked. The antivirus portion should be applied independently of the antispam. It is an important question to ask your provider though.
SPF
Of course you could try implementing Sender Policy Frameworks. This indicates trusted sources for a particular domain.
But most of the time these are deny checks in support of the standard set of deny checks rather than allow rules. They simply help prevent spoofing of the senders domain. But they can contain a ‘maybe‘ option that is nearly always enabled that means most of the time they are fairly useless, unless the recipient insists on strict SPF interpretations.
However, if your antispam is good enough then you can specify which sender domains have SPFs applied and you can enforce it just on those domains. Perhaps you have the ability to do this IP limiting independently of SPFs. Of course if the sending domain changes it’s habits then you’ll end up blocking it.
Problems with IP Whitelists
Above all this you could trust the sending servers but this should only be done if they are unique to the specific sender you want to receive from. Many companies use third parties to filter/control/archive outbound mail and so this isn’t an option without allow all customers of that service. We live in a SaaS age so this is likely for the majority of large companies.
Then we have outsourced CRM, Finance, marketing (and required mass mailing) etc.
You can see the problems caused.
Recommendation

  1. I think the only solution is to push the vendor as hard as you can to resolve any False Positives.
  2. Whitelists of any sort should be used with caution but you may simply have no choice.
  3. Never whitelist addresses in you own domain. Don’t even consider ever whitelisting your entire domain.
  4. If you enable inbound SPF checks try to be strict with any that exist but SPFs won’t help get past the antispam but may add protection where Whitelists exist.
  5. Only whitelist IPs or Subnets where the source can be trusted.
  6. Seriously Consider changing antispam provider.

Not a good position to find yourself.

About harlekwinblog

"Thoughts of an idle mind." Information Security professional.

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Categories

RSS This Blog…

  • An error has occurred; the feed is probably down. Try again later.

Share me…

Bookmark and Share

Twitter Updates

August 2011
S M T W T F S
« Jun   Sep »
 123456
78910111213
14151617181920
21222324252627
28293031  
%d bloggers like this: