[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: smtpserver message-rate-counter (ratelimitmsgs policy)



Too bad that this approach is not cluster-ready...

On Thu, 2004-04-08 at 23:08, Matti Aarnio wrote:
> Now IF your system support command line mungling (in BSDish way), you
> might see following kind of things:   ( Linux system with: "ps axf" )
> 
>   879 ?        S      0:00 smtpserver -s strict -h -s ve -l /var/log/mai..
>   882 ?        S      0:00  \_  [smtpserver ratetracker subsystem]         
>   883 ?        S      0:00  \_  [smtpserver router subsystem]              
>   884 ?        S      0:00  \_  [smtpserver contentfilter subsystem]       
>   885 ?        Z      0:00      \_ [smtp-contentfil <defunct>]
> 
> For systems where this nice textform thing isn't possible,
> the  'mailq -M' command lists PIDs for those processes:
>   SYS.SmtpServerMasterPID                879
>   SS.SubsysRateTrackerPID                882
>   SS.SubsysRouterMasterPID               883
>   SS.SubsysContentfilterMasterPID        884
> 
> 
> Of those subsystems, only 'ratetracker' really works at the moment.
> It keeps everything in memory, so when I ask it to dump internal
> memory content, I get something like this:  (Filename is fixed.)
> 
> # kill -USR1 31800
> # sort /var/tmp/smtpserver-ratetracker.dump |uniq -c
>     999 0.0.0.0
>       1 67.72.78.212    0     9     21    0     0     0     0     0     
> 
> Data slots are allocated in slabs of 1000, therefore this dump has
> 999 examples of '0.0.0.0'.  When first 1000 are in use, next slab
> gets allocated, etc.
> 
> The numbers above after the IP address (oh yes, only IPv4 is
> supported with the code at present, IPv6 needs some further
> thought..) are number of messages received from that address.
> The message count is kept in 8 rotating timeslots, about 510-520
> seconds each giving total time around  1.00 - 1.14 hours which
> the message count exists for given sender IP address.
> 
> The tracking idea here is, that each message accepted into the
> system does get counted as one, and when there are too many messages,
> the system is replying following for MAIL FROM:
>    450 4.7.1 Hello [67.72.78.212], for your MAIL FROM address <****@*****>
>        policy analysis reported: You are sending too much mail per time
>        interval.  Try again latter.
> 
> 
> The count is tracked only for those message senders, that have in the
> initial contact IP address lookup an attribute pair of:
>       ratelimitmsgs 60
> 
> When the number is NEGATIVE, limit excess will result in 550 code
> for MAIL FROM, otherwise a 450 code reply is given.
> (The example number above is "60", meaning about 1 message per minute
> over whole 1.0-1.2 hour period..  or 60 in first minute, and none
> for next hour...)
> 
> The smtpserver policy boilerplate file  (smtp-policy.src)  does not
> have any nicely compartementalized way to handle the rate limiting
> parameter entry.  I had to add that pair into  _full_rights  macro
> values in my tests.
> 
> The overall idea in here is that you can give blanket rate limit to
> all users for whom you are doing outbound relaying without those
> users needing to authenticate.  (Autenticated users bypass these
> tests.)
> 
> If you want to rate-limit ALL incoming email, then you want probably
> to put this attribute both on _default_ipaddr,  and _full_rights
> macroes.  (The 'default-ipaddr' thing was formerly the smtp-policy.src
> source line with:  [0.0.0.0]/0  )
> 
> For incoming traffic rate tracking also the recipient address is
> important to track.  Otherwise you may get nasty surprises with
> large volume (and subscriber population in your system) lists.
> Present system does not support that operational mode.

This is a digitally signed message part