Bugtraq mailing list archives

Re: sendmail 8.9.3 patches to curb RCPT harvesters


From: avarvit () CC ECE NTUA GR (Aggelos P. Varvitsiotis)
Date: Mon, 15 Mar 1999 16:22:14 +0200


Per Joseph's suggestion. Use these patches against sendmail 8.9.3 and add

O RCPTFailDelay=30

to sendmail.cf to make sendmail sleep() for 30 seconds before reporting any
"550" errors. Set the value to 0 for "normal"  behavior.

According to the reports I'm seeing, GeoList Pro does not wait for a
response from the server -- instead, it streams the RCPT TO commands
continuously and then reads the results at the end of transmission.
If that is the case, it doesn't sound like this patch will have any
effect.

     It should work fine, because (1) sendmail won't process anything while
it's sleep()ing, and (2) GeoList will stop sending data when the socket
buffer fills up (because sendmail isn't reading from it).

A default TCP socket's receive buffer may allow a sender to queue up to
e.g. 8K of data (which is quite a lot of 'RCPT TO:'s). Thus, a probing
tool can e.g. queue about 500 RCPT TO's, then go to sleep or open another
connection. A more appropriate method would be to attempt to block the
sending tool's TCP by reducing the socket receive buffer size to zero or
to a very small value while sendmail is sleep(2)ing.

Normally, the next ACK sent by the receiver's TCP (sendmail) would then
present the sender (probing tool) with a zero receiver's window size, which
would oblige the sender TCP to queue all subsequent writes until after the
sleep(2) (and perhaps would also cause the probing tool to block).

To be effective, this method should be proactive. It doesn't make any
difference if the receiver's window size is e.g. 8K at the time when
the first RCPT TO is expected. A moderate (e.g. 512 bytes) window size
at that point of the SMTP conversation would allow all legitimate senders
to send one valid RCPT TO (with irrationally large destination addresses
perhaps requiring a second packet), and at the same time would prevent
probing tools from queueing up a large number of RCPT TO's.

a.varvitsiotis () iccs ntua gr                  A.Varvitsiotis
                                             ICCS Computer Center
                                      National Technical University of Athens



Current thread: