Bug 219762 - Sendmail's rate throttling module does not work
Summary: Sendmail's rate throttling module does not work
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sendmail   
(Show other bugs)
Version: 4.4
Hardware: All Linux
medium
high
Target Milestone: ---
: ---
Assignee: Thomas Woerner
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
: 219763 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-15 08:33 UTC by David Herselman
Modified: 2008-08-26 13:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-26 13:32:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1170156 None None None Never

Description David Herselman 2006-12-15 08:33:44 UTC
Description of problem:
  We need to implement Sendmail's rate throttling module to automatically
  reject hosts which get infected by viruses or spambots. Sendmail does
  provide for this in the form of the 'ratecontrol' and 'conncontrol'
  modules but they are not working.

  Documentation on these modules is available in /usr/share/sendmail-cf/README


Version-Release number of selected component (if applicable):
  8.13.1-3.RHEL4.5


How reproducible:
  Always


Steps to Reproduce:
  1. Add lines to /etc/mail/sendmail.mc (after 'FEATURE(access_db):
    dnl # Limit machines sending viruses
    define(`confCONNECTION_RATE_WINDOW_SIZE', `600s')dnl
    FEATURE(`greet_pause', `2000')dnl
    FEATURE(`ratecontrol')dnl
    FEATURE(`conncontrol')dnl
  2. Add lines to /etc/mail/access:
    GreetPause:127.0.0.1     0
    ClientConn:127.0.0.1     0
    ClientConn:10.0          5
    ClientConn:192.168       5
    ClientConn:              50
    ClientRate:127.0.0.1     0
    ClientRate:10.0          10
    ClientRate:192.168       10
    ClientRate:              100
  3. Rebuild configuration files and restart sendmail:
    make -C/etc/mail
    m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
    service sendmail restart

  
Actual results:
  We've unfortunately just been blacklisted due to a user's machine being
  infected by a spambot which sent out over 16,000 messages over a two hour
  window.


Expected results:
  The configuration above should automatically limit clients when sending
  more than 10 emails within 600 seconds (10 minutes) when the connection
  originates from the 192.168.0.0/16 or 10.0.0.0/16 subnets.



Additional info:

Comment 1 Thomas Woerner 2007-03-08 13:38:22 UTC
*** Bug 219763 has been marked as a duplicate of this bug. ***

Comment 2 Thomas Woerner 2007-10-22 15:47:35 UTC
What exactly happens with this configuration? Is there a limit at all?

Comment 3 Thomas Woerner 2007-10-22 16:01:36 UTC
The feature delay_checks is missing in your configuration. Are you sure, that
you were able to generate a working configuration? Trying to apply your changes
results in an error message.

Please have a look at http://www.technoids.org/dossed.html. There you can get
very good descriptions for rate control etc.

Comment 4 Phil Knirsch 2008-08-26 13:32:21 UTC
This request was evaluated by Red Hat Engineering for inclusion in a Red
Hat Enterprise Linux maintenance release.

As this bug has been in NEEDINFO for an extended period of time we are going
to close this bug due to inactivity. If you would like to persue this
matter feel free to reopen this bug and attach the needed information.

With the goal of minimizing risk of change for deployed systems, and in
response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating enhancements for inclusion in maintenance updates
for currently deployed products. The primary objectives of update releases
are to enable new hardware platform support and to resolve critical
defects.

However, Red Hat will further review this request for potential inclusion
in future major releases of Red Hat Enterprise Linux.


Note You need to log in before you can comment on or make changes to this bug.