On Wed, Jun 13, 2001 at 10:28:55AM -0400, Trei, Peter wrote:
Instead of bitching about ORBS (which certainly behaves sub-optimally), I'd like to suggest that we discuss how a 'better' spam blocklist could be operated.
Who knows - maybe someone could set one up to follow good practices. Under the right circumstances, high-quality information can drive out bad.
[For the record, I'm not as exercised about email spam as are many people - it takes me less time each day to trash the electronic junk mail than it does to sort out the paper kind, despite an internet presence stretching back decades, and posting to both mailing lists and Usenet with my real address. My main objection to spam is that I don't want sexually explicit email arriving in my 10 year old daughter's inbox].
I'd like to suggest that if ORBS gave a little more information about *why* a given site was listed, and sites where thus able to implement their own policies over what parts of the list to use, then that would be a far more equitable situation.
ORBS couldn't do this with any granularity because of the way it was implemented- you did a DNS lookup on the IP address to see if it was in the ORBS database. There was no meta-info available. They (MAPS) did have three different databases- one for open relays (ORBS), one listing addresses that are within an ISP's range of dialups (and which should have been using the ISP's mail servers to relay, not sending directly), and one other database that I can't remember at the moment (was it known spammers?). Using DNS for database lookups had some technical advantages- it's low bandwidth and caching was already built in to DNS. So for example a site like mine which has limited bandwidth (I live out in the woods) and does a lot of email could still do the various MAPS lookups without significantly increasing the traffic load. But that's not to say that a newer reputation system couldn't be designed and written to meet the same goals and include more info about why a site is on the list. However I think that the main problems with such a reputation system aren't technical, they're legal. At least in the U.S., such a system would be the subject of extreme legal harassment by spammers and their ilk, just as MAPS was.
-------------------
BTW, I expect that it should be possible to spam-proof an open relay, by tinkering very slightly with the protocol implementation.
For example: if a server required a 10 second pause between successive RCPT commands, then a message to a single recipient would pass without problems, but a spammer trying to send to many people would be blocked.
The benefit to the spammer of sending spam through a relay is that the spammer can multiply his bandwidth-- the spam will include many To: addresses in the envelope, so the relay has to do the work of sending out all the mail, not the spammer's machine. There may be hundreds of To: adresses in the envelope for each mail that the spammer sends to the relay. So this solution wouldn't work- it'll slow the spammer down only a little. You could restrict the number of To: addresses in the envelope, but that might also keep you from sending mail to an "all" alias at a company.
There are *many* other ways to tinker with the protocol implementations which would let legitimate users send mail without difficulty, using normal agents, but which would make the spammers' life far more difficult.
I'd like to hear some of them. I've been having a hard time coming up with ways to differentiate spam based on the header info. I've had more luck identifying spam based on the content. Eric