[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
smtpserver message-rate-counter (ratelimitmsgs policy)
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:
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
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:
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
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.
/Matti Aarnio <email@example.com>
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to firstname.lastname@example.org