Outbound filtering - part 6

At this point, I hope I have made my point that the question of outbound filtering is non-trivial.  I'm not particularly keen on treating inbound mail the same as outbound mail (ie, scan, filter, deliver or quarantine) because of the time delay.  Ideally, I'd like a bounce to be instantaneous.

On the other hand, I've never been entirely comfortable with the challenge/response model.  However, I suppose in this case, we are only challenging on messages that we have identified as spam and then providing the user with a workaround to force their message through.  But on the other hand, a clever spammer, if they wanted to target us and one of our customers who uses this for outbound, they could conceivably game the system.

It looks like a more complicated solution to the problem will be the one that we will pursue.  Unfortunately, a more complicated solution will involve a bunch of changes to the hardware infrastructure.  It's not necessarily a bad thing but it will take forever to get it out the door (Microsoft development cycles take an eternity... PM spec, dev spec, test spec, coding phase, test phase, staging, stabilization, release-to-operations which is itself another eternity... and only then the product is out the door).

So, internally here, the discussions continue but it looks like we are starting to converge on a strategy (at least for now... I have another wider meeting with more people on Wednesday so things could change).  My hope in this series of posts was to provide a little bit of insight into how tech decisions are driven in my division when I am in charge of the feature.