Bug 1755 - Sending of mail doesn't work: TLS packet with unexpected length was received
Summary: Sending of mail doesn't work: TLS packet with unexpected length was received
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: SMTP (show other bugs)
Version: 3.6.1
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2008-10-11 12:45 CEST by Michiel Scholten
Modified: 2008-10-13 12:34 CEST (History)
0 users

See Also:


Attachments
Debug log of claws-mail starting, then trying to send some queued messages (140.08 KB, application/octet-stream)
2008-10-11 13:54 CEST, Michiel Scholten
no flags Details

Description Michiel Scholten 2008-10-11 12:45:07 CEST
I upgraded claws-mail to 3.6.1 on Ubuntu 8.04 this morning, and SMTP stopped working. In my exim4 logs I notice lines like:

2008-10-11 12:03:06 TLS error on connection from (river) [192.168.69.110] (gnutls_handshake): A TLS packet with unexpected length was received.

With 3.6.0 etc sending worked fine. Claws is configured to do STARTTLS on send using SMTP auth.

As far as I know, the only thing that changed on this machine is claws-mail, and sending with other clients still works fine.

Thanks for the great email client!
Comment 1 Colin Leroy 2008-10-11 12:56:03 CEST
can you attach a --debug log ?
Comment 2 Michael Rasmussen 2008-10-11 13:01:00 CEST
(In reply to comment #0)
> I upgraded claws-mail to 3.6.1 on Ubuntu 8.04 this morning, and SMTP stopped
> working. In my exim4 logs I notice lines like:
> 
> 2008-10-11 12:03:06 TLS error on connection from (river) [192.168.69.110]
> (gnutls_handshake): A TLS packet with unexpected length was received.
> 
If you build from cvs did you do:
1) make clean
2) autogen.sh

before building again?

If you have builded using the Debian build system what does line 32 in
[claws_top_build_dir]/debian/rules contain?
Normally it would contain --enable-openssl \. Either change it to this
--enable-gnutls \ or simply remove it since claws will be build using GnuTLS
anyway if it's available.
Comment 3 Colin Leroy 2008-10-11 13:01:20 CEST
Looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467152
Comment 4 Colin Leroy 2008-10-11 13:17:19 CEST
Can you do from command-line:

gnutls-cli -d 5 --starttls -p 25 your.mail.server

You'll get something like:
220 paperstreet.colino.net ESMTP Postfix on an Apple IIc/ProDOS 3.3

Type
STARTTLS <enter>

You'll get:
220 2.0.0 Ready to start TLS

Now hit Ctrl-D
You'll get lots of debug
type 
QUIT <enter>

And paste the whole thing here :)

Thanks!
Comment 5 Colin Leroy 2008-10-11 13:26:46 CEST
Also, I tested with Exim 4.69 from Ubuntu 8.04 too, and it works for me.
Comment 6 Michiel Scholten 2008-10-11 13:36:55 CEST
I installed the packages through the "deb http://ppa.launchpad.net/claws-mail/ubuntu hardy main" repository, so I didn't build anything myself.

I will attach a --debug log shortly.

Doing the gnutls debug line to my Debian sid home server running exim4 4.69-9 I get the following:

13:32:40 mbscholt@river:sort_out$ gnutls-cli -d 5 --starttls -p 25 luna.aquariusoft.org
Resolving 'luna.aquariusoft.org'...
Connecting to '82.169.46.26:25'...

- Simple Client Mode:

220 luna.aquariusoft.org ESMTP Exim 4.69 Sat, 11 Oct 2008 13:32:48 +0200
STARTTLS 
503 STARTTLS command used when not advertised
*** Starting TLS handshake
|<3>| HSK[8073f88]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8073f88]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<2>| EXT[8073f88]: Sending extension CERT_TYPE
|<2>| EXT[8073f88]: Sending extension SERVER_NAME
|<3>| HSK[8073f88]: CLIENT HELLO was send [106 bytes]
|<4>| REC[8073f88]: Sending Packet[0] Handshake(22) with length: 106
|<4>| REC[8073f88]: Sent Packet[1] Handshake(22) with length: 111
|<2>| ASSERT: gnutls_record.c:493
|<2>| ASSERT: gnutls_record.c:913
|<2>| ASSERT: gnutls_buffers.c:1188
|<2>| ASSERT: gnutls_handshake.c:970
|<2>| ASSERT: gnutls_handshake.c:2291
*** Fatal error: A record packet with illegal version was received.
*** Handshake has failed
*** glibc detected *** gnutls-cli: double free or corruption (fasttop): 0x08073f70 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7d8aa85]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d8e4f0]
gnutls-cli[0x804d735]
gnutls-cli[0x804eba3]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d35450]
gnutls-cli[0x804b251]
======= Memory map: ========
08048000-08053000 r-xp 00000000 08:01 16951365   /usr/bin/gnutls-cli
08053000-08054000 rw-p 0000a000 08:01 16951365   /usr/bin/gnutls-cli
08054000-08077000 rw-p 08054000 00:00 0          [heap]
b7b00000-b7b21000 rw-p b7b00000 00:00 0 
b7b21000-b7c00000 ---p b7b21000 00:00 0 
b7c8d000-b7c97000 r-xp 00000000 08:01 10682432   /lib/libgcc_s.so.1
b7c97000-b7c98000 rw-p 0000a000 08:01 10682432   /lib/libgcc_s.so.1
b7c98000-b7ca7000 r-xp 00000000 08:01 10698791   /lib/tls/i686/cmov/libresolv-2.7.so
b7ca7000-b7ca9000 rw-p 0000f000 08:01 10698791   /lib/tls/i686/cmov/libresolv-2.7.so
b7ca9000-b7cab000 rw-p b7ca9000 00:00 0 
b7cab000-b7caf000 r-xp 00000000 08:01 10698779   /lib/tls/i686/cmov/libnss_dns-2.7.so
b7caf000-b7cb1000 rw-p 00003000 08:01 10698779   /lib/tls/i686/cmov/libnss_dns-2.7.so
b7cc1000-b7cc2000 rw-p b7cc1000 00:00 0 
b7cc2000-b7cc5000 r-xp 00000000 08:01 10682436   /lib/libgpg-error.so.0.3.0
b7cc5000-b7cc6000 rw-p 00002000 08:01 10682436   /lib/libgpg-error.so.0.3.0
b7cc6000-b7cc7000 rw-p b7cc6000 00:00 0 
b7cc7000-b7ce6000 r-xp 00000000 08:01 16951138   /usr/lib/liblzo2.so.2.0.0
b7ce6000-b7ce7000 rw-p 0001e000 08:01 16951138   /usr/lib/liblzo2.so.2.0.0
b7ce7000-b7d09000 r-xp 00000000 08:01 16951205   /usr/lib/libopencdk.so.10.0.6
b7d09000-b7d0a000 rw-p 00021000 08:01 16951205   /usr/lib/libopencdk.so.10.0.6
b7d0a000-b7d1e000 r-xp 00000000 08:01 16951429   /usr/lib/libz.so.1.2.3.3
b7d1e000-b7d1f000 rw-p 00013000 08:01 16951429   /usr/lib/libz.so.1.2.3.3
b7d1f000-b7e68000 r-xp 00000000 08:01 10698762   /lib/tls/i686/cmov/libc-2.7.so
b7e68000-b7e69000 r--p 00149000 08:01 10698762   /lib/tls/i686/cmov/libc-2.7.so
b7e69000-b7e6b000 rw-p 0014a000 08:01 10698762   /lib/tls/i686/cmov/libc-2.7.so
b7e6b000-b7e6e000 rw-p b7e6b000 00:00 0 
b7e6e000-b7eb9000 r-xp 00000000 08:01 10682434   /lib/libgcrypt.so.11.2.3
b7eb9000-b7ebb000 rw-p 0004a000 08:01 10682434   /lib/libgcrypt.so.11.2.3
b7ebb000-b7eca000 r-xp 00000000 08:01 16951358   /usr/lib/libtasn1.so.3.0.12
b7eca000-b7ecb000 rw-p 0000e000 08:01 16951358   /usr/lib/libtasn1.so.3.0.12
b7ecb000-b7ecc000 rw-p b7ecb000 00:00 0 
b7ecc000-b7ed9000 r-xp 00000000 08:01 16949923   /usr/lib/libgnutls-extra.so.13.9.1
b7ed9000-b7eda000 rw-p 0000c000 08:01 16949923   /usr/lib/libgnutls-extra.so.13.9.1
b7eda000-b7f4b000 r-xp 00000000 08:01 16949853   /usr/lib/libgnutls.so.13.9.1
b7f4b000-b7f50000 rw-p 00071000 08:01 16949853   /usr/lib/libgnutls.so.13.9.1
b7f51000-b7f53000 r-xp 00000000 08:01 10682463   /lib/libnss_mdns4_minimal.so.2
b7f53000-b7f54000 rw-p 00001000 08:01 10682463   /lib/libnss_mdns4_minimal.so.2
b7f54000-b7f5d000 r-xp 00000000 08:01 10698782   /lib/tls/i686/cmov/libnss_files-2.7.so
b7f5d000-b7f5f000 rw-p 00008000 08:01 10698782   /lib/tls/i686/cmov/libnss_files-2.7.so
b7f60000-b7f62000 rw-p b7f60000 00:00 0 
b7f62000-b7f63000 r-xp b7f62000 00:00 0          [vdso]
b7f63000-b7f7d000 r-xp 00000000 08:01 10682565   /lib/ld-2.7.so
b7f7d000-b7f7f000 rw-p 00019000 08:01 10682565   /lib/ld-2.7.so
bfad1000-bfae6000 rw-p bffeb000 00:00 0          [stack]
Aborted
Comment 7 Michiel Scholten 2008-10-11 13:54:19 CEST
Created attachment 637 [details]
Debug log of claws-mail starting, then trying to send some queued messages

Interesting things start appearing around line 2457 of attached log.

On error out I get:

** Message: Connecting to SMTP server: luna.aquariusoft.org ...


** (claws-mail:25282): WARNING **: SSL connection failed (Internal error in memory allocation.)

** (claws-mail:25282): WARNING **: couldn't start TLS session.


** (claws-mail:25282): WARNING **: [13:40:30] couldn't start TLS session


(claws-mail:25282): Claws-Mail-WARNING **: send: error: 220 TLS go ahead


** (claws-mail:25282): WARNING **: [13:40:30] Error occurred while sending the message.


** (claws-mail:25282): WARNING **: [13:40:30] IMAP error on higgs.aquariusoft.org: FETCH error


(claws-mail:25282): Claws-Mail-WARNING **: Sending queued message 369 failed.

** Message: Connecting to SMTP server: luna.aquariusoft.org ...


** (claws-mail:25282): WARNING **: SSL connection failed (Internal error in memory allocation.)

** (claws-mail:25282): WARNING **: couldn't start TLS session.


** (claws-mail:25282): WARNING **: [13:40:30] couldn't start TLS session


(claws-mail:25282): Claws-Mail-WARNING **: send: error: 220 TLS go ahead


** (claws-mail:25282): WARNING **: [13:40:30] Error occurred while sending the message.


(claws-mail:25282): Claws-Mail-WARNING **: Sending queued message 371 failed.
Comment 8 Michiel Scholten 2008-10-11 13:59:39 CEST
I might note that I got the same error from Modest on my N810 for a while, but never got it from any other client using this server. I'm not sure whether entropy on my mail server has to do with it (re #3), as I didn't have the problem while using this setup for years. Might still be a server issue of course (seeing that Modest his problems too).
Comment 9 Colin Leroy 2008-10-11 15:13:35 CEST
Thanks for all the information.

Given that connection also fails from Modest (which iirc uses gnutls too), and even with gnutls-cli, I think the problem is more probably in Exim or libgnutls (probably Exim, as you don't seem to have problem on POP or IMAP).

Until now, all GnuTLS related bugs reported to Claws Mail had one common point: gnutls-cli worked in each case. 

I'll try to ask the gnuTLS people to look at your gnutls-cli log. 

Comment 10 Michiel Scholten 2008-10-11 15:18:00 CEST
It's really weird though that claws-mail always worked with this setup, up to 3.6.0, as does Thunderbird, various Palm email clients and webmail clients.

Thanks for forwarding it to the GnuTLS guys though :)
Comment 11 Colin Leroy 2008-10-11 16:04:20 CEST
Previously (up to 3.6.0) we used OpenSSL :)
Comment 12 Colin Leroy 2008-10-11 16:44:29 CEST
I took the liberty of testing connection to your server and it failed in the same way. However I hadn't noticed, in your log:

503 STARTTLS command used when not advertised

Maybe that's the cause of the problem?

Comment 13 Colin Leroy 2008-10-11 16:45:21 CEST
Hmm, no. Adding the EHLO command to get STARTTLS advertised, it only fails a bit later:
$ gnutls-cli -d 5 --starttls -p 25 luna.aquariusoft.org
Resolving 'luna.aquariusoft.org'...
Connecting to '82.169.46.26:25'...

- Simple Client Mode:

220 luna.aquariusoft.org ESMTP Exim 4.69 Sat, 11 Oct 2008 16:43:08 +0200
EHLO jack.colino.net
250-luna.aquariusoft.org Hello paperstreet.colino.net [213.41.244.236]
250-SIZE 52428800
250-PIPELINING
250-STARTTLS
250 HELP
STARTTLS
220 TLS go ahead
*** Starting TLS handshake
|<3>| HSK[8073fb8]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8073fb8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<2>| EXT[8073fb8]: Sending extension CERT_TYPE
|<2>| EXT[8073fb8]: Sending extension SERVER_NAME
|<3>| HSK[8073fb8]: CLIENT HELLO was send [106 bytes]
|<4>| REC[8073fb8]: Sending Packet[0] Handshake(22) with length: 106
|<4>| REC[8073fb8]: Sent Packet[1] Handshake(22) with length: 111
|<4>| REC[8073fb8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8073fb8]: Received Packet[0] Handshake(22) with length: 74
|<4>| REC[8073fb8]: Decrypted Packet[0] Handshake(22) with length: 74
|<3>| HSK[8073fb8]: SERVER HELLO was received [74 bytes]
|<3>| HSK[8073fb8]: Server's version: 3.1
|<3>| HSK[8073fb8]: SessionID length: 32
|<3>| HSK[8073fb8]: SessionID: c1fe9cc4fd7fd83afb0c2c440d5e63fed8237d39e40d5857990ccd0a395c6441
|<3>| HSK[8073fb8]: Selected cipher suite: DHE_RSA_AES_256_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:153
|<4>| REC[8073fb8]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[8073fb8]: Received Packet[1] Handshake(22) with length: 715
|<4>| REC[8073fb8]: Decrypted Packet[1] Handshake(22) with length: 715
|<3>| HSK[8073fb8]: CERTIFICATE was received [715 bytes]
|<4>| REC[8073fb8]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[8073fb8]: Received Packet[2] Handshake(22) with length: 653
|<4>| REC[8073fb8]: Decrypted Packet[2] Handshake(22) with length: 653
|<3>| HSK[8073fb8]: SERVER KEY EXCHANGE was received [653 bytes]
|<4>| REC[8073fb8]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[8073fb8]: Received Packet[3] Handshake(22) with length: 16384
|<4>| REC[8073fb8]: Decrypted Packet[3] Handshake(22) with length: 16384
|<3>| HSK[8073fb8]: CERTIFICATE REQUEST was received [19226 bytes]
|<4>| REC[8073fb8]: Expected Packet[4] Handshake(22) with length: 2842
|<4>| REC[8073fb8]: Received Packet[4] Handshake(22) with length: 2842
|<4>| REC[8073fb8]: Decrypted Packet[4] Handshake(22) with length: 2842
|<2>| ASSERT: gnutls_buffers.c:1223
|<2>| ASSERT: gnutls_handshake.c:1097
|<2>| ASSERT: gnutls_handshake.c:1196
|<2>| ASSERT: gnutls_handshake.c:2322
*** Fatal error: Internal error in memory allocation.
*** Handshake has failed
*** glibc detected *** gnutls-cli: double free or corruption (fasttop): 0x08072cd0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7d3aa85]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d3e4f0]
gnutls-cli[0x804d735]
gnutls-cli[0x804eba3]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7ce5450]
gnutls-cli[0x804b251]
======= Memory map: ========
08048000-08053000 r-xp 00000000 08:01 575062     /usr/bin/gnutls-cli
08053000-08054000 rw-p 0000a000 08:01 575062     /usr/bin/gnutls-cli
08054000-0809a000 rw-p 08054000 00:00 0          [heap]
b7b00000-b7b21000 rw-p b7b00000 00:00 0 
b7b21000-b7c00000 ---p b7b21000 00:00 0 
b7c3a000-b7c44000 r-xp 00000000 08:01 966694     /lib/libgcc_s.so.1
b7c44000-b7c45000 rw-p 0000a000 08:01 966694     /lib/libgcc_s.so.1
b7c45000-b7c54000 r-xp 00000000 08:01 1001282    /lib/tls/i686/cmov/libresolv-2.7.so
b7c54000-b7c56000 rw-p 0000f000 08:01 1001282    /lib/tls/i686/cmov/libresolv-2.7.so
b7c56000-b7c58000 rw-p b7c56000 00:00 0 
b7c71000-b7c72000 rw-p b7c71000 00:00 0 
b7c72000-b7c75000 r-xp 00000000 08:01 967316     /lib/libgpg-error.so.0.3.0
b7c75000-b7c76000 rw-p 00002000 08:01 967316     /lib/libgpg-error.so.0.3.0
b7c76000-b7c77000 rw-p b7c76000 00:00 0 
b7c77000-b7c96000 r-xp 00000000 08:01 575289     /usr/lib/liblzo2.so.2.0.0
b7c96000-b7c97000 rw-p 0001e000 08:01 575289     /usr/lib/liblzo2.so.2.0.0
b7c97000-b7cb9000 r-xp 00000000 08:01 575014     /usr/lib/libopencdk.so.10.0.6
b7cb9000-b7cba000 rw-p 00021000 08:01 575014     /usr/lib/libopencdk.so.10.0.6
b7cba000-b7cce000 r-xp 00000000 08:01 574586     /usr/lib/libz.so.1.2.3.3
b7cce000-b7ccf000 rw-p 00013000 08:01 574586     /usr/lib/libz.so.1.2.3.3
b7ccf000-b7e18000 r-xp 00000000 08:01 1001267    /lib/tls/i686/cmov/libc-2.7.so
b7e18000-b7e19000 r--p 00149000 08:01 1001267    /lib/tls/i686/cmov/libc-2.7.so
b7e19000-b7e1b000 rw-p 0014a000 08:01 1001267    /lib/tls/i686/cmov/libc-2.7.so
b7e1b000-b7e1e000 rw-p b7e1b000 00:00 0 
b7e1e000-b7e69000 r-xp 00000000 08:01 967423     /lib/libgcrypt.so.11.2.3
b7e69000-b7e6b000 rw-p 0004a000 08:01 967423     /lib/libgcrypt.so.11.2.3
b7e6b000-b7e7a000 r-xp 00000000 08:01 574954     /usr/lib/libtasn1.so.3.0.12
b7e7a000-b7e7b000 rw-p 0000e000 08:01 574954     /usr/lib/libtasn1.so.3.0.12
b7e7b000-b7e7c000 rw-p b7e7b000 00:00 0 
b7e7c000-b7e89000 r-xp 00000000 08:01 575262     /usr/lib/libgnutls-extra.so.13.9.1
b7e89000-b7e8a000 rw-p 0000c000 08:01 575262     /usr/lib/libgnutls-extra.so.13.9.1
b7e8a000-b7efb000 r-xp 00000000 08:01 575230     /usr/lib/libgnutls.so.13.9.1
b7efb000-b7f00000 rw-p 00071000 08:01 575230     /usr/lib/libgnutls.so.13.9.1
b7f04000-b7f08000 r-xp 00000000 08:01 1001275    /lib/tls/i686/cmov/libnss_dns-2.7.so
b7f08000-b7f0a000 rw-p 00003000 08:01 1001275    /lib/tls/i686/cmov/libnss_dns-2.7.so
b7f0a000-b7f0c000 r-xp 00000000 08:01 966827     /lib/libnss_mdns4_minimal.so.2
b7f0c000-b7f0d000 rw-p 00001000 08:01 966827     /lib/libnss_mdns4_minimal.so.2
b7f0d000-b7f16000 r-xp 00000000 08:01 1001276    /lib/tls/i686/cmov/libnss_files-2.7.so
b7f16000-b7f18000 rw-p 00008000 08:01 1001276    /lib/tls/i686/cmov/libnss_files-2.7.so
b7f19000-b7f1b000 rw-p b7f19000 00:00 0 
b7f1b000-b7f1c000 r-xp b7f1b000 00:00 0          [vdso]
b7f1c000-b7f36000 r-xp 00000000 08:01 973798     /lib/ld-2.7.so
b7f36000-b7f38000 rw-p 00019000 08:01 973798     /lib/ld-2.7.so
bfc20000-bfc35000 rw-p bffeb000 00:00 0          [stack]
Aborted
Comment 14 Colin Leroy 2008-10-11 18:46:34 CEST
Simon Josefsson of GnuTLS tested your server, with gnutls-cli version 2.6.0 it succeeds. It might be a bug in GnuTLS :)

So, I've tested on Ubuntu Intrepid and it works too. Intrepid ships gnutls 2.4.1; you may rebuild the gnutls packages on Hardy using:
http://archive.ubuntu.com/ubuntu/pool/main/g/gnutls26/gnutls26_2.4.1-1build1.dsc
http://archive.ubuntu.com/ubuntu/pool/main/g/gnutls26/gnutls26_2.4.1.orig.tar.gz
http://archive.ubuntu.com/ubuntu/pool/main/g/gnutls26/gnutls26_2.4.1-1build1.diff.gz

Fetch these files; run
dpkg-source -x gnutls*dsc
cd gnutls-2.4.1-1build1 (or something like that)
sudo apt-get build-dep libgnutls-dev
dpkg-buildpackage -us -uc -rfakeroot

The packages will be built and you should be able to install them:
cd ..
sudo dpkg -i *gnutls*.deb

HTH!

I'm marking the bug as INVALID, as it isn't a Claws Mail bug; reopen it if the new gnutls-cli doesn't fail, but Claws still fails.
Comment 15 Colin Leroy 2008-10-11 18:49:35 CEST
Oh, you'll need to rebuild claws mail from source against the new libgnutls too. 
Maybe the easiest way is to wait for Intrepid to be released (or use its beta for a few weeks) :)
Comment 16 Michiel Scholten 2008-10-11 23:05:20 CEST
The gnutls causing some memory corruption doesn't sound quite healthy to me indeed :)

I started building a newer libgcrypt of my own, but quickly started into "you need a newer version of X" hell:

dpkg-checkbuilddeps: Unmet build dependencies: libgcrypt11-dev (>= 1.3.2) guile-1.8-dev
dpkg-checkbuilddeps: Build conflicts: libgnutls-dev

... and it only got worse from there as some packages required a newer libc6 and such. At the moment I had changed my sources.list to use intrepid and was looking at the changes this would cause (especially packages that would be forced to uninstall and such), I decided to stick with claws-mail 3.6.0 for the time being.

Just to be complete, I'm using libgnutls13 2.0.4-1ubuntu2.1 on Ubuntu 8.04 with claws and am trying to send through my Debian sid server with exim4 4.69-9 with libgnutls26 2.4.2-1

I have the same issue on my N810 with claws-mail 3.6.1 btw. There I have libgnutls13 2.0.4-3maemo3 installed.

So, as claws-mail uses gnutls as of 3.6.1 and I see this inconsistency in gnutls versions on client and server side, it *seems* right to assume it's a gnutls bug/issue. For Ubuntu, I can wait for Intrepid, but it's a real issue for me on Maemo. I'll try looking for the issue with them and follow-up here with a url.

Cheers and thanks for the energy :)
Comment 17 Michael Rasmussen 2008-10-12 00:47:33 CEST
(In reply to comment #16)
> forced to uninstall and such), I decided to stick with claws-mail 3.6.0 for the
> time being.
> 
> Just to be complete, I'm using libgnutls13 2.0.4-1ubuntu2.1 on Ubuntu 8.04 with
> claws and am trying to send through my Debian sid server with exim4 4.69-9 with
> libgnutls26 2.4.2-1
> 
I have backported the required libraries to Ubuntu-hardy. Get, and
install (dpkg -i), the following:
ftp://ftp.datanom.net/pub/ubuntu/i386/libgcrypt11_1.4.1-1ubuntu1_i386.deb
ftp://ftp.datanom.net/pub/ubuntu/i386/libgnutls-dev_2.4.1-1build1_i386.deb
ftp://ftp.datanom.net/pub/ubuntu/i386/libgnutls26_2.4.1-1build1_i386.deb

After that rebuild claws-mail.

It could also require a rebuild of libetpan-0.57 at libetpan also is
build against gnutls-dev. It does not seem to make a difference here
but maybe the errors you are facing also includes libetpan.
Comment 18 Michiel Scholten 2008-10-12 14:20:55 CEST
OK, this is just weird.

I successfully rebuilded claws-mail and libetpan after installing the new libgnutls libraries posted in #17. Sending sending a new mail works, but queued items still bugs, but also on my Debian sid laptop with claws-mail 3.5.0. Sending a new mail from there works fine too.

Sending a new mail from my N810 with claws-mail 3.6.1 still fails with the original error though, but I'll file a new bug with the maemo guys for that, requesting a new gnutls package.

Thanks all!

Comment 19 Michael Rasmussen 2008-10-12 14:31:02 CEST
(In reply to comment #18)
> I successfully rebuilded claws-mail and libetpan after installing the new
> libgnutls libraries posted in #17. Sending sending a new mail works, but queued
> items still bugs, but also on my Debian sid laptop with claws-mail 3.5.0.
> Sending a new mail from there works fine too.
> 
What do you mean by queued mails? Is this mails queued before upgrading to the new gnutls or is it mails created with the new gnutls chosen to be queued for later sending?
Comment 20 Michiel Scholten 2008-10-12 14:49:56 CEST
These where mails queued by claws-mail 3.6.1 when the TLS didn't work. These where still present when I installed the new gnutls and rebuilt claws and libetpan. With the newly built 3.6.1, a fresh mail could be sent, but the old queued one couldn't, because of some IMAP read error, which was weird as other IMAP functionality still worked just fine and could read the queued mail itself when selecting it.

The problem is that I since deleted that mail and can't seem to reproduce by queuing new mails so I'm not sure about the exact cause.
Comment 21 Michael Rasmussen 2008-10-12 14:57:36 CEST
(In reply to comment #20)
> 
> The problem is that I since deleted that mail and can't seem to reproduce by
> queuing new mails so I'm not sure about the exact cause.
> 
I am no expert in these matters but perhaps queued mails are populated with some initial stuff from gnutls which is therefore not remade, even with an upgrade of gnutls, so you infact unknowingly were sending these mails with the SSL part generated from the old library. This is in fact possible because the new library is backwards compatible.
Comment 22 Michiel Scholten 2008-10-13 12:34:23 CEST
I filed a bug with Maemo about the gnutls issue [0], and they asked which exact version/revision of libgnutls fixed the issue, as they are reserved of putting a 'major' new version of the library in their base system. Could you please ping the GnuTLS guys about this? It would be greatly appreciated :)

[0] https://bugs.maemo.org/show_bug.cgi?id=3801

Note You need to log in before you can comment on or make changes to this bug.