Just for fun, here's another aspect of the truth. Some thoughts from the view point of a systems administrator who deals with large environments:
> Normally the blacklisted servers are open relays, and having such servers is bad for everyone.
Uncontroled relays of any kind are bad. One issue that always seems to be overloaded however is the case of dial-up resellers. Consider that most, if not all of the nationwide ISPs in the United States buy dial-up capacity from companies like Level3 and UUNet.
Often, due to lack of good technology to deal with the situation, such ISPs end up having to allow relay from network blocks owned by the third party providers.
The result is of course, is that sometimes an ISP will have to allow relay based on IP, rather than based on a certain knowledge of who the person using that IP is. It's not a situation that most ISPs like, but it's one that many are stuck with. Authenticated SMTP, where the email client persents a username and password in order to be granted relay priveleges can help solve this issue, but it's not widely used yet, and I'm uncertain how well older email clients support it.
> Also, blacklists don't block email, system administrators do
Systems administrators, in my mind, have no bussiness blocking email from servers that haven't been abusive to them personally. As you comment, headers can be modified so that users can easily have their mail programs sort their mail based on that information. This puts the users in control.
Systems administrators are affected by abusive servers, but only because those abusive servers are causing technical problems. Systems administrators can control that. Users can be affected two different ways; they can risk seeing spam, or they can risk not seeing email that's important to them. If the ISP is using blacklists, particularly blacklists that they don't control, then the user has no control at all, other than having the choice to try a different ISP.
I feel an ISP has an obligation to the users do it's best to keep the situation in balance. This means blocking servers that the ISP can prove are being knowingly abusive, and servers that are being abused. This also means that as much as possible, the choice should be in the hands of the users.
> a blacklist only gives you a normally good information about how much you can trust in mail that comes from certain servers
If all blacklists were certain to give "normally good information", the situation would be much better. I don't dislike the idea of shared blacklists, as long as I know that I can trust the content of those lists. All the of blacklists I've ppersonally seen or dealt with can be shown to list servers for reasons that are not commonly agreed on as being "bad".
As an example, certain blacklists have had what I consider a nasty habit of, when finding an open relay that itself relayed mail through another server (a good example is someone with a DSL line who is running a local mail server that then uses the ISPs mail server for delivery), those blacklists would block both the open relay and the ISP's mail server.
The ISP did nothing wrong, there's nothing wrong with any of the ISP's systems that it owns, controls or operates, but it still can find it's entire relay farm on a blacklist because of a single user with a badly configured machine. Of course, when the ISP's systems administrators notice, or are notified that the user has an open relay issue, the ISP needs to take, particularly if it's already being abused.
What's worse is that those running blacklists often have no commitment or even desire to contact the Systems Administrators in question before creating the listing. In the case above, a simple email to the ISPs Systems Administrators might have fixed the problem. (It also might not fix the problem, at which point, I'd feel that listing the open relay itself would be acceptable.)
> Also, getting off, for well configured servers, should not be so hard.
Sometimes it is, and sometimes it isn't. There can be great differences of opinion about what is and is not well configured. For example, certain blacklists have traditionally been very unforgiving of the case of having to relay for IP ranges because of the need for third party dial-up resellers.
There's also a question of what a well configured blacklist should do. If it's an actively scanning blacklist like ORBZ was, it should respect you if you ask it to bugger off and stop checking your network blocks. (There could be a lot of reasons for this, including the case of poorly writen servers that can't survive the checks.) The blacklist certainly should not blacklist the entire network in retaliation.
A well run blacklist should always attempt to make contact with the Systems administrators in question, and make the record of attempts public, to avoid any questions of if they really did try or not. I've seen situations where the blacklist claimed to have attempted contact, but where the other party claimed that they were never contacted. The blacklist was unable to dig up anything as simple as even a log saying "here's when we tried to make contact, how we tried, and what happened". This damaged the case for me ever trusting that blacklist again.
A well run blacklist should be intellegent. It's rather annoying to work with a blacklist to get a server off the list due to a mis-detection, only to find a few weeks later that it's been added to the list again, because of the exact same mis-detection as the last time.
Going back to the prior example of an ISP that needs to use third party dial-up resellers, doing relay tests on a mail server, from an IP address that is supposed to be allowed to relay through that mail server is a fairly obvious error, once it's pointed out that the IP address in question is in the mail server's access list.
In the end, I feel that unless the ISP can be very certain of the quality of the blacklist in question, the choice should be in the hands of the users.
In summary, I feel that well run blacklists that have a commitment to quality, communication, understanding and accuracy can be very useful to both users and Systems administrators. Sadly, I don't know of any blacklists that I trust right now. I'm not even sure that blacklists are really the correct solution. I've been playing with per-message based anti-spam systems lately, and I think that the future of spam fighting could be there.
may have a lot of potential in that regard. DCC servers work based on distributed, somewhat "fuzzy" checksums. As long as only real spam is submitted to a DCC server, it's content should be quite trustworthy.
If I had the bandwidth, and a domain that would get a lot of spammers doing dictionary based spamming attacks against it, I'd be tempted to build a spam trap with it, and feed the spam traps into a DCC server that accepted new checksum only from the spam trap system, but would openly share it's checksums with anyone.
[ Parent ]