mutt - TLS packet with unexpected length

[Erik Garrison]

http://<email address hidden>/msg32520.html

I use mutt on Feisty (ubuntu). When connecting to gmail using pops, mutt connects to the server and asks my password. After I enter it, I see the following error message:

tls_socket_read (A TLS packet with unexpected length was received.)

I googled a bit and saw that it is GNUTLS which causes the problem and rebuilding mutt with openssl solves the problem. Is there any way other than building mutt from source?

I have replicated this in the most current fiesty version of mutt (1.5.13-1ubuntu1).

[feld (felderado)]

I'm also experiencing the same issue on Gutsy....

[Emil Sit (emilsit)]

Hello,

I can not reproduce this problem with the latest version of mutt (1.5.17+20080114) in the beta version of Ubuntu, Hardy Heron. Both IMAP and POP over SSL appear to work as shipped. If you have the chance to, can you try and see if you still have this problem in the latest Ubuntu?

Thanks.

[Gregory Petrosyan (gregory-petrosyan)]

I confirm this bug. Latest Ubuntu (8.04) and Mutt (1.5.17+20080114); GMail over IMAPS.
I experience it when trying to change folder to one with lots (500+) of messages,
especially for the first time (when there's no header cache).

[Gregory Petrosyan (gregory-petrosyan)]

I think, this is a GNUTLS bug indeed.

http://groups.google.se/group/linux.debian.bugs.dist/browse_thread/thread/6509643ac7f2ec9e
http://<email address hidden>/msg02368.html
http://developer.pidgin.im/ticket/4646
http://dev.mutt.org/trac/ticket/2540

So, easy fix is to use OpenSSL with Mutt, but the right one will be to fix GNUTLS.

[trmentry (trmentry)]

I can confirm this as well on 8.04 64b and mutt version installed: 1.5.17+20080114-1ubuntu1 for connection to Goggle Apps.

I get the error randomly. Sometimes in fast succession every couple of minutes.. and other times long periods of time between.

[Bill Duetschler (bikergeek)]

I can confirm this on Intrepid w/ mutt 1.5.18 for connection to my ISP's mail server over IMAPS (Courier-IMAP). Like trmentry I get this randomly--sometimes I can go all day without this error and sometimes I get it every couple of minutes for half an hour.

Haven't tested it on Jaunty.

One other thing I've noticed is that when this happens it resets all the message flags ("N"ew and "D"elete) since I last sync'd the mailbox.

[trmentry (trmentry)]

One thing I tried today is to not use Mutt for the ssl connection. So I setup Stunnel4 to do that for me.

I had Mutt connect to localhost:143 and Stunnel4 then take it to imap.gmail.com:993.

I still experienced the same issues as before. Random TLS bad packets, etc.

Hardy 64 bit server
Mutt 1.5.17+20080114-1ubuntu1
Stunnel4: 3:4.21-1

[Bem Jones-Bey (ajani)]

I can confirm that this bug affects me on Jaunty 64bit. After compiling mutt from source and linking with openssl instead of gnutls, the problem goes away. So it's definitely a bug in gnutls.

[Jeremy Nickurak (nickurak)]

Terribly frustrating when you've got many many messages, and you've marked a bunch for particular statuses to record the point in which you're working.... and then everything gets lost.

The failure of a core piece communication infrastructure, which then effects many other applications, potentially with all kinds of data loss, should be a very high priority bug.

[Jeremy Nickurak (nickurak)]

Is there any reason to believe that this problem isn't affecting all the other projects which are using gnutls instead of openssl for licensing reasons? Perhaps with other hard-to-diagnose reliability issues? Core projects I'm seeing that might be affected include cups, exim, gnome-vfs, tracker, vino...

[Jeremy Nickurak (nickurak)]

Filed upstream at https://savannah.gnu.org/support/index.php?106987 , which launchpad doesn't seem to interoperate with.

[Mark McCoy (mcking)]

Jeremy,

I can confirm that this bug has been present in python-ldap, ldap-utils, and gnome-vfs since the 8.04 release of Ubuntu, (ever since GNU-TLS replaced OpenSSL across the entire distribution), and it is *still present*. The LDAP tools all worked fine with OpenSSL and have been broken for me for the last 18 months now.

[marco (gaedol)]

Hi,

I am using Ubuntu 9.10, and I can confirm the behavior of mutt with imaps and smtps, *not* on gmail servers.

If i read the compile option in mutt -v correctly, mutt has been compiled with GNUTLS, since I have: +USE_SSL_GNUTLS and -USE_SSL_OPENSSL.

This renders mutt almost completely unusable for me.

[David Whiting (david-whiting)]

I have just started getting this (since yesterday, 2010-03-10). I have been using mutt to connect to a microsoft exchange server via secure imap for about a year without a problem and now this has suddenly started. I lose mutt about every 5 mins. As with Marco this means I can no longer use mutt. I have checked with the admin who runs the exchange server and he says that he has not changed anything on the server side.

[marco (gaedol)]

Hi,

thank you David for your feedback.

I have tried in the last few days to compile mutt with different options, from ubuntu (and also debian) source packages.

This behavior is still there both with GNUTLS and with OpenSSL. In fact, compiling with -USE_POP +USE_IMAP +USE_SMTP
+USE_SSL_OPENSSL -USE_SSL_GNUTLS +USE_SASL -USE_GSS [...] doesn't change a thing.

At this point (since the same behavior is there both with GNUTLS and OpenSSL) I would tend to think that the bug is not (only) in GNUTLS.

Again: this bug makes mutt unusable (IMHO).

[David Whiting (david-whiting)]

Ahaaa, I've found out what caused the problem in my case. My muttrc contained a non-existent mailbox in my list of mailboxes. Removing this resolved the problem, i.e. the jsp mailbox in the example below no longer existed:

# Line that was failing
mailboxes +INBOX +"Junk-Email" +jsp

# Line that now works okay
mailboxes +INBOX +"Junk-Email"

[Querdenker (everytrash)]

i have the same error!

tls_socket_read (A TLS packet with unexpected length was received)

with "--with-sll" all is OK

[Ariel Faigon (ariel.faigon)]

I'm on Ubuntu 10.10 (Maverick) with mutt:
Mutt 1.5.20 (2009-06-14)

Started getting this when switching to a new MS Exchange-2010 server using imap from an older exchange server
It happens very frequently making mutt very unusable.

      tls_socket_read (A TLS packet with unexpected length was received)

$ mutt -v
Mutt 1.5.20 (2009-06-14)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 2.6.35-28-generic (x86_64)
ncurses: ncurses 5.7.20100626 (compiled with 5.7)
libidn: 1.18 (compiled with 1.18)
hcache backend: GDBM version 1.8.3. 10/15/2002 (built Dec 5 2009 22:15:17)
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK
+USE_POP +USE_IMAP +USE_SMTP
-USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to <email address hidden>.
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode
misc/hg.pmdef.debugtime
debian-specific/build_doc_adjustments.diff
features/ifdef
features/xtitles
features/trash-folder
features/purge-message
features/sensible_browser_position
features-old/patch-1.5.4.vk.pgp_verbose_mime
features/compressed-folders
features/compressed-folders.debian
debian-specific/Muttrc
debian-specific/Md.etc_mailname_gethostbyname.diff
debian-specific/use_usr_bin_editor.diff
debian-specific/correct_docdir_in_man_page.diff
debian-specific/dont_document_not_present_features.diff
debian-specific/document_debian_defaults
debian-specific/assumed_charset-compat
debian-specific/467432-write_bcc.patch
misc/define-pgp_getkeys_command.diff
misc/gpg.rc-paths
misc/smime.rc
upstream/533209-mutt_perror.patch
upstream/533459-unmailboxes.patch
upstream/533439-mbox-time.patch
upstream/531430-imapuser.patch
upstream/534543-imap-port.patch
upstream/538128-mh-folder-access.patch
upstream/537818-emptycharset.patch
upstream/535096-pop-port.patch
upstream/542910-search-segfault.patch
upstream/533370-pgp-inline.patch
upstream/533520-signature-highlight.patch
upstream/393926-internal-viewer.patch
upstream/543467-thread-segfault.patch
upstream/544180-italian-yesorno.patch
upstream/542817-smimekeys-tmpdir.patch
upstream/544794-smtp-batch.patch
upstream/537694-segv-imap-headers.patch
upstream/548577-gpgme-1.2.patch
upstream/548494-swedish-intl.patch
upstream/553321-ansi-escape-segfault.patch
upstream/553238-german-intl.patch
upstream/557395-muttrc-c...

[Paul Gortmaker (paul-gortmaker)]

I can confirm that the above suggested workaround [from David] of pruning non-existent entries from the mailbox line(s) worked for me locally. Server was Exch 2010.

[Ｖ字龍(Vdragon) (vdragon)]

I have this issue too, but I met when using add-apt-repository

Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 88, in <module>
    ppa_info = get_ppa_info_from_lp(user, ppa_name)
  File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py", line 80, in get_ppa_info_from_lp
    curl.perform()
pycurl.error: (35, 'gnutls_handshake() failed: A TLS packet with unexpected length was received.')

 I think it's a general bug when gnu-tls is used to establish ssl connections.

[Andrey Tykhonov (atykhonov)]

 I had the same issue. And just recently resolved it.

I have tried to connect mutt to the davmail and in mutt configuration file just placed the same lines as was in configuration for gmail and I didn't noticed that they should be different.

So, one of the line was:

set folder = "imaps://localhost:1143" # I just changed imap.gmail.com:993 to localhost:1143

But it is wrong. Instead of imaps should be imap (without 's' in the end!)

Good luck!

[Bill Duetschler (bikergeek)]

Of course if you change "imaps" to "imap" in .muttrc it will appear to fix the problem, because you will no longer be using GNU TLS but will be transmitting all information (including your password!) in plaintext. So yes this will make the problem "go away" but it is not a solution.

mutt with GNU TLS appears to work correctly in Precise and Quantal, now. Not sure what changed.

[Daniel Wiberg (dannew)]

Yes, works fine for me to in 12.04.

[Timo Aaltonen (tjaalton)]

closing as fixed

[tremby (tremby)]

I'm on 12.04.1 and this bug is not fixed for me. I still fairly frequently get this same error message.

[Stefan Handschuh (handschuh)]

It happens for me as well on 12.04.

[Luis Lezcano Airaldi (devilishfreak)]

I can confirm this issue, too.
Ubuntu 13.04
Mutt 1.5.21 (2010-09-15)

[Luis Lezcano Airaldi (devilishfreak)]

Just for the record: using the package "mutt-patched" seems to solve the issue. It depends on gnutls too, so this seems more like a bug on mutt itself.

[Russ Kine (mondifero)]

I am running Mutt 1.5.21 on Debian Wheezy and had the same issue. Unfortunately, none of the advice on this page helped (including the installation of muth-patched; I did not try recompiling mutt with openssl, however.).

What solved it for me was setting imap_keepalive to a small enough number. In my muttrc, it was set to 300. When I changed this to 10, the packet length errors stopped! i.e.,

set imap_keepalive = 10

Good luck,

RK

[luis gf (luisgf)]

With the lastest version of ubuntu LTS 14.04. Exim4 packages has comunication problems with other exim4 running the same Ubuntu version. After trying to do the SSL handshake, gnutls broke the connection with the lenght error.

<2>| EXT[0x14a7ea0]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0x14a7ea0]: CLIENT HELLO was sent [139 bytes]
|<6>| BUF[HSK]: Inserted 139 bytes of Data
|<7>| HWRITE: enqueued 139. Total 139 bytes.
|<7>| HWRITE FLUSH: 139 bytes in buffer.
|<4>| REC[0x14a7ea0]: Sending Packet[0] Handshake(22) with length: 139
|<7>| WRITE: enqueued 144 bytes for 0x4. Total 144 bytes.
|<4>| REC[0x14a7ea0]: Sent Packet[1] Handshake(22) with length: 144
|<7>| HWRITE: wrote 139 bytes, 0 bytes left.
|<7>| WRITE FLUSH: 144 bytes in buffer.
|<7>| WRITE: wrote 144 bytes, 0 bytes left.
|<7>| READ: Got 0 bytes from 0x4
|<7>| READ: read 0 bytes from 0x4
|<2>| ASSERT: gnutls_buffers.c:640
|<2>| ASSERT: gnutls_record.c:971
|<2>| ASSERT: gnutls_handshake.c:2762
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[0x14a7ea0]: Sending Packet[1] Alert(21) with length: 2
|<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<7>| WRITE: wrote 7 bytes, 0 bytes left.
|<4>| REC[0x14a7ea0]: Sent Packet[2] Alert(21) with length: 7
*** Handshake has failed

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Reinier Post (reinpost)]

This still happens on Ubuntu 12.04 (up to date with patches) connecting to an Exchange 2010 server,
using the 'mutt' package, version 1.5.21-5ubuntu2.1. It happens often enough that mutt is effectively unusable. I can post my configuration on request. The mutt in package 'mutt-patched', same version, has the same problem, but additionally crashes.

[Reinier Post (reinpost)]

For what it's worth: the same problem exists with Cygwin's mutt, so it looks like this needs to be fixed upstream.

[Reinier Post (reinpost)]

Incidentally: setting imap_keepalive to a small value does not make any difference for me.