Eric Murray [mailto:ericm@lne.com] wrote:
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.
[..]
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.
That may be so, but I would have thought that ORBS could have usurped one of the many types of queries which DNS permits to package it's reputation data. [...]
-------------------
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.
I think you misunderstand SMTP (If not, please correct me. :-) If you look at RFC 821, section 3.1, you'll find that the RCPT TO: command takes only a single address; multiple addressees are handled by sending multiple RCPT TO: lines, and waiting for a 250 OK or a 550 Failure response after each one. My suggestion is that, on a given connection, an open relay server wait 10 seconds after before issuing a 250 OK response. This is too short to time out a client, but slows the process down greatly for messages with multiple recipients. Yes, you couldn't spam your entire company's internal mail from an open server in this manner, but you usually would do this by sending to a single address which runs a mail exploder within the company. Nor does it protect against spammers sending messages to hundreds via mailing lists such as cypherpunks. However, it would permit open relays to exist without them adding significantly to the spam problem, which is the problem I am trying to solve. In my initial letter, I suggested delaying response only after the second RCPT message, but on second thought, I think delaying after the first one is ok. For single messages, you would not be bothered by a 10 second delay. and it prevents the spammer from opening hundreds to connections at once to get around the restriction.
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.
I'll admit that was an off-the-cuff remark, and I'd have to think hard to find other ways. OTOH, I'm sure there are many. I'm not trying to identify spam per se; I'm trying to make the relay unattractive to spammers, while minimally impacting everyone else. I'm working at the SMTP protocol level, not envelope, headers, or content. I'm impacting behaviour, not content or header info.
Eric
Peter Trei