[9935] in bugtraq
Re: sendmail 8.9.3 patches to curb RCPT harvesters
daemon@ATHENA.MIT.EDU (Aggelos P. Varvitsiotis)
Tue Mar 16 16:54:19 1999
Date: Mon, 15 Mar 1999 16:22:14 +0200
Reply-To: "Aggelos P. Varvitsiotis" <avarvit@CC.ECE.NTUA.GR>
From: "Aggelos P. Varvitsiotis" <avarvit@CC.ECE.NTUA.GR>
X-To: achurch@DRAGONFIRE.NET
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <36ea9410.17602@crystal.dragonfire.net> from "Andy Church" at Mar
13, 99 11:36:32 am
> >> 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
