On Fri, Sep 05, 2003 at 01:26:30AM -0700, Ask Bj�rn Hansen wrote:
> Oh man, usually my qpsmtpd log streams by too fast to keep up. (We
> really should have it make a sendmail style log).
>
> Robert thought of grep'ing for just the return codes, like
>
> tail -f ~smtpd/qpsmtpd/log/main/current | egrep '
> [45][[:digit:]][[:digit:]] | 250 Q'
>
> The sad output of ~45 seconds in the middle of the night here is below.
> (Yes, I just started blocking people who keep sending "Incomplete
> DATA" as well).
for lists.mysql.com, since 2003-08-31 01:03:40:
* 794231 connections
* 279531 connections denied by a plugin
* 488970 transactions
* 449912 transactions denied by a plugin
that doesn't account for the connections rejected by tcpserver. (there
have also been chunks of downtime in there.)
that's probably not a terribly significant amount of incoming traffic
compared to what others may be seeing, but this is for a server that
only handles mailing lists: the incoming traffic should be pretty tiny.
certainly not the peaks of four connections per second i'm seeing.
i switched to using PPerl, which helped the load average, but it got
stuck overnight and i had to kill a single qpsmtpd process to get things
going again. i'll try to figure out what caused it to get stuck if it
happens again.
oh, a breakdown of denials by plugin:
check_badbounceto | 168200
check_badheader | 21844
check_badmailfrom | 34362
check_badrcptto | 16554
check_earlytalker | 36404
check_relay | 463
check_spamhelo | 38
count_unrecognized_commands | 32
dnsbl | 240065
klez_filter | 2307
reject_strange_quit | 59018
rhsbl | 42993
sender_permitted_from | 121
spamassassin | 2414
strange_quit | 105807
virus_sobig | 2217
('strange_quit' means one of those 'DATA\r\nQUIT\r\n' things was
noticed, 'reject_strange_quit' is a plugin that rejects connections from
those in the time between cron runs that rebuilds the tcpserver rules
database.)
a few things i'm planning to do --
* collect/graph the number of incoming connections being handled (it
looks to me like the server is pretty much keeping at its configured
maximum)
* collect/graph the connection info from tcpserver, not just what makes
it to qpsmtpd
* be more aggressive in blocking connections at the tcpserver level
based on noticed behavior
five days until sobig.f turns itself off. it will be interesting to see
how things change, if at all, when that happens.
jim
