> >> 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.varvitsiotisat_private A.Varvitsiotis ICCS Computer Center National Technical University of Athens
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:39:07 PDT