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 184.108.40.206 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 [220.127.116.11], 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