Fixing ORBS, and spam-proofing open relays.

[Trei, Peter]

Eric Murray [mailto:ericm at 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