[tpop3d-discuss] tpop3d 1.5.1pre2 (with TLS support)

Angel Marin anmar at gmx.net
Mon, 11 Nov 2002 22:05:58 +0100


> -----Mensaje original-----
>
> On Mon, Nov 11, 2002 at 09:44:04AM +0100, Angel Marin wrote:
> > While downloading more than 100 messages at a time with MS outlook the
> > connection gets a reset at after succefully downloading some of
> them. The
> > log entries are:
> >
> > [...]
> > Nov 11 09:21:45 falcone tpop3d[6490]: maildir_send_message:
> sending message
> > 422 (cur/1036960375) size 8081 bytes
> > Nov 11 09:21:45 falcone tpop3d[6490]: ioabs_tls_immediate_write: client
> > [7]user@foo(x.x.x.x): Connection reset by peer; closing connection
> > Nov 11 09:21:45 falcone tpop3d[6490]: connection_sendmessage:
> send failure
> > Nov 11 09:21:45 falcone tpop3d[6490]: connections_post_select: client
> > [7]user@foo(x.x.x.x): finished session for `user@foo' with flatfile
> > Nov 11 09:21:45 falcone tpop3d[6490]: connections_post_select: client
> > [7]user@foo(x.x.x.x): disconnected; 330/138591 bytes read/written
> > [...]
>
> That's wierd. I don't fully understand the TLS stuff. With
> Outlook Express, I can download messages fine (though it's
> a bit slow). With Mozilla, it works most of the time, but
> sometimes gives me a `bad write retry' error. I don't see
> why this should happen, since I think I got the TLS state
> machine right. What a pain....

I think there are many underlying bugs in openssl library when implemented
on a non blocking way. Openssl only works as spected if you fork on connect
and use blocking IO otherwise I always got weird results. May be GNU TLS is
a better option ? But I don't know how mature it is.

> You don't know of any client which uses STLS, do you?
> That's not tested at all....

No I'm sorry.

> > With other clients I get this while checking mail or
> downloading a message
> > (This happens with several clients, local and remote):
> >
> > [...]
> > Nov 11 09:21:48 falcone tpop3d[6491]: quit: signal 11 post_fork = 1
> > Nov 11 09:21:48 falcone tpop3d[30332]: net_loop: child process
> 6491 killed
> > by signal 11 (shouldn't h
> > appen)
> > [...]
> >
> > I cannot debug this as I have switched again to stunnel after
> an hour try,
> > but it seems that something is broken :(
>
> That one's now fixed-- I'd managed to break the DELE
> command when refactoring. (Test the code? Nah, this is a
> prerelease.) The fix is in CVS.


I'll give It a try tomorrow morning on my next maintenance window.

Angel.