We've been using SBRS[6.0:10.0] as the basis for whitelisting for several years now. We just discovered last week that this is no longer a good idea. A host with SBRS +6.3 was sending us phish, which got right past our defenses due to the whitelisting. Ouch. Of course, it is for reasons exactly like this that phishers seek to obtain credentials on reputable mail servers.
Just thought I'd share the good news with others who might be interested...
Yep, we have seen exactly the same. We do the same and SBRS[6.0:10.0] is the same than 'whitelist'. For us it means that this mail flow policy have much more relaxed rules (no rate limiting, no flow control, no DHAP, no sender DNS verification) but it still use SPAM and virus detection.
As an addition there is very, very rarely used 'Bypass SPAM filter' mail policy which is used only when true false positive Spam verdict happens, this will allow those special senders to bypass Spam detection but still obey SBRS and mail flow policies.
We've been seeing the same thing as well. We used to install devices with a whitelist SBRS[6:10] by default. But over the past year or so, the reputation score of many servers has increased.
A lot of servers that I don't trust now have a score higher than 6. So I have updated our default policy to only whitelist scores higher than 7 and I'm concidering removing SBRS from the whitelist entirely.
Of course, the devices deployed with the old policy are now receiving more spam and I'm getting more and more complaints about this. Thats the problem with devices that "just work" - people forget how to manage them ;)
Well well, it just keeps getting better. I've changed our WHITELIST definition to SBRS[8.0:10.0], and that addressed the immediate problem. But now there's a new one. SBRS is one of the factors that CASE considers when making a spam determination, and the sending host has such a high reputation that it's pulling the spam verdict up from "CASE spam positive" to "CASE spam suspect". When the very same spam arrives from another source, it's "spam positive". I've been working with someone inside IronPort, and he's confirmed that this is indeed what's happening. The sending host has a deservedly good reputation because their spam volume overall is small. It's actually phish we're getting from them, most likely via webmail accounts which have themselves been phished.
Anyway, be on the lookout for this, too. It's easy enough to address with a content filter. Make sure your "suspected spam" policy includes tagging the message in some way (we use an X-header), then use a content filter that checks for the tag and for SBRS > 6.0, or whatever threshold is appropriate for you.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...