Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.

[Marc Haber]

On Sat, Jan 05, 2008 at 09:02:43PM +1100, Andrew McGlashan wrote:
> Marc Haber wrote:
> >I am having a problem with your port references. It would be more
> >helpful if you'd not only reference the port number (which is most
> >probably irrelevant for debugging), but also the protocol you're
> >using. I feel that we are mixing up plain unencrypted SMTP (which
> >usually runs on ports tcp/25 and/or tcp/587), the ESMTP STARTTLS
> >extension (which also runs on ports tcp/25 and/or tcp/587 and is
> >negotiated in a clear text handshake involving the EHLO and STARTTLS
> >commands), and the non-standardized "SMTP over SSL" protocol which
> >microsoft and other sites use on port tcp/465.
> 
> I believe that I am using ESMTP STARTTLS.

So you only have ssl_on_connect_port=465 in your exim configuration
and no other port number? And you get a clear text banner when you
connect to tcp/25 or tcp/587? And you get a banner when you use
gnutls-cli -p 465 _without_ the -s option?

> >>If Exim can use whatever qpopper is using for the SSL setup, then
> >>that would probably solve the problem.
> >
> >qpopper is using OpenSSL, which I'd like to avoid for exim since exim
> >links to a gazillion of other libraries and I'd rather not have to
> >check all their licenses for an OpenSSL exception. Additionally, Simon
> >is member of the GnuTLS team and surely would not want to advocate
> >changing to a competitor.
> 
> I understand, but it _seems_ that OpenSSL works whilst GnuTLS doesn't.... 

yes, and if we don't find out why, it's going to stay this way. I find
it worth trying to find out where the issue with GnuTLS is, and GnuTLS
upstream has become very responsive and motivated in the last few
weeks (btw, I really really appreciate that).

> but I can't be sure as I probably don't understand enough to properly debug 
> the issue amongst other things I need to do.
> 
> Is there a good step by step process that I could follow to help this cause?
> 
> Would a copy (privately) of my /var/lib/exim4/config.autogenerated help?

I must admit that I have lost the overview over this bug report. If I
recall correctly, Simon is running an incredimail evaluation copy
under wine and can do any debugging on the library side that might be
possible. If I recall correctly, again, he has found out that
incredimail negotiates an obsolete version of SSL whose ciphers can
easily be broken and might be inable to negotiatate a better version.
Under these circumstances, I remember him writing, it might be better
not to use encryption at all.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190