Over the years I've made a number of minor changes to my copies of qpsmtpd
to do a little more, or perhaps more specific, logging for my own
purposes. For instance, I added a logging line to the respond() method so
I can see half of the SMTP conversation which is more useful to me as a
mail administrator than the default logging which appears more developer
based. I have augmented many of the plugins so they return DENY_DISCONNECT
and log accordingly as well (I'm a BOFH/anti-spammer. Discussions of the
propriety of my disconnects with respect to RFCs will be piped to
/dev/null.) I wrote scripts that later parse these logs to give me some
rudimentary stats on how many messages were accepted or blocked and why.
Anyway, one thing that never gets properly logged is a poorly cancelled
transaction. From time to time I see SPAM flurries where anywhere from
50-100 hosts will start banging at my SMTP server trying to do their
thing. Many of these get caught by check_earlytalker and other stock
plugins, many others by my own 'hnbl' (blocks based on reverse DNS
regex's). But a LARGE number of these incoming spammers send a EHLO and
then disconnect as soon as I respond with the ESMTP capabilities. They do
not send a QUIT so I never even see my 221 which would properly end the
conversation.
Can anyone give me some ideas on how I could implement some code whereby
if the connection is severed prior to an official disconnect (via QUIT or
DENY_DISCONNECT or similar device) that the incident gets properly logged?
I find it very frustrating to try to do stats when there are so many
connections that neither fail nor succeed...
TIA
-f
- logging incomplete transactions frank
-
