Quoting Phil Pennock <exim-users@???>:
> 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
