Hey, you're not Ilja! :-P More inline... Paul J Stevens <[EMAIL PROTECTED]> said: > > Aaron Stone wrote: > > Ilja, > > > > I still can't seem to get my Postfix talking to the LMTP daemon :-( > > Something that I had never specifically tested, though, is what happens > > when you connect to the same process that you'd previously connected to > > and closed? > > This sounds alot like the problems I have with the imap networking code.
There seems to be an underlying issue in the design philosophy; everything works once, and may work twice when the client cleans up after themselves, but very often with servers like these, the code needs to be able to recover from an explosion of garbage data or dropped connection at *any and every point*. I have a feeling that we won't be able to easily introduce weird-error handling code into the servers without a general refactoring of the server daemon code... which is something that we definitely need to do anyways, since we now have three copies of a lot of the files, for pop3d, imapd and lmtpd. > > > Looking at the output and reading over the code again led me to believe > > that some data might have been hanging around after the end of a > > connection only to haunt the next connection. This should now be cleaned > > up. > > I know for a fact that the imap code doesn't properly close connections > when a client issues a tcp-close. I'm guessing the same problems may > well infect the lmtp code. Right, the close is handled at a different layer and I don't think that from that layer any calls are made into the protocol handler to tell it to clean up and reset its state. > > > > > I have not tried delivering a message, then waiting for a timeout, then > > trying again. My hunch is that a call to lmtp_reset() needs to be made > > from the timeout alarm signal handler... > > Sounds like a hack to me that doesn't address the underlying problem. > Assuming of course lmtpd behaves like imapd wrt networking. Could you > run a tcpdump of such a session, and post the results ? > At the very least, it's a hack in the right direction / with the right philosophy of aggressively cleaning up after each session, regardless of whether or not the client issued any RSET or QUIT commands to cause an explicit cleanup. > > > I won't be up tonight, so I hope that this might be the clue you need > > to fix this bug and clear the way for 2.0rc3. Best of luck! > > > > -- > ________________________________________________________________ > Paul Stevens mailto:[EMAIL PROTECTED] > NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] > The Netherlands________________________________http://www.nfg.nl > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
