On Sun, Aug 01, 2004 at 03:02:19PM +0100, Mark Powell wrote: > Isn't that what qpsmtpd is doing? Just delaying the failure allows the > other to do it's logging?
No, the trouble is that qpsmtpd didn't log its connections. Instead, if your loglevel set high enough to get the SMTP conversation logged, you'd get the remote IP from the HELO (or possibly from tcpserver). Since the greeting is the first order of business it wasn't a big deal, but it was still happening uncomfortably late when we're looking at detection methods that preceede the greeting. Besides some of your patch, yesterday I also checked in a one-liner that gives us that logging -- the first thing that qpsmtpd emits on startup now resembles: Aug 1 14:58:01 atlantic qmail-smtpd: 14400 Connection from [127.0.0.1] [127.0.0.1] > Looks like we have a crossed purpose on this one. As I said, it makes my > life much easier when investigating user's complaints if I have extra > logging info. I still run qpsmtpd at the debug level. I planned to turn it > down after a while, but there is always useful info there which allows me > to make a better decision on what happened. Each of our relays is > producing almost 1GB of logging info per day (the vast majority of it > qpsmtpd), but the disk and cpu load of all that logging and those > connections staying around a little longer than they could is still > acceptable. Logging is cheap (just ask my employers :)). I run at LOGINFO rather than LOGDEBUG, but I do habitually patch things to log the entire SMTP conversation. Hopefully one of us will get around to log classing or channelling or bitmasks or another approach to let folks enable logging of various kinds of events rather than just using levels, so one could say "I want the SMTP dialogue, and also the info-level notices from plugins, but don't bother me telling me what plugins are getting loaded every time." -- Devin \ aqua(at)devin.com, 1024D/E9ABFCD2; http://www.devin.com Carraway \ IRC: Requiem GCS/CC/L s-:--- !a !tv C++++$ ULB+++$ O+@ P L+++
