It takes a lot of effort to identify IP blocks for white, gray and black lists. I've seen some people include whole class C's without seemingly verifying that they were all under the control of one party. It seems that the SBL type spammer is now using only partial blocks and in researching that Pexicom spammer, I found blocks that were definitely shared with other companies (which is a shame).
I've considered creating a tool for automating the maintenance of my own blacklists. In part, it would allow me to submit IP's that I considered spam to a database where they would be time stamped. I would also look at blocked messages and build some intelligence that would qualify blocks as some RBL's do, this way I wouldn't take additional action on just one IP because it might be a false positive, but two, three, four, etc., IP's from the same block is a sign of a static spammer, and time stamps could be used to verify continued activity so that they could be automatically expired after some point. The gathering of this automated information could be done fairly easily with IMail's program alias with a ROUTETO or COPYTO action instead of using DELETE or HOLD. If I could write this information to IMail's access control file, all the better, but then of course I would also have to process IMail's SMTP logs for activity, but at least this could be used with SKIPIFWEIGHT to save on processing with Declude.
As far as whitelisting trusted bulk mailers goes, this would be process intensive and best done if shared. If a group of people could agree on a definition of spam and make nominations and then do the work of identifying the IP's (which is more useful than reverse DNS since unique domains are being registered for such uses), then this would be a virtually spoof-proof way of allowing such traffic on your server. You could also differentiate between what is purely white, such as Ebay notifications and what is gray such as commercial ad related content sent to members, then you could build two lists simultaneously and allow administrators to block the gray stuff per domain with an action for the test in which it is defined.
When it comes to whitelisting ISP mail servers, I don't believe we have the necessary tools to make the most out of this. Spam does get sent through these mail servers, but they also are very problematic when it comes to being blocked by RBL's. It would be great if a list could be generated of ISP mail server IP's which could then be used by Declude to turn off the RBL's but still take action on technical filters and custom filters. It wouldn't take a very large group to come up with something that would cover 80% or more of ISP mail server traffic.
I'm not sure that Web-o-Trust allows for the flexibility to be defined in so many different ways, nor do I believe that such a process is necessary. This could be set up as an automated download from a network of servers maintained from a private master database where each public server advertises peers in the network (making it DOS-proof). The programming is also quite simple. The hard part is choosing people to do this work who can agree and be responsible.
I only mention this because of the current discussion. I can't fathom having any time to explore this idea in reality until February at the earliest, but I definitely see myself doing at least part of it as a way to reduce the administration of my system.
Any thoughts?
Matt
R. Scott Perry wrote:
I think the attempt is admirable, as it is with the RBL's and anyone else that contributes to the "greater good," however I strongly believe that the approach is flawed. I've had similar discussions regarding shared blacklists and the same issue comes up over and over again...there needs to be some form of unautomated management and an enforceable standard for something like this to work.
I checked out the limited number of submissions to that list and found the following file for instance:
http://home.teleport.com/~amurph/web-o-trust.txt
This file lists blocks containing Comcast and Earthlink mail servers.
I'm guessing that they were added because they have troubles with spam filters, and aren't going to be sending out spam. Do you have a record of spam from those IPs?
In this case, though, if you're unsure that you can trust them, you can use "omit: http://home.teleport.com/~amurph/web-o-trust.txt";.
It also includes the following list:
http://users.adelphia.net/~equalizer/web-o-trust.txt
This one contains addresses on Road Runner, Adelphia and three educational institutions, and this out of only the first 100 or so members.
But, why shouldn't those IPs be listed? It looks like they are being listed for a good reason.
What's to stop me or someone else from having an epiphany and using this as my pseudo-whitelist all of a sudden and including places like Cheetah Mail and Dart Mail? Some here consider that to be spam.
In that case, you'll likely get limited. For example, we could put a "1" after your URL, so that people trusting us would only trust your IPs, not those of people that you trust (or if you put the actual IPs for Cheetah Mail and Dart Mail, we could remove your entry).
It seems like this would present more trouble than problems fixed.
It could be. But only time will tell how it will really work out.
Sure, I don't need to trust this person, or who they trust, but I also don't want to have to spend the time figuring out if someone currently has a very poor understanding of whitelisting, or may at any time in the future have a brain fart and start including the IP addresses of ISP's where the users themselves, trustworthy or not, can be infected with viruses and haplessly become open relays. This in itself is the #1 problem in spam fighting currently.
I think the goal here is for those people to be far enough down the ladder that limiting your trust would fix it.
It's the folks that don't own their IP space that are the hardest to block, and these are the same guys that won't be discouraged by the Can Spam laws because they are already criminals. Such a network and registry if successful, also presents a large potential issue when compromised and targeted...the map to the network is there for spoiling.
True. But, it's going to be a major undertaking for little benefit. So they manage to get a few IPs in? They have to quickly send out spam before those IPs get removed. But even so, they don't know how many people are trusting them.
Perhaps we can build something in where people don't get trusted until their WOT files have been active for X hours/days, allowing time for others with more time to omit them if needed. :)
Sorry to be so negative about the idea, but if it was all just this simple, we wouldn't have a spam problem in the first place.
But, the idea hasn't been put through the paces yet.
Another idea is that if it is limited so that you can only add your own IPs, it may be more useful (so that the clueless admin can't just add Cheetah Mail and Dart Mail).
In the current suggested implementation, I just don't see the value as a whitelist of places that I'm pretty sure wouldn't have any problems to begin with.
Like us? We don't have anything that I consider a problem -- no spam has ever been sent from our mailserver, and there isn't any indicate that there will. But quite a few of Len's followers have blocked us. And for a few hours when EASYNET-DYNA added us, there were some people blocking just on that. Those people would *really* benefit from WOT -- which then benefits anyone who uses WOT.
Maybe it might be useful to have a conversation about alternative uses for such a program? I'm definitely interested in sharing some whitelists and blacklists based on the above stated criteria, but only if we could all agree on definitions, processes, and can be responsible.
That's not an alternate use -- that's an intended use. :)
There is nothing saying that everybody should be included in WOT, or that you should trust someone like us. If that works for you, great. If not, it's quite possible to start a WOT specific to certain uses.
I hadn't even thought of blacklists, but that would work too (just so long as they were handled carefully, so that whitelists and blacklists didn't accidentally include each other!).
-Scott
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
