On Fri, 11 Jul 2014 16:52:12 -0500 Noel Jones <njo...@megan.vbhcs.org> wrote: > But there's really only one scenario. The only time postfix logs > that message is when the connection is lost after RCPT. This is > always caused by either A) a poorly written mail engine that > improperly drops the connection, or B) a network problem.
But 'A' has subsets. I want to ask the question "Who connected, confirmed a valid address and disconnected without sending mail?" Is that an unreasonable question without needing to do stateful log analysis? It's not that I am a stranger to that sort of log analysis but the Postfix engine already has that information. All I am saying is that it would be nice if the lost connection message (or a separate message) made note of the status at the time of disconnection. Actually, a separate log entry makes sense because I want to know that information whether the connection was dropped properly or not. In other words, after a disconnect of any sort I want to know if the sender sent an invalid address, a valid one which it followed up with DATA or a valid one that it did not follow up. > Unfortunately, it's impossible to tell the difference from your end. > All postfix knows is the connection was lost unexpectedly, and it > would be improper to not log it. I understand that. In fact, I understand more about what gets logged now from this discussion which I thank you and others for. > You're focusing on what happens before the lost connection. That's a > job for log analysis tools. Which I was trying to avoid mainly because I analyze the logs every five minutes to see who to block. By the end of the day that gets very CPU intensive. I was hoping for a simple grep|sed solution. Maybe I need a single process that runs all day doing a tail -f on the log file. Hmm. I wonder if I can play games with syslogd so that mail logs go to maillog as well as a socket that I can read. I'll have to play with that. > Of course, the spamware writers could easily fix this little > artifact by sending QUIT after their payload is rejected rather than > just dropping the connection. They already know this. Apparently > (for now) they would rather save a few milliseconds and move on to > the next target. This is what I am worried about. Right now I am just counting dropped connections but that's not a long term solution. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
