Mailing List Archive

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!



--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl

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!
>
>
>
>

Ok, nevermind, it must be a broken mail client... I just spoke with Postfix
via 'telnet localhost 25' and my message was inserted properly via lmtp :-)

Aaron


Ilja Booij <ilja@ic-s.nl> said:

> 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!
> >
> >
> >
> >
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

Hey, you're not Ilja! :-P More inline...

Paul J Stevens <paul@nfg.nl> 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:paul@nfg.nl
> NET FACILITIES GROUP PGP: finger paul@nfg.nl
> The Netherlands________________________________http://www.nfg.nl
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--