Tim Pierce wrote: > On Thu, Mar 11, 1999 at 07:31:21PM -0500, Peter W wrote: > > 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. (1) It will slow down your server's responses to GeoList, et al. Set the delay to 60 seconds and a 5000 word attack could take 83 hours to send the responses they need (assuming they don't run parallel attacks, and sendmail already has means to limit such attacks). (2) sendmail logs the RCPT failure notices via syslog as soon as it sends them to the client. Which is why I said the changes would "frustrate current RCPT abuse tools, give admins more time to notice the failures in the maillog and react". If the attacker thinks it's worthwhile to wait for the response codes, and you're not watching your log files, then you're right, these changes won't help you much. Also I said "current... tools" because a more intelligent harvester could compare the delay rates of "250" and "550" responses and learn when to time out and assume the RCPT failed. To get around this you'd need to make a simple change so that sendmail had a deliberate delay before *all* RCPT responses; that doesn't seem warranted yet, and would slow legitimate mail delivery. See my previous post for comments on RFC 1123 and deferring verification. -Peter -- Q: How could China track down and punish dissidents more effectively? A: The new Pentium III chip! http://www.privacy.org/bigbrotherinside/ Intel doesn't care about your privacy. Join the boycott today.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:39:04 PDT