On 2010-09-07 at 11:40 +0100, Jonathan Plews wrote:
> Hi, I don't want to get into the back-story of this error, but did
> want to raise an issue that I have just come across.
>
>
> My customers mail server was not able to receive messages for
> Microsoft's own hosted exchange service because on every connection
> attempt there was a 'A TLS packet with unexpected length was received'
> error. There was also 1 independently run Ex2007 server that was
> causing the same problem.
>
> After digging through bug reports and removing ca-certificates (or
> dpk-reconfiguring) has completely stopped the problem
>
>
> All of this may have been covered before, but as I noticed a change I
> thought it may be worth reporting, I'm interested to hear if others
> are having the same problems lately.
>
>
> The bug must lie in gnutls or ca-certificates, yet all the Debian bugs
> are in the Exim lists - but that mess is something for later.
Sounds like:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477
reoccurring: ie, GnuTLS getting upset if there are too many certificate
authorities locally known.
GnuTLS bug.
Perhaps Exim could add an option to call
gnutls_handshake_set_max_packet_length() as Yet Another SSL Library
Tuning Option To Work Around Brokenness. But reportedly updating gnutls
fixes the problem, so why not update the broken software instead of
updating Exim to work around it? Or switch to OpenSSL.
Otherwise, if you're in a position to reproduce this and feel like
exploring, can you see what happens if you modify Exim's src/tls-gnu.c
to include a call to:
gnutls_handshake_set_max_packet_length(session, 64*1024);
in tls_session_init() around the gnutls_compat_mode area of the
function?
If you can confirm this works around the problem, I'll add knobs to Exim
to expose this setting to configuration and let people tune their way
around the bug in future.
-Phil
