sslio error description incomplete/wrong

I've been dabbling with using sslio to add STARTTLS functionality to Bruce
Guenter's imapfront-auth and have encountered some problems with SSL
negotiation, which took me a little too long to track down due to
misreporting by sslio.  Here's what I see in my log:

@4000000041d723651ff1e11c imapfront-auth[1412]: * OK imapfront ready.
@4000000041d723652000d924 imapfront-auth[1412]: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED 
@4000000041d7236520010034 imapfront-auth[1412]: 00000000 OK CAPABILITY completed
@4000000041d7236522107774 imapfront-auth[1412]: 00000001 OK Begin TLS negotiation now
@4000000041d7236526ef4edc sslio[1412]: info: read bytes: 88
@4000000041d7236526f9e9b4 sslio[1412]: info: sending ssl handshake response
@4000000041d7236526fb1294 sslio[1412]: info: write bytes: 1122
@4000000041d7236527035f94 sslio[1412]: info: read bytes: 7
@4000000041d723652704a3cc sslio[1412]: fatal: ssl alert from peer: no error
@4000000041d7236527055b64 sslio[1412]: warning: matrixSslEncodeClosureAlert returns ssl error: no error
@4000000041d723652709b4ac sslio[1412]: info: bytes in: 95
@4000000041d72365270ac234 sslio[1412]: info: bytes ou: 1122

However, once I sniff the traffic, I see that the client sent an SSL alert 
message to the server:

 Level: Fatal (2)
 Description: Protocol Version (70)

I'm thinking that sslio shouldn't have reported this as "no error". I 
guess this is a martixSsl library problem, but I thought i should report 
anywhere.

BTW, the imap clients I've tried aren't very user friendly here. All the
one's I've tried refuse to talk to an SSLv3 server, demanding TLSv1.0
(SSLv3.1).  But they're all happy to talk SSLv3 on the imaps port.
Here's some of what the RFC says about compatibility:

   TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
   is easy. TLS clients who wish to negotiate with SSL 3.0 servers
   should send client hello messages using the SSL 3.0 record format and
   client hello structure, sending {3, 1} for the version field to note
   that they support TLS 1.0. If the server supports only SSL 3.0, it
   will respond with an SSL 3.0 server hello; if it supports TLS, with a
   TLS server hello. The negotiation then proceeds as appropriate for
   the negotiated protocol.
...

   TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
   Version 2.0 client hello messages [SSL2]. TLS servers should accept
   either client hello format if they wish to support SSL 2.0 clients on
   the same connection port. The only deviations from the Version 2.0
   specification are the ability to specify a version with a value of
   three and the support for more ciphering types in the CipherSpec.

Evolution was the worst. It sent an SSLv2 client hello (seemingly implying 
that it would talk to SSLv2 servers, then dropped the connection when the 
server replied with an SSLv3.0 server hello. No useful diagnostics 
available at either end.

BTW2, only the commercial version of martixSsl includes TLSv1 support. 
Unless someone has hacked it into the GPL version.

---
Charlie