Bug#629314: more info -- has to do with mailx program being used
Hi, The older exim4-base also has the recipient up front. The problem must be a change in the mail program -- older system is fine using bsd-mailx via alternatives whilst newer system is using heirloom-mailx. Regardless, it does make more sense to put the recipient at the end of the mail line -- it works fine with both this way. This from an older lenny system: # which mail /usr/bin/mail # l /usr/bin/mail lrwxrwxrwx 1 root root 22 2010-01-17 12:03 /usr/bin/mail - /etc/alternatives/mail # l /etc/alternatives/mail lrwxrwxrwx 1 root root 18 2010-01-17 12:03 /etc/alternatives/mail - /usr/bin/bsd-mailx # l /usr/bin/bsd-mailx -rwxr-xr-x 1 root root 78520 2008-04-26 17:54 /usr/bin/bsd-mailx And a newer squeeze system (with the problem) # which mail /usr/bin/mail # l /usr/bin/mail lrwxrwxrwx 1 root root 22 Sep 17 02:54 /usr/bin/mail - /etc/alternatives/mail # l /etc/alternatives/mail lrwxrwxrwx 1 root root 23 Sep 17 02:54 /etc/alternatives/mail - /usr/bin/heirloom-mailx # l /usr/bin/heirloom-mailx -rwxr-xr-x 1 root root 343264 May 29 2010 /usr/bin/heirloom-mailx -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9012 2102 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612281: installation-reports: volatile reference instead of squeeze/updates in, installer
Package: installation-reports Severity: minor -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/debian-cd/6.0.0/multi-arch/iso-cd/debian-6.0.0-amd64-i386-netinst.iso Date: 7th February 2011 Machine: HP DL380 G4 Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] -- with non-free firmware added to iso Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Simple base minimalistic installation with ssh server and standard only, as server, no desktop GUI installed. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=6.0 (squeeze) - installer build 20110106+b1 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux hp-dl380g4-a 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation E7520 Memory Controller Hub [8086:3590] (rev 0c) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3200] lspci -knn: 00:02.0 PCI bridge [0604]: Intel Corporation E7525/E7520/E7320 PCI Express Port A [8086:3595] (rev 0c) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation E7520 PCI Express Port C [8086:3599] (rev 0c) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 [8086:24d2] (rev 02) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3201] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.1 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 [8086:24d4] (rev 02) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3201] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.2 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 [8086:24d7] (rev 02) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3201] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.3 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 [8086:24de] (rev 02) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3201] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3201] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev c2) lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge [8086:24d0] (rev 02) lspci -knn: 00:1f.1 IDE interface [0101]: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller [8086:24db] (rev 02) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:3201] lspci -knn: Kernel driver in use: ata_piix lspci -knn: 01:03.0 VGA compatible controller [0300]: ATI Technologies Inc Rage XL [1002:4752] (rev 27) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:001e] lspci -knn: 01:04.0 System peripheral [0880]: Compaq Computer Corporation Integrated Lights Out Controller [0e11:b203] (rev 01) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:b206] lspci -knn: 01:04.2 System peripheral [0880]: Compaq Computer Corporation Integrated Lights Out Processor [0e11:b204] (rev 01) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:b206] lspci -knn: 02:00.0 PCI bridge [0604]: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A [8086:0329] (rev 09) lspci -knn: 02:00.2 PCI bridge [0604]: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B [8086:032a] (rev 09) lspci -knn: 03:01.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet [14e4:1648] (rev 10) lspci -knn: Subsystem: Compaq Computer Corporation Device [0e11:00d0] lspci -knn: Kernel driver in use: tg3
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
Hi, RE: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459323 Marc Haber wrote: How does your exim reply when you telnet to localhost 465? Does it show a clear text SMTP banner? www:/tmp# telnet localhost 465 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. [had to press ctrl-c to get the last line] Please let's find out whether Incredimail does really really use SMTP over SSL. On your exim server, run $ echo 220 | socat TCP4-LISTEN:4465 - and configure incredimail to use Outgoing 4465 with SSL. Then try sending a message. When you see a cleartext EHLO something on the socat shell, Incredimail is trying to do ESMTP STARTTLS, which will need a differently configured exim than Outlook Express does. www:/tmp# echo 220 | socat TCP4-LISTEN:4465 - L3 À @dbcÎêÕ¢ÅETݳܺÔPuTTYwww:/tmp# PuTTY If you don't see a cleartext EHLO something, please retry with openssl s_server instead of the socat. I couldn't work out how to use openssl s_server properly Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 8790 1224 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
Hi,
Simon Josefsson wrote:
openssl s_server -accept 4465 -debug -msg
www:~# openssl s_server -accept 4465 -debug -msg
Error opening server certificate private key file server.pem
8687:error:02001002:system library:fopen:No such file or
directory:bss_file.c:352:fopen('server.pem','r')
8687:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:354:
unable to load server certificate private key file
and try IM on port 4465 against it. And also try:
gnutls-serv --port 4465 --debug 4711
www:~# gnutls-serv --port 4465 --debug 4711
Echo Server ready. Listening to port '4465'.
|7| READ: Got 5 bytes from 5
|7| READ: read 5 bytes from 5
|7| - 80 4c 01 03 01
|7| RB: Have 0 bytes into buffer. Adding 5 bytes.
|7| RB: Requested 5 bytes
|4| REC[8070cf0]: V2 packet received. Length: 76
|4| REC[8070cf0]: Expected Packet[0] Handshake(22) with length: 1
|4| REC[8070cf0]: Received Packet[0] Handshake(22) with length: 76
|7| READ: Got 73 bytes from 5
|7| READ: read 73 bytes from 5
|7| - 00 33 00 00 00 10 00 00 04 00 00 05 00 00 0a 01
|7| 0001 - 00 80 07 00 c0 03 00 80 00 00 09 06 00 40 00 00
|7| 0002 - 64 00 00 62 00 00 03 00 00 06 02 00 80 04 00 80
|7| 0003 - 00 00 13 00 00 12 00 00 63 7d 3c 1c 87 9d 8c fb
|7| 0004 - 50 fe 8e 10 c8 29 d2 32 af
|7| RB: Have 5 bytes into buffer. Adding 73 bytes.
|7| RB: Requested 78 bytes
|4| REC[8070cf0]: Decrypted Packet[0] Handshake(22) with length: 76
|6| BUF[HSK]: Inserted 76 bytes of Data(22)
|6| BUF[REC][HD]: Read 1 bytes of Data(22)
|3| HSK[8070cf0]: CLIENT HELLO(v2) was received [76 bytes]
|6| BUF[REC][HD]: Read 75 bytes of Data(22)
|6| BUF[HSK]: Peeked 0 bytes of Data
|6| BUF[HSK]: Emptied buffer
|6| BUF[HSK]: Inserted 1 bytes of Data
|6| BUF[HSK]: Inserted 75 bytes of Data
|3| HSK[8070cf0]: SSL 2.0 Hello: Client's version: 3.1
|3| HSK[8070cf0]: Parsing a version 2.0 client hello.
|2| ASSERT: gnutls_handshake.c:2674
|3| HSK[8070cf0]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|2| ASSERT: gnutls_handshake.c:2674
|3| HSK[8070cf0]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|2| ASSERT: gnutls_handshake.c:2674
|3| HSK[8070cf0]: Removing ciphersuite: ANON_DH_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|3| HSK[8070cf0]: Removing ciphersuite: RSA_ARCFOUR_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: RSA_ARCFOUR_MD5
|3| HSK[8070cf0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1
|3| HSK[8070cf0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1
|2| ASSERT: gnutls_handshake.c:632
|2| ASSERT: gnutls_v2_compat.c:181
|2| ASSERT: gnutls_handshake.c:1952
|2| ASSERT: gnutls_handshake.c:2415
|6| BUF[HSK]: Cleared Data from buffer
Error in handshake
Error: Could not negotiate a supported cipher suite.
|4| REC: Sending Alert[2|40] - Handshake failed
|4| REC[8070cf0]: Sending Packet[0] Alert(21) with length: 2
|7| WRITE: Will write 7 bytes to 5.
|7| WRITE: wrote 7 bytes to 5. Left 0 bytes. Total 7 bytes.
|7| - 15 03 01 00 02 02 28
|4| REC[8070cf0]: Sent Packet[1] Alert(21) with length: 7
|2| ASSERT: gnutls_record.c:242
Exiting via signal 2
www:~#
Kind Regards
AndrewM
Andrew McGlashan
Broadband Solutions now including VoIP
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
..sR.. 0010 - e5 72 73 54 bc 96 .rsT.. write to 0x80c0e90 [0x80cad28] (22 bytes = 22 (0x16)) - 17 03 01 00 11 25 61 98-4a 2d 71 8c f1 d4 43 2f .%a.J-q...C/ 0010 - 68 95 95 b1 d3 9a h. write to 0x80c0e90 [0x80cad28] (22 bytes = 22 (0x16)) - 17 03 01 00 11 80 3a 80-6f 72 d0 c9 89 24 39 57 ..:.or...$9W 0010 - 07 24 cd 9d 6e 67 .$..ng write to 0x80c0e90 [0x80cad28] (22 bytes = 22 (0x16)) - 17 03 01 00 11 b4 2c 61-c9 59 92 62 c8 3b 31 ed ..,a.Y.b.;1. 0010 - 9a b0 2f ba ef 57 ../..W write to 0x80c0e90 [0x80cad28] (22 bytes = 22 (0x16)) - 17 03 01 00 11 7b 94 2b-a5 b0 e2 40 a6 b7 3b 20 [EMAIL PROTECTED]; 0010 - 4a 59 1c 5f 02 32 JY._.2 read from 0x80c0e90 [0x80c6518] (5 bytes = 0 (0x0)) ERROR shutting down SSL CONNECTION CLOSED ACCEPT www:~# = gnutls-serv --port 4465 --debug 4711 \ --x509certfile /usr/share/ssl-cert/CAcert.pem \ --x509keyfile /usr/share/ssl-cert/ca.key \ --x509cafile /etc/ssl/certs/ca.pem www:~# gnutls-serv --port 4465 --debug 4711 \ --x509certfile /usr/share/ssl-cert/CAcert.pem \ --x509keyfile /usr/share/ssl-cert/ca.key \ --x509cafile /etc/ssl/certs/ca.pem Processed 1 CA certificate(s). |2| ASSERT: x509_b64.c:514 |2| ASSERT: x509_b64.c:447 |2| Could not find '-BEGIN DSA PRIVATE KEY' |2| ASSERT: privkey.c:397 |2| ASSERT: gnutls_x509.c:686 |2| ASSERT: gnutls_x509.c:733 Error reading '/usr/share/ssl-cert/CAcert.pem' or '/usr/share/ssl-cert/ca.key' Error: Base64 decoding error. = Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
Simon Josefsson wrote: How does your exim TLS configuration look like? Is it really using the same filenames? Sorry, I am guessing on the ca.pem file -- but the other two (cert and key) are in my config as follows: MAIN_TLS_CERTIFICATE = CONFDIR/exim.crt MAIN_TLS_PRIVATEKEY = CONFDIR/exim.key www:~# openssl s_server -accept 4465 -debug -msg \ -cert /etc/exim4/exim.crt \ -key/etc/exim4/exim.key \ -CAfile /etc/ssl/certs/ca.pem Using default temp DH parameters Using default temp ECDH parameters ACCEPT bad gethostbyaddr read from 0x80c0eb8 [0x80c6540] (11 bytes = 11 (0xB)) - 80 4c 01 03 01 00 33 00-00 00 10 .L3 read from 0x80c0eb8 [0x80c654b] (67 bytes = 67 (0x43)) - 00 00 04 00 00 05 00 00-0a 01 00 80 07 00 c0 03 0010 - 00 80 00 00 09 06 00 40-00 00 64 00 00 62 00 00 [EMAIL PROTECTED] 0020 - 03 00 00 06 02 00 80 04-00 80 00 00 13 00 00 12 0030 - 00 00 63 4f fc 7e 56 50-47 39 1c 9f 4c 6d da cd ..cO.~VPG9..Lm.. 0040 - 13 39 05 .9. SSL 2.0 [length 004c], CLIENT-HELLO 01 03 01 00 33 00 00 00 10 00 00 04 00 00 05 00 00 0a 01 00 80 07 00 c0 03 00 80 00 00 09 06 00 40 00 00 64 00 00 62 00 00 03 00 00 06 02 00 80 04 00 80 00 00 13 00 00 12 00 00 63 4f fc 7e 56 50 47 39 1c 9f 4c 6d da cd 13 39 05 TLS 1.0 Handshake [length 004a], ServerHello 02 00 00 46 03 01 47 81 11 5a ad 8b 1a 4d 06 46 71 7d fc ef 96 32 c3 79 ba 9d f9 bc 3d 32 71 35 3e 1d 17 41 51 de 20 01 f8 34 0f 89 a2 45 82 1b 2b 5f 85 8e 28 7d 3e f6 10 fc fd 4f ab 1d 24 97 f8 e9 ac 5e 27 a3 ae 00 04 00 write to 0x80c0eb8 [0x80d0708] (79 bytes = 79 (0x4F)) - 16 03 01 00 4a 02 00 00-46 03 01 47 81 11 5a ad J...F..G..Z. 0010 - 8b 1a 4d 06 46 71 7d fc-ef 96 32 c3 79 ba 9d f9 ..M.Fq}...2.y... 0020 - bc 3d 32 71 35 3e 1d 17-41 51 de 20 01 f8 34 0f .=2q5..AQ. ..4. 0030 - 89 a2 45 82 1b 2b 5f 85-8e 28 7d 3e f6 10 fc fd ..E..+_..(} 0040 - 4f ab 1d 24 97 f8 e9 ac-5e 27 a3 ae 00 04 O..$^' 004f - SPACES/NULS TLS 1.0 Handshake [length 0394], Certificate 0b 00 03 90 00 03 8d 00 03 8a 30 82 03 86 30 82 02 6e a0 03 02 01 02 02 01 03 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 30 2c 31 2a 30 28 06 03 55 04 03 13 21 41 66 66 69 6e 69 74 79 20 56 69 73 69 6f 6e 20 41 75 73 74 72 61 6c 69 61 20 50 74 79 20 4c 74 64 30 1e 17 0d 30 37 31 30 32 35 31 31 31 31 30 36 5a 17 0d 31 37 31 30 32 32 31 31 31 31 30 36 5a 30 25 31 23 30 21 06 03 55 04 03 13 1a 6d 61 69 6c 2e 61 66 66 69 6e 69 74 79 76 69 73 69 6f 6e 2e 63 6f 6d 2e 61 75 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 de cd 38 50 1a ea be f7 b9 90 45 28 8e 60 61 2d 11 8d e5 8c 9b af 26 a3 27 ce 0b 7b 0a bc b3 5b 6a 3d d8 8a 4c 8e 57 64 b1 7e fd bc 08 04 4d c1 33 90 75 57 bd da 74 dc 37 53 e1 9e 76 8f 46 fd 71 dc c0 47 ff 33 87 44 8c df 69 7b 8f 57 5a 8d f1 50 2d 0f f7 0d e0 21 94 cc c0 b7 c6 2f 6c d8 e7 bd 2b b3 4d e3 7c 95 1a 59 8f 10 93 8d 83 15 65 d8 45 ec ce 0d 71 98 ec 67 c6 70 c1 6b 04 49 5a 82 09 8f 7d 29 70 d5 36 06 01 b7 e6 55 f6 18 f8 4a f0 8d 3c b9 f3 ea 9a 71 f0 ac 34 6e a5 ee d9 55 19 d3 fa 48 ec ac a0 6b ac 9f 4d 5e de fe c9 a3 30 23 20 66 41 bf ea 7d 95 92 95 eb 6c 38 24 fd b9 2e 7b d2 05 98 c7 cd 4d 1e 75 2c f2 40 99 a3 be d3 8b 73 ba a3 7b 9e ce 1c 39 2b d8 6e de 1b b3 b5 17 3b 93 86 64 44 e7 53 99 51 e5 5d 09 2e 4c fc 50 ab e9 d2 db ac 21 82 3b bf c4 57 02 03 01 00 01 a3 81 b9 30 81 b6 30 09 06 03 55 1d 13 04 02 30 00 30 2c 06 09 60 86 48 01 86 f8 42 01 0d 04 1f 16 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 65 64 20 43 65 72 74 69 66 69 63 61 74 65 30 1d 06 03 55 1d 0e 04 16 04 14 f1 67 c2 9f f3 3c 13 0e 07 ca bf 2a 2b 6a 1b f4 d3 08 d8 44 30 5c 06 03 55 1d 23 04 55 30 53 80 14 6b df 0e b6 f3 d6 f7 bb 93 aa 4e 9f 35 c6 bf 58 a8 55 1c 0a a1 30 a4 2e 30 2c 31 2a 30 28 06 03 55 04 03 13 21 41 66 66 69 6e 69 74 79 20 56 69 73 69 6f 6e 20 41 75 73 74 72 61 6c 69 61 20 50 74 79 20 4c 74 64 82 09 00 c9 1f f0 0c f2 80 dc 8b 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 03 82 01 01 00 0a c9 24 45 51 0f ba 2d f1 e0 3c 31 fa 05 97 bc 1e 8f 7a 11 1e 34 36 47 77 8f 9e e2 e2 1b 25 56 97 ce 6c c1 57 ba 6f fb 13 9e bb 95 83 b3 d4 e4 5c c5 7f e9 75 06 3a 41 c7 bc 50 ba 8c f8 e7 49 50 b0 da 57 cf 40 11 cc b3 71 c1 65 1d f6 de 7f 41 59 15 42 5a ab d5 a7 a3 38 e9 5a 41 a7 a5 84 a4 11 d5 88 81 fe f5 7a f4 53 2d c4 51 3e ed 0d eb 9d a8 06 a7 3a 42 c0 d0 9e be 22 38 ef 60 37 47 9b 56 84 76 d6 6d 16 9c 0c f8 d2 d8 01 7f 92 fc dc e1 e2 ef 87 95 da a1 c1 d5 18 e8 94 bf 72 92 9e 14 29 fa 89 8e 32 4d d7 44 97 78 6b 0c 29 3c 80 5f 86 57 04 1e a3 a6 e6 01 50 af 26 f0 22 ea d9 fc bf 3d 86 b4 8e 47 0d 27 55 4d 40 e7 c8 20 7e 7b ea f7 a0 77 b3 1c 36 a3 17 c4 63 e1 08 24 1a 6d ec e8 47 e4 73 34 81 6b 30 c1 c3 bf ff
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
Simon Josefsson wrote: Thanks. Great. I suspect the problem is the same as for TheBat, i.e., that GnuTLS sends a certificate request and IM can't handle it. Can you try to add --disable-client-cert to: www:~# gnutls-serv --port 4465 --debug 4711 \ --x509certfile /etc/exim4/exim.crt \ --x509keyfile /etc/exim4/exim.key \ --x509cafile /etc/ssl/certs/ca.pem www:~# gnutls-serv --port 4465 --debug 4711 \ --disable-client-cert \ --x509certfile /etc/exim4/exim.crt \ --x509keyfile /etc/exim4/exim.key \ --x509cafile /etc/ssl/certs/ca.pem Invalid option 'disable-client-cert' Error in the arguments. Use the --help or -h parameters to get more information. www:~# www:~# gnutls-serv -h GNU TLS test server Usage: gnutls-serv [options] -d, --debug integer Enable debugging -g, --generate Generate Diffie Hellman Parameters. -p, --port integer The port to connect to. -q, --quiet Suppress some messages. --nodb Does not use the resume database. --http Act as an HTTP Server. --echo Act as an Echo Server. --dhparams FILE DH params file to use. --x509fmtder Use DER format for certificates --x509cafile FILECertificate file to use. --x509crlfile FILE CRL file to use. --pgpkeyring FILEPGP Key ring file to use. --pgptrustdb FILEPGP trustdb file to use. --pgpkeyfile FILEPGP Key file to use. --pgpcertfile FILE PGP Public Key (certificate) file to use. --x509keyfile FILE X.509 key file to use. --x509certfile FILE X.509 Certificate file to use. --x509dsakeyfile FILEAlternative X.509 key file to use. --x509dsacertfile FILE Alternative X.509 certificate file to use. --require-cert Require a valid certificate. --pskpasswd FILE PSK password file to use. --srppasswd FILE SRP password file to use. --srppasswdconf FILE SRP password conf file to use. --ciphers cipher1 cipher2... Ciphers to enable. --protocols protocol1 protocol2... Protocols to enable. --comp comp1 comp2...Compression methods to enable. --macs mac1 mac2... MACs to enable. --kx kx1 kx2... Key exchange methods to enable. --ctypes certType1 certType2... Certificate types to enable. -l, --list Print a list of the supported algorithms and modes. -h, --help prints this help -v, --versionprints the program's version number --copyright prints the program's license www:~# Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
Andrew McGlashan wrote: www:~# gnutls-serv -h GNU TLS test server Usage: gnutls-serv [options] www:~# gnutls-serv -v GNU TLS test server, version 1.4.4. Libgnutls 1.4.4. www:~# /AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Hi, Marc Haber wrote: I am having a problem with your port references. It would be more helpful if you'd not only reference the port number (which is most probably irrelevant for debugging), but also the protocol you're using. I feel that we are mixing up plain unencrypted SMTP (which usually runs on ports tcp/25 and/or tcp/587), the ESMTP STARTTLS extension (which also runs on ports tcp/25 and/or tcp/587 and is negotiated in a clear text handshake involving the EHLO and STARTTLS commands), and the non-standardized SMTP over SSL protocol which microsoft and other sites use on port tcp/465. I believe that I am using ESMTP STARTTLS. If Exim can use whatever qpopper is using for the SSL setup, then that would probably solve the problem. qpopper is using OpenSSL, which I'd like to avoid for exim since exim links to a gazillion of other libraries and I'd rather not have to check all their licenses for an OpenSSL exception. Additionally, Simon is member of the GnuTLS team and surely would not want to advocate changing to a competitor. I understand, but it _seems_ that OpenSSL works whilst GnuTLS doesn't but I can't be sure as I probably don't understand enough to properly debug the issue amongst other things I need to do. Is there a good step by step process that I could follow to help this cause? Would a copy (privately) of my /var/lib/exim4/config.autogenerated help? Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 8790 1224 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Marc Haber wrote: So you only have ssl_on_connect_port=465 in your exim configuration and no other port number? And you get a clear text banner when you connect to tcp/25 or tcp/587? And you get a banner when you use gnutls-cli -p 465 _without_ the -s option? www:/tmp# grep ssl_on_connect_port /var/lib/exim4/config.autogenerated - so no ssl_on_connect_port entry in my config... But I do have the following: www:/tmp# grep 587 /var/lib/exim4/config.autogenerated tls_on_connect_ports=465:587 www:/tmp# gnutls-cli -p 465 127.0.0.1 Resolving '127.0.0.1'... Connecting to '127.0.0.1:465'... - Successfully sent 0 certificate(s) to server. - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate does NOT match '127.0.0.1'. # valid since: Thu Oct 25 21:11:06 EST 2007 # expires at: Sun Oct 22 22:11:06 EST 2017 # fingerprint: F6:9D:DB:E5:BC:EA:59:CC:F4:81:0A:D1:56:81:11:1E # Subject's DN: CN=mail.affinityvision.com.au # Issuer's DN: CN=Affinity Vision Australia Pty Ltd - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: DHE RSA - Cipher: AES 256 CBC - MAC: SHA - Compression: NULL - Handshake was completed - Simple Client Mode: 220 mail.affinityvision.com.au ESMTP Exim 4.63 Sat, 05 Jan 2008 21:23:56 +1100 I understand, but it _seems_ that OpenSSL works whilst GnuTLS doesn't yes, and if we don't find out why, it's going to stay this way. I find it worth trying to find out where the issue with GnuTLS is, and GnuTLS upstream has become very responsive and motivated in the last few weeks (btw, I really really appreciate that). So do I really appreciate it! I must admit that I have lost the overview over this bug report. If I recall correctly, Simon is running an incredimail evaluation copy under wine and can do any debugging on the library side that might be possible. If I recall correctly, again, he has found out that incredimail negotiates an obsolete version of SSL whose ciphers can easily be broken and might be inable to negotiatate a better version. Under these circumstances, I remember him writing, it might be better not to use encryption at all. Interesting, but I cam at it a bit later. I have a client whom I want to host DNS and email for, but he wants to use IM and that is the only blocking factor. He isn't interested in using any other email program, but given that IM is actually quite popular, it is going to continue to be a problem if it isn't sorted. Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459323: exim4: Incredimail problem sending email using Exim4 SMTP over SSL / TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received.
Package: exim4 Version: 4.63-17 Severity: normal How to reproduce this problem. Setup email on Windows XP Pro using Outlook Express as follows. General tab: mail account: testaccount user information: name: whatever email address: valid email address Servers tab: standard setup for pop but with My server requires authenticaiton checked Outgoing mail server settings, Use same settings as my incoming mail server Advanced tab: Server port numbers: Outgoing 465 with SSL Incoming 995 with SSL Once the above is setup okay and tested, close Outlook Express. Install Incredimail [custom without extras checked], it should automatically take the settings from the Outlook Express setup. Now when sending an email using Incredimail, you get this popup: Failed to connect the outgoing server: 'outgoing server name' Please try again later. Clicking on Details gives this information: SocketError: -2146885628 , Port: 465, Protocol: SMTP.Cannot find object or property. On the Debian mail server, you see the following in the /var/log/exim4/mainlog file: TLS error on connection from [ip.ad.dr.ess] (gnutls_handshake): A TLS packet with unexpected length was received. -- Package-specific info: Exim version 4.63 #1 built 20-Jan-2007 10:42:32 Copyright (c) University of Cambridge 2006 Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 6, 2005) Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages Content_Scanning Old_Demime Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl plaintext spa Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' dc_eximconfig_configtype='internet' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='true' #dc_relay_nets='192.168.0.0/24:192.168.2.0/24' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:mail.affinityvision.com.au -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-p4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages exim4 depends on: ii debconf [debconf-2.0]1.5.11etch1 Debian configuration management sy ii exim4-base 4.63-17 support files for all exim MTA (v4 ii exim4-daemon-heavy 4.63-17 exim MTA (v4) daemon with extended exim4 recommends no packages. -- debconf information: exim4/drec: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Hi, I tried adjusting my exim4 config by setting MAIN_TLS_ENABLE to false and restarting exim4. OE still worked fine with SMTP Auth, but IM [with all it's crud in the registry btw, which is another matter], still failed exactly the same. So for me it isn't, I don't think, anything to do with my mail server settings. So I reverted back to my original setting of true for MAIN_TLS_ENABLE. Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 8790 1224 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Hi Simon, Simon Josefsson wrote: Thanks for prompt feedback, Andrew! You are most welcome. My reading from this is that we can close the IM related part of this bug report. Perhaps. There is clearly still some problem between IM and Exim, but that could be the topic for another report? It would be interesting if you could identify whether it is related to exim (i.e., does it happen with sendmail too?) or gnutls (i.e., does it happen if exim4 is linked with openssl?). Part of the problem relates to my server having a strict requirement to use SSL with SMTP Auth. Popping email using SSL on port 995 works fine using qpopper. Gmail works fine with SSL on port 465. So the combination of these observations points to an Exim issue... from what I can tell. Although Outlook Express works fine with both my server and a gmail one both using SSL over port 465. If Exim can use whatever qpopper is using for the SSL setup, then that would probably solve the problem. Anyway, to reduce the complexity of this bug report, I think it would be very good, if you still wish to debug this, to report the problem anew, for the component you think is causing the problem. It might even be a IM bug.. IM are useless in terms of support. Often they say that they were getting a zero length email and to use plain text. Well I ONLY use plain text and none of the responses were zero bytes in length. So their support is broken too. IM adds so much garbage into the Windows registry that I did a restore to an older image to get rid of it properly -- did some fresh tests with a new install which was fruitless and then restored my older image again. Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 8790 1224 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Marc Haber wrote: After thinking for a while, why did your incredimail not complain about the server not presenting a certificate? It was dropping out with the error as given already with no hint of any certificate issue. I have my own ca.crt certificate installed in the trusted root in order to stop questions about a certificate that I already trust (or others made by myself). Please try again and give gnutls-serv the same certificate that your exim also uses. For reference, you might want to try openssl: Tried this: # gnutls-serv -d 5 -p 588 \ --x509certfile /etc/exim4/exim.crt \ --x509keyfile /etc/exim4/exim.key Failed in the same manner, IM gave immediate error and quit trying to send. On my Debian box: Echo Server ready. Listening to port '588'. |4| REC[80738b0]: V2 packet received. Length: 76 |4| REC[80738b0]: Expected Packet[0] Handshake(22) with length: 1 |4| REC[80738b0]: Received Packet[0] Handshake(22) with length: 76 |4| REC[80738b0]: Decrypted Packet[0] Handshake(22) with length: 76 |3| HSK[80738b0]: CLIENT HELLO(v2) was received [76 bytes] |3| HSK[80738b0]: SSL 2.0 Hello: Client's version: 3.1 |3| HSK[80738b0]: Parsing a version 2.0 client hello. |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[80738b0]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5 |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[80738b0]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[80738b0]: Removing ciphersuite: ANON_DH_AES_128_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |3| HSK[80738b0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |3| HSK[80738b0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Keeping ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |3| HSK[80738b0]: Keeping ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |3| HSK[80738b0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[80738b0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[80738b0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |2| ASSERT: gnutls_handshake.c:2664 |3| HSK[80738b0]: Removing ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5 |3| HSK[80738b0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |3| HSK[80738b0]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |3| HSK[80738b0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |3| HSK[80738b0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |3| HSK[80738b0]: Selected cipher suite: RSA_ARCFOUR_MD5 |2| ASSERT: gnutls_db.c:327 |2| ASSERT: gnutls_db.c:247 |3| HSK[80738b0]: SessionID: dd9ee262aef8cf92e30193819a8a13ea830a19326bf476e36260acac5c605c97 |3| HSK[80738b0]: SERVER HELLO was send [74 bytes] |4| REC[80738b0]: Sending Packet[0] Handshake(22) with length: 74 |4| REC[80738b0]: Sent Packet[1] Handshake(22) with length: 79 |3| HSK[80738b0]: CERTIFICATE was send [916 bytes] |4| REC[80738b0]: Sending Packet[1] Handshake(22) with length: 916 |4| REC[80738b0]: Sent Packet[2] Handshake(22) with length: 921 |3| HSK[80738b0]: CERTIFICATE REQUEST was send [9 bytes] |4| REC[80738b0]: Sending Packet[2] Handshake(22) with length: 9 |4| REC[80738b0]: Sent Packet[3] Handshake(22) with length: 14 |3| HSK[80738b0]: SERVER HELLO DONE was send [4 bytes] |4| REC[80738b0]: Sending Packet[3] Handshake(22) with length: 4 |4| REC[80738b0]: Sent Packet[4] Handshake(22) with length: 9 |2| ASSERT: gnutls_buffers.c:289 |2| ASSERT: gnutls_buffers.c:1087 |2| ASSERT: gnutls_handshake.c:949 |2| ASSERT: gnutls_buffers.c:565 |2| ASSERT: gnutls_record.c:891 |2| ASSERT: gnutls_buffers.c:1087 |2| ASSERT: gnutls_handshake.c:949 |2| ASSERT: gnutls_handshake.c:2463 Error in handshake Error: A TLS packet with unexpected length was received. |4| REC: Sending Alert[2|22] - Record overflow |4| REC[80738b0]: Sending Packet[4] Alert(21) with length: 2 |4| REC[80738b0]: Sent Packet[5] Alert(21) with length: 7 |2| ASSERT: gnutls_record.c:242 openssl s_server -cert /etc/exim4/tls/certs/exim.crt -key /etc/exim4/tls/key/exim.key -accept 588 -debug Using openssl: # openssl s_server \ -cert /etc/exim4/exim.crt \ -key /etc/exim4/exim.key \ -accept 588 -debug Causes IM to continually be stuck at 'connecting' at the 'securing' point. Last lines shown on Linux console [putty]: -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMBBAIABAQgE3hoE42fCVtNzS+IIc4qomwaLjHyA9LsHCXJkjcmmYYE data removed
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Marc Haber wrote: On Mon, Oct 29, 2007 at 02:14:19AM +1100, Andrew McGlashan wrote: Marc Haber wrote: You might want to use gnutls-serv as a test target against your incredimail client. Okay, well I set up port 588 for the test: # gnutls-serv -p 588 Echo Server ready. Listening to port '588'. Error in handshake Error: Could not negotiate a supported cipher suite. Please retry with -d 5 # gnutls-serv -p 588 -d 5 Echo Server ready. Listening to port '588'. |4| REC[8070cf0]: V2 packet received. Length: 76 |4| REC[8070cf0]: Expected Packet[0] Handshake(22) with length: 1 |4| REC[8070cf0]: Received Packet[0] Handshake(22) with length: 76 |4| REC[8070cf0]: Decrypted Packet[0] Handshake(22) with length: 76 |3| HSK[8070cf0]: CLIENT HELLO(v2) was received [76 bytes] |3| HSK[8070cf0]: SSL 2.0 Hello: Client's version: 3.1 |3| HSK[8070cf0]: Parsing a version 2.0 client hello. |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[8070cf0]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5 |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[8070cf0]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 |2| ASSERT: gnutls_handshake.c:2674 |3| HSK[8070cf0]: Removing ciphersuite: ANON_DH_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5 |3| HSK[8070cf0]: Removing ciphersuite: RSA_ARCFOUR_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: RSA_ARCFOUR_MD5 |3| HSK[8070cf0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 |3| HSK[8070cf0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 |2| ASSERT: gnutls_handshake.c:632 |2| ASSERT: gnutls_v2_compat.c:181 |2| ASSERT: gnutls_handshake.c:1952 |2| ASSERT: gnutls_handshake.c:2415 Error in handshake Error: Could not negotiate a supported cipher suite. |4| REC: Sending Alert[2|40] - Handshake failed |4| REC[8070cf0]: Sending Packet[0] Alert(21) with length: 2 |4| REC[8070cf0]: Sent Packet[1] Alert(21) with length: 7 |2| ASSERT: gnutls_record.c:242 Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Hi Marc, Marc Haber wrote: I prefer to stick with standard packages as supplied by apt package management I am not interested in doing any re-compiles and moving too far away from the standards that are currently in place. Then you're out of luck. Okay well I'll persevere if I can with some more information. I want to be able to support the use of Incredimail against my mail server without departing from my strict policy of using SMTP Auth over port 465 with SSL security. Port 465 is an RFC violation anyway, it was never assigned for SMTP over SSL in the first place. Microsoft is the only instance who insists on using this non-standard. I have just re-configured my server to accept 25 / 265 and 587 for SSL/TLS connections. 03_exim4-config_tlsoptions: tls_on_connect_ports=465:587 AND in /etc/default/exim4 SMTPLISTENEROPTIONS='-oX 587:465:25 -oP /var/run/exim4/exim.pid' Now I can send using port 25 or 465 both with SSL with OE, but 587 with OE times out and eventually gives the same error on the server as does IncrediMail -- although IM does it almost immediately. Leaving the port at 25 is not acceptable because any old wireless hotspot will interfere with my direct SMTP Auth connections by hijacking the port 25 traffic and using their own sending mail servers. I don't know why port 587 with SSL isn't working with OE though. By default if you select SSL for outgoing mail server with OE, then it uses port 25 -- this has to be changed to 465 in my case to work as I prefer. GMAIL also breaks the RFC then as they only use port 465 The widely accepted standardized way to do secure SMTP is STARTTLS, which is kind of SMTP-over-SSL-over-SMTP and can be run on the standardized ports 25 (SMTP) and 587 (mail submission). But you are likely to fall into the same trap with your incredimail that way. IM will not work on port 25, 465 or 587. On my server, I can see the following: # netstat -an|grep -e 25 -e 465 -e 587|grep tcp tcp0 0 0.0.0.0:587 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:465 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp0 0 192.168.2.2:25 80.161.186.2:63657 TIME_WAIT And when OE is 'waiting' on port 587 tests: # netstat -an|grep -e 25 -e 465 -e 587|grep tcp tcp0 0 0.0.0.0:587 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:465 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp0 0 192.168.2.2:587 192.168.0.158:2854 ESTABLISHED When I give up on the waiting, the following is sent to /var/log/exim4/mainlog: 2007-10-29 02:06:07 TLS error on connection from [192.168.0.158] (gnutls_handshake): A TLS packet with unexpected length was received Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Marc Haber wrote: You might want to use gnutls-serv as a test target against your incredimail client. Okay, well I set up port 588 for the test: # gnutls-serv -p 588 Echo Server ready. Listening to port '588'. Error in handshake Error: Could not negotiate a supported cipher suite. Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Hi Marc, Marc Haber wrote: On Sat, Oct 27, 2007 at 03:29:47PM +1000, Andrew McGlashan wrote: I have just discovered this bug and it appears to be rather long term. any progress? This will most probably not be fixed in etch. :( What is Incredimail? An MTA, or a Mail service? Incredimail is an email client [MUA], much like Outlook Express, but it is heavily used in the Windows world. FWIW, I don't like Incredimail, however, I have a client whom does like it and I want to host his email -- the problem is the TLS handling as I enforce SMTP Auth usage and only with port 465 with SSL. And if so, is there any way that the Exim4 can work with both OpenSSL and GNUTLS? You can recompile the packages with OpenSSL. I prefer to stick with standard packages as supplied by apt package management I am not interested in doing any re-compiles and moving too far away from the standards that are currently in place. However, if a special package was made available in the normal way, then I would be happy to install it -- so long as it is maintained as a 'normal' package would be. Would it be safe and advisable to provide the output from the gnutls-cli-debug program here? gnutls-cli-debug --port 465 -v localhost -d 3 Probably not since we know that a gnutls client will work nicely with exim. I am guessing that if OpenSSL is used by an MUA, then it too might fail similarly. I kind of fail to understand what you intend to do and what works and what not. I want to be able to support the use of Incredimail against my mail server without departing from my strict policy of using SMTP Auth over port 465 with SSL security. Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Receiving mail via POPS on port 995 with SSL works fine with Incredimail [and other tried MUAs] but that is using openssl through qpopper to get the mail. Extract from /var/log/mail.info : Oct 26 11:56:36 www in.qpopper[15103]: (v4.0.5) TLSv1/SSLv3 handshake with client at XX..x.net.au (ip.ad.dr.ess); new session-id; cipher: RC4-MD5 (RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 ), 128 bits [pop_tls_openssl.c:543] So... we either need Incredimail to support GNUTLS or we need Exim4 to include support for the data formats / handshaking as used by openssl. It would seem that gmail most probably uses openssl and that is why it works with Incredimail. Kind Regards AndrewM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.
Hi, I have just discovered this bug and it appears to be rather long term. any progress? Some further information: SMTP Auth issue with Incredimail using Exim, but not with Gmail... - SSL over 465 works fine for Outlook Express; - same machine if running Incredimail fails with msg as per this bug report. I wonder if Incredimail uses OpenSSL? And if so, is there any way that the Exim4 can work with both OpenSSL and GNUTLS? My version details: Exim version 4.63 #1 built 20-Jan-2007 10:42:32 Copyright (c) University of Cambridge 2006 Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 6, 2005) Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages Content_Scanning Old_Demime Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl plaintext spa Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated Would it be safe and advisable to provide the output from the gnutls-cli-debug program here? gnutls-cli-debug --port 465 -v localhost -d 3 [I only use port 465 with SSL/TLS] Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 8790 1224 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
