Quoting Phil Pennock <[email protected]>:
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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Hi,It's been a while since I started this thread but I thought I should update it, even though my conclusion is not very helpful.
I have 2 servers that are having the problem, one was modified as above, the other to not offer any ca certs at all - both have not had any further problems (but I have checked that messages have been delivered from the problem senders)
The problem now is that I cannot force these errors without potentially disrupting my clients emails. To test further I'd need to set up a server at home to receive for an unused domain, and sign up for a trial of MS Hosted exchange. Before this I'd want to revert one of the patched servers just to be sure the problem still exists.
I would do this if asked, but I'm not sure if it's worth the effort. The core issue seems to be error handling in both GNUTLS and Exchange.
I'm going to send a message to the GNUTLS list because I think the errors its giving could be more helpful, normally I'd jump at the chance to generate a load of debug info, but for the days when searching based on an error in standard logs is all you have time for it would be good to have less dead ends. That's my conclusion from this experience anyway :)
Regards Jonathan Plews
pgpNTBsUs2vky.pgp
Description: PGP Digital Signature
-- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
