Hi
Reconnecting to the same process seems to work ok. I guess the problem
from the imap-code is not present here (or not expressed like it is in
the imap-server).
And Aaron, what's the problem with your postfix and dbmail-lmtp? Have
you made the right entry in main.cf:
dbmail-lmtp unix - - n - - lmtp
and transport:
test01.office.fastxs.net dbmail-lmtp:localhost:10024
where in my case, all mail to the test01.office.fastxs.net is
transported to a dbmail-lmtp daemon on port 10024 on the localhost.
Ilja
Paul J Stevens wrote:
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.
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.
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 ?
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!
