SpamFoo with an alternate Anti-Spam architecture
Idea shared by Douglas Foster - Today at 1:25 PM
Proposed
Tim has outlined how a weight-based rollout of SpamFoo worked so well for their organization.   Their anti-spam strategy assumes a workforce that can effectively share responsibility for spam identification.

Our approach is very different.   We barely use weight-based scoring.   One of our goals is to ensure that dangerous messages never reach the intended recipient, because users cannot be deceived by messages they never see.    Stated differently, our goal is to deliver all of the wanted messages and none of the unwanted messages.   Heuristics and probabilistic strategies do not serve that purpose, certainty is required.   The only result we consider certain is our reputation data.   Authentication failures and content filtering failures are routed to quarantine.   When content filtering failures are detected, we need to block the sender so that his unwanted messages will continue to be blocked he changes content.   If the attack is an impersonation, the impersonating identifiers need to be extracted and blocked, also to block future attacks.    False positives need local policy changes to ensure that future messages from wanted senders will be accepted.  All of this is performed by email administration, not by users.

I freely admit that our content filtering is inadequate, so I have a great desire to deploy SpamFoo.   But it needs to permit administrator-based filter management.    Currently, we block almost all spam by blocking most unwanted senders.   But that is causing some legitimate messages to be delayed by quarantine, even though the sender and recipient are expecting instant delivery.    The target mail flow looks like this:

1) Pre-screen incoming messages for definite accept, definite block, and definite quarantine.
2) For messages that fit none of those categories, invoke SpamFoo.
3) If SpamFoo flags the message as suspicious, send to quarantine.
4) Review quarantine and adjust local policy to ensure definite accept or definite reject of the next message.   This ensures that the next message will not go to SpamFoo, but the feedback is still missing.  The last step is to administratively feed the message back to SpamFoo with a flag indicating should-have-been-accepted or should-have-been-rejected, so that the filtering model can be updated.  The improved filter will not be used on those specific messages, but it will be smarter for processing similar messages.

Ready to move forward, and not sure that I want to wait.   Wondering about talking to SpamFoo directly about letting me build a different integration mechanism.
 

Reply to Thread

Enter the verification text