Alan,

This is a very interesting idea. I see two potential problems, please let us know what you think.

1) we always try to recommend against using SpamFilter as an outgoing SMTP server, since it's designed to only handle incoming email. Yes, it can be used for that by whitelisting source IPs, but it does cause a performance hit. Your idea would usually require to use SpamFilter to collect destination IPs

2) Some users actually reply to spam by saying "I'm not interested", "please take of your list", "@#$%^#^$", etc... Doing so would automatically put the spammer on a whitelist!

Roberto F.
LogSat Software

I love this idea although it does bring up some interesting caveats as Roberto mentioned. But, with user education, I think I can prevent the users from sender the spammers email <g>. Plus, if they never get the spam in the first place, they won't see it to respond to it hehe (let's hope I have good filters in place).

Combining this with the current strong bayesian filter abilities will provide a spam solution that learns what to allow and not allow based on the use. This would be the ultimate in a self learning spam filter solution. 

If you didn't combine this into the main product the outbound relay component could be just a very simple routing engine that relays email. During that process is could extract the "to" email, and perhaps even do a "good bayesian" token on it? 

I did move one customer from GFI's spam killer to Spam Filter and GFI had this feature. I  don't like how GFI intertwines itself into my Exchange servers. When it messes up it takes my mail server with it. I never have that problem with Spam Filter <g>.

bill

Thanks for considering my idea.

1) As an alternative, you could create a seperate data collection applet that would reside on the outgoing mail gateway or the email server itself that simply collects the outgoing data and fills the shared database.  The flipside would be increased network traffic instead of server load on the SF server.

2) Yes that could be a drawback if you users respond to spam.  It seems to me that spammers that list an opt-out address tend to use either a false one (fake or spoofed) or use a temporary one for data collection.  Others will simply take you to a website to collect your confirmed valid address.  But for the most part it seems that they use a different address for every batch of spam they send out and it tends to not match the fake/spoofed/data collection address they offer for opting out.  I guess it would take a real analysis of a batch of spam to get a real feel for whether the address given for response ever match the "From" of other spam.

And also if the users have recieved the spam to respond to in the first place then the spammer has already been able to get past your filtering and it is up to the admin to figure out why.

But I think that if you give the admin enough control over expiration of these temporary whitelist passes they can narrow the window of opportunity for the spammers to re-use a response address as a "From" in another batch of spam so it fits .  Some may never run across it while others may have to bypass this whitelist feature.

Finally simple education is still the best prevention.  After years of our training our users not to respond to opt-out's, the rediculous Can-Spam Act tells them to do so.  I still maintain a do not opt out stance with our users.