Today our system decided that AOL was on 10 SFDB's. I guess the question would be what protections are there in place to protect from a large mail vendor from making it on these databases. Putting AOL on these lists seems a little extreme, and our users a little more then unhappy.

 

10/10/06 13:39:12:173 -- (10208) Connection from: 205.188.139.137  -  Originating country : United States

10/10/06 13:39:12:984 -- (10208) Resolving 205.188.139.137 - imo-d23.mx.aol.com

10/10/06 13:39:13:281 -- (10208) - SFDB filter match - relevance:10

10/10/06 13:39:13:281 -- (10208) 205.188.139.137 - Mail from: XXXX@aol.com To: XXXX@lasvegasnevada.gov will be rejected

10/10/06 13:39:13:796 -- (10208) Blacklist cache - Added 205.188.139.137 to limbo

10/10/06 13:39:13:796 -- (10208) Disconnect

 

Scott,

That particular IP has (and still is) been sending spam/viruses all day, and thus will remain listed in the SFDB until it stops. Please also note that there are currently several other RBL MAPS servers that are listing the same IP.

We do not make any exceptions for the SFDB, even our own mail server was listed in the SFDB once (rightfully so....). Doing so would require us to decide who's a "priviledged" provider that gets away with sending spam and who isn't, and is bound to make quite a few people/companies unhappy. By making the rules the same for everyone, we level the playing field, and all companies will share the same responibilities in ensuring their systems do not send spam/viruses.

SpamFilter users are then left with the decision of whether they want to whitelist major providers or not, as some admins may have your same thoughts (AOL must be allowed to send emails), but others instead will want their system to reject all emails from that AOL's IP as it's sending them spam. Please remember that the IP ended up in the SFDB because multiple companies using SpamFilter are receiving spam from it, not just legitimate emails.

I guess I'm unclear on how exactly these address get registered in the SFDB. I read the "Information for administrators" and as near as I can tell one message considered spam by SpamfilterISP causes it’s IP to be registered it with the SFDB database. If that is the case given the volume of messages from the AOLs of the world it's quite likely that the false positives may adversely effect mail delivery for those companies, thus an unequal and biased treatment against them. Your large mail providers have safe guards and TOS policies in place that make spam from their company far less likely. We rarely find true Spam from these companies typically either they are from spoofed address or just plain made up domains. Is the system taking into consideration the volume of mail to Spam ratio? As it stands now I have been forced to disable SFDB altogether. Also, as an administrator I find that I need to have a tool to look up an address to see why it’s block, since I’m placed in a position of explaining these delivery issues to our users.