Debian Bug report logs - #348046
multiple GnuTLS issues - please only add information to blocking bugs - see message #371

Package: exim4-daemon-heavy; Maintainer for exim4-daemon-heavy is Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>; Source for exim4-daemon-heavy is src:exim4 (PTS, buildd, popcon).

Reported by: martin@hinterlands.org

Date: Sat, 14 Jan 2006 12:03:06 UTC

Severity: important

Found in versions exim4-daemon-heavy/4.60-1, exim4-daemon-heavy/4.50-8, exim4/4.63-17, exim4/4.80-9

Done: Marc Haber <mh+debian-packages@zugschlus.de>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to "Martin A. Brooks" <martin@winter.hinterlands.org>:
New Bug report received and forwarded. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: exim4-daemon-heavy
Version: 4.60-1
Severity: important

Hi

A newly install exim4 server produces the following error during any TLS
connection:

2006-01-14 11:57:13 TLS error on connection from (parken) [195.1.19.x]
(gnutls_handshake): A TLS packet with unexpected length was received.
2006-01-14 11:57:13 TLS error on connection from (parken) [195.1.19.x]
(gnutls_handshake): A TLS packet with unexpected length was received.

Disabling TLS delivery attempts by adding "hosts_avoid_tls = *" to the
remote_smtp driver alleviates the problem, but obviously disables TLS
entirely.

Regards

Martin A. Brooks

-- Package-specific info:
Exim version 4.60 #1 built 28-Nov-2005 18:19:31
Copyright (c) University of Cambridge 2005
Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
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
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
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.2
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages exim4-daemon-heavy depends on:
ii  exim4-base                    4.60-1     support files for all exim MTA (v4
ii  libc6                         2.3.5-8    GNU C Library: Shared libraries an
ii  libdb4.2                      4.2.52-23  Berkeley v4.2 Database Libraries [
ii  libgnutls12                   1.2.9-2    the GNU TLS library - runtime libr
ii  libldap2                      2.1.30-12  OpenLDAP libraries
ii  libmysqlclient14              4.1.15-1   mysql database client library
ii  libpam0g                      0.79-3     Pluggable Authentication Modules l
ii  libpcre3                      6.4-1.1    Perl 5 Compatible Regular Expressi
ii  libperl5.8                    5.8.7-10   Shared Perl library
ii  libpq4                        8.1.0-3    PostgreSQL C client library
ii  libsasl2                      2.1.19-1.7 Authentication abstraction library

exim4-daemon-heavy recommends no packages.

-- no debconf information

Information forwarded to debian-bugs-dist@lists.debian.org, Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #10 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sat, Jan 14, 2006 at 12:59:25PM +0100, Martin A. Brooks wrote:
> A newly install exim4 server produces the following error during any TLS
> connection:
> 
> 2006-01-14 11:57:13 TLS error on connection from (parken) [195.1.19.x]
> (gnutls_handshake): A TLS packet with unexpected length was received.
> 2006-01-14 11:57:13 TLS error on connection from (parken) [195.1.19.x]
> (gnutls_handshake): A TLS packet with unexpected length was received.

Is your exim working as a client, or as a server?
Does this really happen to _all_ remote stations?
Do you have enough entropy?
Is this possibly a duplicate of #297174?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Acknowledgement sent to "Martin A. Brooks" <martin@hinterlands.org>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #15 received at 348046@bugs.debian.org (full text, mbox, reply):

Hi

I sent the bug report from the wrong machine, please note that my email 
address is martin@hinterlands.org not martin@winter.hinterlands.org

Is this case exim is working as a mailhub, it accepts mail and then 
relays it on to one of a few possible destinations.

This problems occurs for all the destinations available.

This certainly might be a dupe of #297174, the nature of this server 
means I cannot reasonably attempt to relink against the older gnutls 
library.  I'll need to put together a test system to try that.

It's possible that the machine has insufficient entropy, I'll have to 
admit that I have no idea how to check that this is or isn't the case.

Regards

Martin A. Brooks

Message #20 received at 348046@bugs.debian.org (full text, mbox, reply):

submitter #348046 martin@hinterlands.org
thanks

(submitter is now corrected in the Debian BTS)

On Sat, Jan 14, 2006 at 02:46:13PM +0100, Martin A. Brooks wrote:
> I sent the bug report from the wrong machine, please note that my email 
> address is martin@hinterlands.org not martin@winter.hinterlands.org

corrected.

> Is this case exim is working as a mailhub, it accepts mail and then 
> relays it on to one of a few possible destinations.
> 
> This problems occurs for all the destinations available.

Is there something common with these destinations? Is it possible to
add the zugschlus.de to the list of possible destinations and send a
test message to mh+debian-packages@zugschlus.de?

Can you try establishing a SMTP/STARTTLS session to these destinations
with swaks?

swaks --tls --server destination.host.name.example --to some.address@domain.example

Swaks uses OpenSSL. To test a gnutls client, we need to use gnutls-cli
(gnutls-cli -s -p 25 destination.host.name.example, and proceed to do
SMTP on that connection, take the swaks transaction as an example)

> This certainly might be a dupe of #297174, the nature of this server 
> means I cannot reasonably attempt to relink against the older gnutls 
> library. 

No need to try that. Let's first check with a different client (hence
my swaks/gnutls-cli suggestion) and a different server (hence my suggestion
with zugschlus.de)

> It's possible that the machine has insufficient entropy, I'll have to 
> admit that I have no idea how to check that this is or isn't the case.

cat /proc/sys/kernel/random/entropy_avail

The number can have a range between 4096 and 0, the higher the better.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Changed Bug submitter from "Martin A. Brooks" <martin@winter.hinterlands.org> to martin@hinterlands.org. Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (full text, mbox, link).

Message #27 received at 348046@bugs.debian.org (full text, mbox, reply):

Marc Haber wrote:
> Is there something common with these destinations? Is it possible to
> add the zugschlus.de to the list of possible destinations and send a
> test message to mh+debian-packages@zugschlus.de?

That's done, you should have got a test mail from the system involved. 
You can use this machine to send mails back to yourself if you'd like to 
test for yourself.

> swaks --tls --server destination.host.name.example --to some.address@domain.example

Done.

> cat /proc/sys/kernel/random/entropy_avail

This start at 4096 then drops sharply to <200 when a TLS session is 
initiated.  I've installed the rng-tools package, if this is an entropy 
starvation problem them this daemon might alleviate the problem.

Regards

Martin A. Brooks

Message #32 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sat, Jan 14, 2006 at 04:36:55PM +0100, Martin A. Brooks wrote:
> Marc Haber wrote:
> >Is there something common with these destinations? Is it possible to
> >add the zugschlus.de to the list of possible destinations and send a
> >test message to mh+debian-packages@zugschlus.de?
> 
> That's done, you should have got a test mail from the system involved. 

I didn't see it. At what time, and from which IP address should I have
received the message?

> You can use this machine to send mails back to yourself if you'd like to 
> test for yourself.

Which machine?

> >swaks --tls --server destination.host.name.example --to 
> >some.address@domain.example
> 
> Done.

Did it work?

Does gnutls-cli work as well?

> >cat /proc/sys/kernel/random/entropy_avail
> 
> This start at 4096 then drops sharply to <200 when a TLS session is 
> initiated.  I've installed the rng-tools package, if this is an entropy 
> starvation problem them this daemon might alleviate the problem.

Does the system have a hardware rng? If not, rng-tools is not going to
help.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message #37 received at 348046@bugs.debian.org (full text, mbox, reply):

user exim4@packages.debian.org
usertags #348046 close-20060430
thanks

On Sat, Jan 14, 2006 at 04:42:21PM +0100, Marc Haber wrote:
> On Sat, Jan 14, 2006 at 04:36:55PM +0100, Martin A. Brooks wrote:
> > Marc Haber wrote:
> > >Is there something common with these destinations? Is it possible to
> > >add the zugschlus.de to the list of possible destinations and send a
> > >test message to mh+debian-packages@zugschlus.de?
> > 
> > That's done, you should have got a test mail from the system involved. 
> 
> I didn't see it. At what time, and from which IP address should I have
> received the message?
> 
> > You can use this machine to send mails back to yourself if you'd like to 
> > test for yourself.
> 
> Which machine?
> 
> > >swaks --tls --server destination.host.name.example --to 
> > >some.address@domain.example
> > 
> > Done.
> 
> Did it work?
> 
> Does gnutls-cli work as well?
> 
> > >cat /proc/sys/kernel/random/entropy_avail
> > 
> > This start at 4096 then drops sharply to <200 when a TLS session is 
> > initiated.  I've installed the rng-tools package, if this is an entropy 
> > starvation problem them this daemon might alleviate the problem.
> 
> Does the system have a hardware rng? If not, rng-tools is not going to
> help.

May I remind answering these questions?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Acknowledgement sent to jarek <jarek@srv.pl>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #45 received at 348046@bugs.debian.org (full text, mbox, reply):

Package: exim4-daemon-heavy
Version: 4.50-8
Followup-For: Bug #348046


Almost every day, first few clients (M$ OE2003) can't send mails with
this error in mainlog.
It happends only 2-3 times, and after this everything works OK till next
day. 


-- Package-specific info:
Exim version 4.50 #1 built 27-May-2005 08:10:05
Copyright (c) University of Cambridge 2004
Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
Support for: iconv() IPv6 PAM Perl GnuTLS Content_Scanning Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql
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
Configuration file is /etc/exim4/exim4.conf
# /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'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to replace
# the DEBCONFsomethingDEBCONF strings in the configuration template files.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='satellite'
dc_other_hostnames='xxxxxxx'
dc_local_interfaces=''
dc_readhost='xxxxxxxxx'
dc_relay_domains=''
dc_minimaldns='true'
dc_relay_nets=''
dc_smarthost='mail'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
mailname:xxxxxxxxx

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.15.4
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

Versions of packages exim4-daemon-heavy depends on:
ii  exim4-base               4.50-8          support files for all exim MTA (v4
ii  libc6                    2.3.2.ds1-22    GNU C Library: Shared libraries an
ii  libdb4.2                 4.2.52-18       Berkeley v4.2 Database Libraries [
ii  libgnutls11              1.0.16-13.2     GNU TLS library - runtime library
ii  libldap2                 2.1.30-8        OpenLDAP libraries
ii  libmysqlclient12         4.0.24-10sarge1 mysql database client library
ii  libpam0g                 0.76-22         Pluggable Authentication Modules l
ii  libpcre3                 4.5-1.2sarge1   Perl 5 Compatible Regular Expressi
ii  libperl5.8               5.8.4-8sarge3   Shared Perl library
ii  libpq3                   7.4.7-6sarge1   PostgreSQL C client library
ii  libsasl2                 2.1.19-1.5      Authentication abstraction library

-- no debconf information

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>, 348046-quiet@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #50 received at 348046@bugs.debian.org (full text, mbox, reply):

user exim4@packages.debian.org
usertags #348046 gnutls
thanks

Usertagging this bug for gnutls. Please note that the original
submitter has become unresponsive months ago, so we'll have to debug
without his help.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Acknowledgement sent to Ian Zimmerman <nobrowser@gmail.com>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #58 received at 348046@bugs.debian.org (full text, mbox, reply):

I am not sure if this is the same problem, but with exim4-daemon-light 
version 4.62-2, TLS enabled (EHLO response lists STARTTLS), I try to
connect from localhost with openssl and I get this:

itz@madbat:/etc/exim4/conf.d$ telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 madbat.mine.nu ESMTP Exim 4.62 Tue, 25 Jul 2006 20:45:33 -0400
EHLO localhost
250-madbat.mine.nu Hello localhost [127.0.0.1]
250-SIZE 12582912
250-PIPELINING
250-STARTTLS
250 HELP
QUIT
221 madbat.mine.nu closing connection
Connection closed by foreign host.
itz@madbat:/etc/exim4/conf.d$ openssl s_client -connect 127.0.0.1:587 -starttls smtp
CONNECTED(00000003)
20025:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:567:
itz@madbat:/etc/exim4/conf.d$ 

(the same thing happens when I configure the normal port 25, of course).

-- 
A true pessimist won't be discouraged by a little success.

Message #63 received at 348046@bugs.debian.org (full text, mbox, reply):

So, now I tried with gnutls-bin, also interesting (?)

itz@madbat:/etc/exim4/conf.d$ gnutls-cli-debug --port 25 -v localhost -d 3
Resolving 'localhost'...
Connecting to '127.0.0.1:25'...
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[806f430]: CLIENT HELLO was send [57 bytes]
|<2>| ASSERT: gnutls_record.c:494
|<2>| ASSERT: gnutls_record.c:908
|<2>| ASSERT: gnutls_buffers.c:1087
|<2>| ASSERT: gnutls_handshake.c:949
|<2>| ASSERT: gnutls_handshake.c:2209
Checking for TLS 1.1 support... no
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[806f430]: CLIENT HELLO was send [57 bytes]
|<2>| ASSERT: gnutls_record.c:494
|<2>| ASSERT: gnutls_record.c:908
|<2>| ASSERT: gnutls_buffers.c:1087
|<2>| ASSERT: gnutls_handshake.c:949
|<2>| ASSERT: gnutls_handshake.c:2209
Checking fallback from TLS 1.1 to... failed
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[806f430]: CLIENT HELLO was send [57 bytes]
|<2>| ASSERT: gnutls_record.c:494
|<2>| ASSERT: gnutls_record.c:908
|<2>| ASSERT: gnutls_buffers.c:1087
|<2>| ASSERT: gnutls_handshake.c:949
|<2>| ASSERT: gnutls_handshake.c:2209
Checking for TLS 1.0 support... no
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[806f430]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|<3>| HSK[806f430]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[806f430]: CLIENT HELLO was send [55 bytes]
|<2>| ASSERT: gnutls_record.c:494
|<2>| ASSERT: gnutls_record.c:908
|<2>| ASSERT: gnutls_buffers.c:1087
|<2>| ASSERT: gnutls_handshake.c:949
|<2>| ASSERT: gnutls_handshake.c:2209
Checking for SSL 3.0 support... no

Server does not support none of SSL 3.0, TLS 1.0 and TLS 1.1
itz@madbat:/etc/exim4/conf.d$ 

-- 
A true pessimist won't be discouraged by a little success.

Message #68 received at 348046@bugs.debian.org (full text, mbox, reply):

On Tue, Jul 25, 2006 at 06:09:56PM -0700, Ian Zimmerman wrote:
> I am not sure if this is the same problem,

Possibly. Can you try answering the questions asked to the original
bug reporter in this bug thread?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message #73 received at 348046@bugs.debian.org (full text, mbox, reply):

On Tue, Jul 25, 2006 at 06:39:55PM -0700, Ian Zimmerman wrote:
> So, now I tried with gnutls-bin, also interesting (?)
> 
> itz@madbat:/etc/exim4/conf.d$ gnutls-cli-debug --port 25 -v localhost -d 3

You need the --starttls option.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Acknowledgement sent to "Ian Zimmerman" <nobrowser@gmail.com>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #78 received at 348046@bugs.debian.org (full text, mbox, reply):

On 7/26/06, Marc Haber <mh+debian-packages@zugschlus.de> wrote:
> On Tue, Jul 25, 2006 at 06:39:55PM -0700, Ian Zimmerman wrote:
> > So, now I tried with gnutls-bin, also interesting (?)
> >
> > itz@madbat:/etc/exim4/conf.d$ gnutls-cli-debug --port 25 -v localhost -d 3
>
> You need the --starttls option.

itz@madbat:~$ gnutls-cli-debug --port 587 -v localhost -d 3 --starttls
Invalid option 'starttls'
Error in the arguments. Use the -h or --help parameters to get more info.
itz@madbat:~$

Message #83 received at 348046@bugs.debian.org (full text, mbox, reply):

On Wed, Jul 26, 2006 at 11:35:22AM -0400, Ian Zimmerman wrote:
> On 7/26/06, Marc Haber <mh+debian-packages@zugschlus.de> wrote:
> >On Tue, Jul 25, 2006 at 06:39:55PM -0700, Ian Zimmerman wrote:
> >> So, now I tried with gnutls-bin, also interesting (?)
> >>
> >> itz@madbat:/etc/exim4/conf.d$ gnutls-cli-debug --port 25 -v localhost -d 
> >3
> >
> >You need the --starttls option.
> 
> itz@madbat:~$ gnutls-cli-debug --port 587 -v localhost -d 3 --starttls
> Invalid option 'starttls'
> Error in the arguments. Use the -h or --help parameters to get more info.
> itz@madbat:~$

Hm. Looks like gnutls-cli-debug cannot be used to debug STARTTLS
connects. Does hiking up gnutls-cli's debug level offer comparable
verbosity?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Acknowledgement sent to Ian Zimmerman <itz@madbat.mine.nu>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #88 received at 348046@bugs.debian.org (full text, mbox, reply):

Marc> Hm. Looks like gnutls-cli-debug cannot be used to debug STARTTLS
Marc> connects. Does hiking up gnutls-cli's debug level offer comparable
Marc> verbosity?

Not really :\

itz@ahiker:~$ gnutls-cli --port 25  -d 5 --starttls localhost
|<2>| ASSERT: gnutls_psk.c:101
Resolving 'localhost'...
Connecting to '127.0.0.1:25'...

- Simple Client Mode:

220 ahiker.homeip.net ESMTP Exim 4.62 Wed, 26 Jul 2006 22:08:04 -0400

I assume this is the initial unencrypted greeting.  It hangs here, have to
hit ^C, which is actually similar to my original attempt to send real mail
from one Exim to another, also hangs.  That's how I came to investigate
with openssl and you know the rest.

Exim TLS _client_ to a different TLS enabled MTA (postfix, which links to
openssl) works fine.

-- 
A true pessimist won't be discouraged by a little success.

Message #93 received at 348046@bugs.debian.org (full text, mbox, reply):

On Wed, Jul 26, 2006 at 10:15:28PM -0400, Ian Zimmerman wrote:
> Marc> Hm. Looks like gnutls-cli-debug cannot be used to debug STARTTLS
> Marc> connects. Does hiking up gnutls-cli's debug level offer comparable
> Marc> verbosity?
> 
> Not really :\
> 
> itz@ahiker:~$ gnutls-cli --port 25  -d 5 --starttls localhost
> |<2>| ASSERT: gnutls_psk.c:101
> Resolving 'localhost'...
> Connecting to '127.0.0.1:25'...
> 
> - Simple Client Mode:
> 
> 220 ahiker.homeip.net ESMTP Exim 4.62 Wed, 26 Jul 2006 22:08:04 -0400
> 
> I assume this is the initial unencrypted greeting.

Yes.

>   It hangs here, have to hit ^C,

You need to manually say STARTTLS, and then hit Ctrl-D to switch the
client to TLS mode.

>  which is actually similar to my original attempt to send real mail
>  from one Exim to another, also hangs.

Entropy available?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message #98 received at 348046@bugs.debian.org (full text, mbox, reply):

>> itz@ahiker:~$ gnutls-cli --port 25 -d 5 --starttls localhost |<2>|
>> ASSERT: gnutls_psk.c:101 Resolving 'localhost'...  Connecting to
>> '127.0.0.1:25'...
>> 
>> - Simple Client Mode:
>> 
>> 220 ahiker.homeip.net ESMTP Exim 4.62 Wed, 26 Jul 2006 22:08:04 -0400
>> 

Ian> It hangs here, have to hit ^C,

Marc> You need to manually say STARTTLS, and then hit Ctrl-D to switch
Marc> the client to TLS mode.

Okay, now gnutls-cli seems to work; immediately after, I try to connect
with openssl, still same error.

itz@madbat:~$ gnutls-cli --port 587  -d 5 --starttls localhost
|<2>| ASSERT: gnutls_psk.c:101
Resolving 'localhost'...
Connecting to '127.0.0.1:587'...

- Simple Client Mode:

220 madbat.mine.nu ESMTP Exim 4.62 Fri, 28 Jul 2006 00:05:49 -0400
EHLO localhost
250-madbat.mine.nu Hello localhost [127.0.0.1]
250-SIZE 10240000
250-PIPELINING
250-STARTTLS
250 HELP
STARTTLS
220 TLS go ahead
*** Starting TLS handshake
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[80714a8]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[80714a8]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5
|<2>| EXT[80714a8]: Sending extension CERT_TYPE
|<2>| EXT[80714a8]: Sending extension SERVER_NAME
|<3>| HSK[80714a8]: CLIENT HELLO was send [131 bytes]
|<4>| REC[80714a8]: Sending Packet[0] Handshake(22) with length: 131
|<4>| REC[80714a8]: Sent Packet[1] Handshake(22) with length: 136
|<4>| REC[80714a8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[80714a8]: Received Packet[0] Handshake(22) with length: 74
|<4>| REC[80714a8]: Decrypted Packet[0] Handshake(22) with length: 74
|<3>| HSK[80714a8]: SERVER HELLO was received [74 bytes]
|<3>| HSK[80714a8]: Server's version: 3.1
|<3>| HSK[80714a8]: SessionID length: 32
|<3>| HSK[80714a8]: SessionID: c4f6780c4d2527abc8cc041d00a257f0dcc0a33573ed9a8eb65a7cb5c4b22717
|<3>| HSK[80714a8]: Selected cipher suite: DHE_RSA_AES_256_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:153
|<4>| REC[80714a8]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[80714a8]: Received Packet[1] Handshake(22) with length: 687
|<4>| REC[80714a8]: Decrypted Packet[1] Handshake(22) with length: 687
|<3>| HSK[80714a8]: CERTIFICATE was received [687 bytes]
|<4>| REC[80714a8]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[80714a8]: Received Packet[2] Handshake(22) with length: 333
|<4>| REC[80714a8]: Decrypted Packet[2] Handshake(22) with length: 333
|<3>| HSK[80714a8]: SERVER KEY EXCHANGE was received [333 bytes]
|<4>| REC[80714a8]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[80714a8]: Received Packet[3] Handshake(22) with length: 14187
|<4>| REC[80714a8]: Decrypted Packet[3] Handshake(22) with length: 14187
|<3>| HSK[80714a8]: CERTIFICATE REQUEST was received [14187 bytes]
- Successfully sent 0 certificate(s) to server.
|<4>| REC[80714a8]: Expected Packet[4] Handshake(22) with length: 1
|<4>| REC[80714a8]: Received Packet[4] Handshake(22) with length: 4
|<4>| REC[80714a8]: Decrypted Packet[4] Handshake(22) with length: 4
|<3>| HSK[80714a8]: SERVER HELLO DONE was received [4 bytes]
|<3>| HSK[80714a8]: CERTIFICATE was send [7 bytes]
|<4>| REC[80714a8]: Sending Packet[1] Handshake(22) with length: 7
|<4>| REC[80714a8]: Sent Packet[2] Handshake(22) with length: 12
|<3>| HSK[80714a8]: CLIENT KEY EXCHANGE was send [102 bytes]
|<4>| REC[80714a8]: Sending Packet[2] Handshake(22) with length: 102
|<4>| REC[80714a8]: Sent Packet[3] Handshake(22) with length: 107
|<3>| REC[80714a8]: Sent ChangeCipherSpec
|<4>| REC[80714a8]: Sending Packet[3] Change Cipher Spec(20) with length: 1
|<4>| REC[80714a8]: Sent Packet[4] Change Cipher Spec(20) with length: 6
|<3>| HSK[80714a8]: Cipher Suite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Initializing internal [write] cipher sessions
|<3>| HSK[80714a8]: FINISHED was send [16 bytes]
|<4>| REC[80714a8]: Sending Packet[0] Handshake(22) with length: 16
|<4>| REC[80714a8]: Sent Packet[1] Handshake(22) with length: 229
|<4>| REC[80714a8]: Expected Packet[5] Change Cipher Spec(20) with length: 1
|<4>| REC[80714a8]: Received Packet[5] Change Cipher Spec(20) with length: 1
|<4>| REC[80714a8]: ChangeCipherSpec Packet was received
|<3>| HSK[80714a8]: Cipher Suite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[80714a8]: Initializing internal [read] cipher sessions
|<4>| REC[80714a8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[80714a8]: Received Packet[0] Handshake(22) with length: 80
|<4>| REC[80714a8]: Decrypted Packet[0] Handshake(22) with length: 16
|<3>| HSK[80714a8]: FINISHED was received [16 bytes]
|<2>| ASSERT: ext_server_name.c:244
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate does NOT match 'localhost'.
 # valid since: Wed Jul 26 00:09:36 EDT 2006
 # expires at: Fri Aug 25 00:09:36 EDT 2006
 # fingerprint: 7F:68:15:10:FC:23:79:17:0E:37:10:C1:DA:4B:D2:32
 # Subject's DN: C=??,ST=Nostate,L=Nocity,O=Internet Widgits Pty Ltd,CN=madbat.mine.nu,EMAIL=itz@madbat.mine.nu
 # Issuer's DN: C=??,ST=Nostate,L=Nocity,O=Internet Widgits Pty Ltd,CN=madbat.mine.nu,EMAIL=itz@madbat.mine.nu

|<2>| ASSERT: verify.c:242
|<2>| ASSERT: verify.c:398

- 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
QUIT
|<4>| REC[80714a8]: Sending Packet[1] Application Data(23) with length: 5
|<4>| REC[80714a8]: Sent Packet[2] Application Data(23) with length: 229
|<4>| REC[80714a8]: Expected Packet[1] Application Data(23) with length: 4096
|<4>| REC[80714a8]: Received Packet[1] Application Data(23) with length: 128
|<4>| REC[80714a8]: Decrypted Packet[1] Application Data(23) with length: 39
221 madbat.mine.nu closing connection
|<4>| REC[80714a8]: Expected Packet[2] Application Data(23) with length: 4096
|<4>| REC[80714a8]: Received Packet[2] Alert(21) with length: 48
|<4>| REC[80714a8]: Decrypted Packet[2] Alert(21) with length: 2
|<4>| REC[80714a8]: Alert[1|0] - Close notify - was received
- Peer has closed the GNUTLS connection
itz@madbat:~$ openssl s_client -connect localhost:587 -starttls smtp
CONNECTED(00000003)
32522:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:567:


-- 
A true pessimist won't be discouraged by a little success.

Message #103 received at 348046@bugs.debian.org (full text, mbox, reply):

user exim4@packages.debian.org
usertags #348046 - close-20060430
tags #348046 help
thanks

On Fri, Jul 28, 2006 at 12:22:03AM -0400, Ian Zimmerman wrote:
> Okay, now gnutls-cli seems to work; immediately after, I try to connect
> with openssl, still same error.

I am at a loss here. Tagging this bug appropriately.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Tags added: help Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (full text, mbox, link).

Acknowledgement sent to "Marc F. Clemente" <marc@mclemente.net>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #110 received at 348046@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

I am seeing this bug with exim version 4.62-4.

To me, it happens with Thunderbird and Mozilla MUAs (on different 
computers).  It does not happen all the time.  If the MUA fails sending 
the message, a repeat attempt will eventually succeed.

I tried connecting manually with:
gnutls-cli --port 25 -d 5 --starttls mail.mclemente.net
and it worked four times in a row. I attach a debug output of gnutls-cli.

Entropy available?  How do I know?
cat /proc/sys/kernel/random/entropy_avail
gives me a number.  But how do I know what the number was when I get the 
error?

I don't know how to reliably reproduce this error, but let me know if I 
can help debug the problem.

Marc (marc@mclemente.net)

[gnutls-cli.txt (text/plain, inline)]

mc-laptop:~> gnutls-cli --port 25 -d 5 --starttls mail.mclemente.net
|<2>| ASSERT: gnutls_psk.c:101
Resolving 'mail.mclemente.net'...
Connecting to '24.182.131.218:25'...

- Simple Client Mode:

220 mail.mclemente.net ESMTP Exim 4.62 Wed, 09 Aug 2006 10:57:54 -0500
ehlo mclemente.net
250-mail.mclemente.net Hello 24-178-49-83.static.stls.mo.charter.com [24.178.49.83]
250-SIZE 52428800
250-PIPELINING
250-AUTH CRAM-MD5
250-STARTTLS
250 HELP
starttls
220 TLS go ahead
*** Starting TLS handshake
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[8071bc0]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[8071bc0]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5
|<2>| EXT[8071bc0]: Sending extension CERT_TYPE
|<2>| EXT[8071bc0]: Sending extension SERVER_NAME
|<3>| HSK[8071bc0]: CLIENT HELLO was send [140 bytes]
|<4>| REC[8071bc0]: Sending Packet[0] Handshake(22) with length: 140
|<4>| REC[8071bc0]: Sent Packet[1] Handshake(22) with length: 145
|<4>| REC[8071bc0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8071bc0]: Received Packet[0] Handshake(22) with length: 74
|<4>| REC[8071bc0]: Decrypted Packet[0] Handshake(22) with length: 74
|<3>| HSK[8071bc0]: SERVER HELLO was received [74 bytes]
|<3>| HSK[8071bc0]: Server's version: 3.1
|<3>| HSK[8071bc0]: SessionID length: 32
|<3>| HSK[8071bc0]: SessionID: b371ba8fe867339f14446af7ff2cc71895a9593fbf54c48eac68218600bbaa20
|<3>| HSK[8071bc0]: Selected cipher suite: DHE_RSA_AES_256_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:153
|<4>| REC[8071bc0]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[8071bc0]: Received Packet[1] Handshake(22) with length: 447
|<4>| REC[8071bc0]: Decrypted Packet[1] Handshake(22) with length: 447
|<3>| HSK[8071bc0]: CERTIFICATE was received [447 bytes]
|<4>| REC[8071bc0]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[8071bc0]: Received Packet[2] Handshake(22) with length: 333
|<4>| REC[8071bc0]: Decrypted Packet[2] Handshake(22) with length: 333
|<3>| HSK[8071bc0]: SERVER KEY EXCHANGE was received [333 bytes]
|<4>| REC[8071bc0]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[8071bc0]: Received Packet[3] Handshake(22) with length: 14187
|<4>| REC[8071bc0]: Decrypted Packet[3] Handshake(22) with length: 14187
|<3>| HSK[8071bc0]: CERTIFICATE REQUEST was received [14187 bytes]
- Successfully sent 0 certificate(s) to server.
|<4>| REC[8071bc0]: Expected Packet[4] Handshake(22) with length: 1
|<4>| REC[8071bc0]: Received Packet[4] Handshake(22) with length: 4
|<4>| REC[8071bc0]: Decrypted Packet[4] Handshake(22) with length: 4
|<3>| HSK[8071bc0]: SERVER HELLO DONE was received [4 bytes]
|<3>| HSK[8071bc0]: CERTIFICATE was send [7 bytes]
|<4>| REC[8071bc0]: Sending Packet[1] Handshake(22) with length: 7
|<4>| REC[8071bc0]: Sent Packet[2] Handshake(22) with length: 12
|<3>| HSK[8071bc0]: CLIENT KEY EXCHANGE was send [102 bytes]
|<4>| REC[8071bc0]: Sending Packet[2] Handshake(22) with length: 102
|<4>| REC[8071bc0]: Sent Packet[3] Handshake(22) with length: 107
|<3>| REC[8071bc0]: Sent ChangeCipherSpec
|<4>| REC[8071bc0]: Sending Packet[3] Change Cipher Spec(20) with length: 1
|<4>| REC[8071bc0]: Sent Packet[4] Change Cipher Spec(20) with length: 6
|<3>| HSK[8071bc0]: Cipher Suite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Initializing internal [write] cipher sessions
|<3>| HSK[8071bc0]: FINISHED was send [16 bytes]
|<4>| REC[8071bc0]: Sending Packet[0] Handshake(22) with length: 16
|<4>| REC[8071bc0]: Sent Packet[1] Handshake(22) with length: 197
|<4>| REC[8071bc0]: Expected Packet[5] Change Cipher Spec(20) with length: 1
|<4>| REC[8071bc0]: Received Packet[5] Change Cipher Spec(20) with length: 1
|<4>| REC[8071bc0]: ChangeCipherSpec Packet was received
|<3>| HSK[8071bc0]: Cipher Suite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8071bc0]: Initializing internal [read] cipher sessions
|<4>| REC[8071bc0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8071bc0]: Received Packet[0] Handshake(22) with length: 192
|<4>| REC[8071bc0]: Decrypted Packet[0] Handshake(22) with length: 16
|<3>| HSK[8071bc0]: FINISHED was received [16 bytes]
|<2>| ASSERT: ext_server_name.c:244
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'mail.mclemente.net'.
 # valid since: Fri Jan  6 10:19:37 CST 2006
 # expires at: Mon Jan  5 10:19:37 CST 2009
 # fingerprint: 69:28:FD:31:E0:D8:6C:95:5F:1C:71:74:E2:62:5E:AA
 # Subject's DN: CN=mail.mclemente.net
 # Issuer's DN: CN=mail.mclemente.net

|<2>| ASSERT: verify.c:242
|<2>| ASSERT: verify.c:398

- 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
mail from:mclemente.net
|<4>| REC[8071bc0]: Sending Packet[1] Application Data(23) with length: 24
|<4>| REC[8071bc0]: Sent Packet[2] Application Data(23) with length: 101
|<4>| REC[8071bc0]: Expected Packet[1] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[1] Application Data(23) with length: 112
|<4>| REC[8071bc0]: Decrypted Packet[1] Application Data(23) with length: 57
501 mclemente.net: sender address must contain a domain
mail from:marc@mclemente.net
|<4>| REC[8071bc0]: Sending Packet[2] Application Data(23) with length: 29
|<4>| REC[8071bc0]: Sent Packet[3] Application Data(23) with length: 229
|<4>| REC[8071bc0]: Expected Packet[2] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[2] Application Data(23) with length: 64
|<4>| REC[8071bc0]: Decrypted Packet[2] Application Data(23) with length: 8
250 OK
rcpt to:marc@mclemente.net
|<4>| REC[8071bc0]: Sending Packet[3] Application Data(23) with length: 27
|<4>| REC[8071bc0]: Sent Packet[4] Application Data(23) with length: 133
|<4>| REC[8071bc0]: Expected Packet[3] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[3] Application Data(23) with length: 192
|<4>| REC[8071bc0]: Decrypted Packet[3] Application Data(23) with length: 14
250 Accepted
data
|<4>| REC[8071bc0]: Sending Packet[4] Application Data(23) with length: 5
|<4>| REC[8071bc0]: Sent Packet[5] Application Data(23) with length: 117
|<4>| REC[8071bc0]: Expected Packet[4] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[4] Application Data(23) with length: 128
|<4>| REC[8071bc0]: Decrypted Packet[4] Application Data(23) with length: 56
354 Enter message, ending with "." on a line by itself
From: marc@mclemente.net
|<4>| REC[8071bc0]: Sending Packet[5] Application Data(23) with length: 25
|<4>| REC[8071bc0]: Sent Packet[6] Application Data(23) with length: 69

|<4>| REC[8071bc0]: Sending Packet[6] Application Data(23) with length: 1
|<4>| REC[8071bc0]: Sent Packet[7] Application Data(23) with length: 101
test4
|<4>| REC[8071bc0]: Sending Packet[7] Application Data(23) with length: 6
|<4>| REC[8071bc0]: Sent Packet[8] Application Data(23) with length: 149
.
|<4>| REC[8071bc0]: Sending Packet[8] Application Data(23) with length: 2
|<4>| REC[8071bc0]: Sent Packet[9] Application Data(23) with length: 213
|<4>| REC[8071bc0]: Expected Packet[5] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[5] Application Data(23) with length: 192
|<4>| REC[8071bc0]: Decrypted Packet[5] Application Data(23) with length: 28
250 OK id=1GAqRy-0000NC-Qm
quit
|<4>| REC[8071bc0]: Sending Packet[9] Application Data(23) with length: 5
|<4>| REC[8071bc0]: Sent Packet[10] Application Data(23) with length: 101
|<4>| REC[8071bc0]: Expected Packet[6] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[6] Application Data(23) with length: 256
|<4>| REC[8071bc0]: Decrypted Packet[6] Application Data(23) with length: 43
221 mail.mclemente.net closing connection
|<4>| REC[8071bc0]: Expected Packet[7] Application Data(23) with length: 4096
|<4>| REC[8071bc0]: Received Packet[7] Alert(21) with length: 224
|<4>| REC[8071bc0]: Decrypted Packet[7] Alert(21) with length: 2
|<4>| REC[8071bc0]: Alert[1|0] - Close notify - was received
- Peer has closed the GNUTLS connection

Message #115 received at 348046@bugs.debian.org (full text, mbox, reply):

Hi,

the scenario I reported is just bug #221689.  Exim does the right thing
in that particular case.  (Not that it helps in pratical terms, because
any client linked with openssl will fail).  I am not closing or merging
348046 because I am not sure that Martin's and Marc Clemente's scenarios
were the same.  Do Thunderbird and Mozilla link with openssl or gnutls?
If openssl this could really be just a dupe of 221689.

-- 
She had a passion for anyone who could do anything really well.
...                "Not for an engineer, not for a technician!"
                    Mikhail Bulgakov, The Master & Margarita

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.org>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #120 received at 348046@bugs.debian.org (full text, mbox, reply):

My laptop has been connected for several days to another network,
where TLS is used for the mail. And I get the error "TLS error on
connection to pilet.ens-lyon.fr [140.77.167.16] (gnutls_handshake):
A TLS packet with unexpected length was received." on (almost)
every morning for the first message I send. This would be consistent
with a lack of entropy (but to be sure, I'll try to log the output
of /proc/sys/kernel/random/entropy_avail in RRDTool).

I have exim4-daemon-light 4.63-3 and libgnutls13 1.4.4-1.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #125 received at 348046@bugs.debian.org (full text, mbox, reply):

On 2006-10-05 Vincent Lefevre <vincent@vinc17.org> wrote:
> My laptop has been connected for several days to another network,
> where TLS is used for the mail. And I get the error "TLS error on
> connection to pilet.ens-lyon.fr [140.77.167.16] (gnutls_handshake):
> A TLS packet with unexpected length was received." on (almost)
> every morning for the first message I send. This would be consistent
> with a lack of entropy (but to be sure, I'll try to log the output
> of /proc/sys/kernel/random/entropy_avail in RRDTool).

> I have exim4-daemon-light 4.63-3 and libgnutls13 1.4.4-1.

Having this happen for just the first message sugggests is very
strange. There is nothing in exim or gnutls that should behave
differently for the second run. (Entropy starvage cannot be the cause
either, as this is only a issue for *incoming* connections).

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

Message #130 received at 348046@bugs.debian.org (full text, mbox, reply):

On 2006-10-07 15:08:52 +0200, Andreas Metzler wrote:
> Having this happen for just the first message sugggests is very
> strange. There is nothing in exim or gnutls that should behave
> differently for the second run. (Entropy starvage cannot be the cause
> either, as this is only a issue for *incoming* connections).

Are you sure? I've just done a test on this machine, to which I've
opened 2 SSH connections. With one of them, I've sent a mail. With
the other one:

ay:~> cat /proc/sys/kernel/random/entropy_avail                        <0:21:27
2757
ay:~> cat /proc/sys/kernel/random/entropy_avail                        <0:21:30
3067
ay:~> cat /proc/sys/kernel/random/entropy_avail                        <0:21:56
3462
ay:~> cat /proc/sys/kernel/random/entropy_avail                        <0:22:11
4
ay:~> cat /proc/sys/kernel/random/entropy_avail                        <0:22:15
29
ay:~> cat /proc/sys/kernel/random/entropy_avail                        <0:22:24

The entropy dropped from 3462 to 4 just after I've sent the mail!

Concerning the mail, it is still in the queue, but the exim4 log file
doesn't show any error! And "exim -qff" doesn't solve the problem.
Here are the contents of /var/log/exim4/mainlog:

[...]
2006-10-08 00:12:23 Start queue run: pid=15334
2006-10-08 00:12:23 End queue run: pid=15334
2006-10-08 00:17:23 Start queue run: pid=15526
2006-10-08 00:17:23 End queue run: pid=15526
2006-10-08 00:22:13 1GWKYf-00043q-HN <= vincent@vinc17.org U=lefevre P=local S=778 id=20061007222213.GA15599@ay.vinc17.org
2006-10-08 00:22:23 Start queue run: pid=15622
2006-10-08 00:22:23 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
2006-10-08 00:22:23 End queue run: pid=15622
2006-10-08 00:24:28 Start queue run: pid=15630 -qff
2006-10-08 00:24:28 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
2006-10-08 00:24:28 End queue run: pid=15630 -qff
2006-10-08 00:25:23 Start queue run: pid=15797 -qff
2006-10-08 00:25:23 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
2006-10-08 00:25:23 End queue run: pid=15797 -qff
2006-10-08 00:27:23 Start queue run: pid=15859
2006-10-08 00:27:23 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
2006-10-08 00:27:23 End queue run: pid=15859

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #135 received at 348046@bugs.debian.org (full text, mbox, reply):

On 2006-10-08 00:30:53 +0200, Vincent Lefevre wrote:
> The entropy dropped from 3462 to 4 just after I've sent the mail!
> 
> Concerning the mail, it is still in the queue, but the exim4 log file
> doesn't show any error! And "exim -qff" doesn't solve the problem.
  ^^^^^^^^^^^^^^^^^^^^^^

Of course, this was because the process was still running to propagate
the mail. But I finally got the TLS error:

> Here are the contents of /var/log/exim4/mainlog:
> 
> [...]
> 2006-10-08 00:12:23 Start queue run: pid=15334
> 2006-10-08 00:12:23 End queue run: pid=15334
> 2006-10-08 00:17:23 Start queue run: pid=15526
> 2006-10-08 00:17:23 End queue run: pid=15526
> 2006-10-08 00:22:13 1GWKYf-00043q-HN <= vincent@vinc17.org U=lefevre P=local S=778 id=20061007222213.GA15599@ay.vinc17.org
> 2006-10-08 00:22:23 Start queue run: pid=15622
> 2006-10-08 00:22:23 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
> 2006-10-08 00:22:23 End queue run: pid=15622
[...]
2006-10-08 00:37:06 1GWKYf-00043q-HN TLS error on connection to pilet.ens-lyon.fr [140.77.167.16] (gnutls_handshake): A TLS packet with unexpected length was received.
[...]

Then the entropy was back to 617. I've typed "exim -qff" (which
successfully sent the mail), and just after this, the entropy was
186.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #140 received at 348046@bugs.debian.org (full text, mbox, reply):

On 2006-10-08 Vincent Lefevre <vincent@vinc17.org> wrote:
> On 2006-10-07 15:08:52 +0200, Andreas Metzler wrote:
> > Having this happen for just the first message sugggests is very
> > strange. There is nothing in exim or gnutls that should behave
> > differently for the second run. (Entropy starvage cannot be the cause
> > either, as this is only a issue for *incoming* connections).

> Are you sure?

Quite sure, yes.

> I've just done a test on this machine, to which I've
> opened 2 SSH connections. With one of them, I've sent a mail. With
> the other one:
[...]
> The entropy dropped from 3462 to 4 just after I've sent the mail!

For outgoing TLS exim reads from /dev/urandom which *does* drain
entropy but switches to a prng instead of blocking when there is no
more entropy.

> Concerning the mail, it is still in the queue, but the exim4 log file
> doesn't show any error! And "exim -qff" doesn't solve the problem.
> Here are the contents of /var/log/exim4/mainlog:

[...]
> 2006-10-08 00:22:13 1GWKYf-00043q-HN <= vincent@vinc17.org U=lefevre P=local S=778 id=20061007222213.GA15599@ay.vinc17.org
> 2006-10-08 00:22:23 Start queue run: pid=15622
> 2006-10-08 00:22:23 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
[...]

What does exiwhat say?
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

Message #145 received at 348046@bugs.debian.org (full text, mbox, reply):

On 2006-10-08 09:26:35 +0200, Andreas Metzler wrote:
> For outgoing TLS exim reads from /dev/urandom which *does* drain
> entropy but switches to a prng instead of blocking when there is no
> more entropy.

This is strange, because it really seems to be related to the entropy.
Is there a way to get more information (debugging mode...) on what
exim is doing?

> > Concerning the mail, it is still in the queue, but the exim4 log file
> > doesn't show any error! And "exim -qff" doesn't solve the problem.
> > Here are the contents of /var/log/exim4/mainlog:
> 
> [...]
> > 2006-10-08 00:22:13 1GWKYf-00043q-HN <= vincent@vinc17.org U=lefevre P=local S=778 id=20061007222213.GA15599@ay.vinc17.org
> > 2006-10-08 00:22:23 Start queue run: pid=15622
> > 2006-10-08 00:22:23 1GWKYf-00043q-HN Spool file is locked (another process is handling this message)
> [...]
> 
> What does exiwhat say?

ay:/home/lefevre# exiwhat
 2165 daemon: -q5m, listening for SMTP on [127.0.0.1]:25
15602 delivering 1GWt31-00043d-2z: waiting for a remote delivery subprocess to finish
15604 delivering 1GWt31-00043d-2z to pilet.ens-lyon.fr [140.77.167.16] (vincent@vinc17.org, ...)
ay:/home/lefevre# ps -aef|grep exim
108       2165     1  0 Oct07 ?        00:00:00 /usr/sbin/exim4 -bd -q5m
root     15602     1  0 13:11 ?        00:00:00 /usr/sbin/exim4 -Mc 1GWt31-00043d-2z
108      15604 15602  0 13:11 ?        00:00:00 /usr/sbin/exim4 -Mc 1GWt31-00043d-2z
root     15687 15648  0 13:14 pts/5    00:00:00 grep exim

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Acknowledgement sent to Ronny Adsetts <ronny.adsetts@amazinginternet.com>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #150 received at 348046@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi.

This error is occurring with 4.50-8sarge2 on Sarge too. Judging by my munin graphs on both sending and receiving side, there's no entropy on the sending side. I noticed this error yesterday when there was testing on a client's site that resulted in a couple of hundred emails being sent to us in rapid succession. The first few were sent on a TLS connection, the remainder had this logged on the sending side:

radsetts@monolith:~$ grep 1GZ8x3-0000Ix-Iv /var/log/exim4/mainlog.1
2006-10-15 17:35:01 1GZ8x3-0000Ix-Iv <= secretary@chelseaartsclub.com H=mainoffice.theclub.chelseaartsclub.com (mainoffice) [172.17.0.189] P=esmtp S=612 id=9004539.1160930103968.JavaMail.prestonm@mail.theclub.chelseaartsclub.com
2006-10-15 17:42:36 1GZ8x3-0000Ix-Iv TLS error on connection to mail.amazing-internet.net [172.16.1.20] (gnutls_handshake): A record packet with illegal version was received.
2006-10-15 17:42:36 1GZ8x3-0000Ix-Iv TLS session failure: delivering unencrypted to mail.amazing-internet.net [172.16.1.20] (not in hosts_require_tls)
2006-10-15 17:42:39 1GZ8x3-0000Ix-Iv => devnull@amazing-internet.com R=dnslookup T=remote_smtp H=mail.amazing-internet.net [172.16.1.20]
2006-10-15 17:42:39 1GZ8x3-0000Ix-Iv Completed

This on the receiving side:

2006-10-15 17:42:39 1GZ94O-0003t2-T3 <= secretary@chelseaartsclub.com H=monolith.theclub.chelseaartsclub.com [172.17.0.16] P=esmtp S=822 id=9004539.1160930103968.JavaMail.prestonm@mail.theclub.chelseaartsclub.com
2006-10-15 17:42:39 1GZ94O-0003t2-T3 => /dev/null <devnull@amazing-internet.com> R=ldap_aliases T=**bypassed**
2006-10-15 17:42:39 1GZ94O-0003t2-T3 Completed

Plus lots of these logged on the receiving side:

2006-10-15 17:39:59 TLS error on connection from monolith.theclub.chelseaartsclub.com [172.17.0.16] (gnutls_handshake): timed out

So it looks like entropy again is the problem.

A quick google brings up a thread [1] that suggest use of /dev/urandom would not be a big deal is some cases. Not sure whether that it feasible from within exim though and I suspect not.

[1] http://www.mail-archive.com/help-gnutls@gnu.org/msg00323.html

Is the problem with how greedy gnutls is for random data or in how exim uses gnutls?

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to Jon Fine <fine@astro.psu.edu>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #155 received at 348046@bugs.debian.org (full text, mbox, reply):

Just wanted to chime in on what happened with our debian mail server. 
Using courier-imap-ssl, exim4, etc originally with a 2.4.25 kernel. 
Installed a hand compiled 2.6.22 kernel, rebooted, and ran into various 
problems, specifically with sending email using TLS.  After much 
hairpulling and very little to go on via the logs(no errors logged), 
someone pointed me to this thread and the discussion of low entropy. 
Doing a cat of /proc/sys/kernel/random/entropy_avail was giving me at 
max a number in the high 50's.  After rolling back to our 2.4 kernel, we 
are back at 4096.


I haven't done enough research yet to figure out if this is a "bug" 
specific to the 2.6.22 kernel or if that 2.6 kernel uses something that 
debian sarge did not expect.


Jon

Acknowledgement sent to "Andrew McGlashan" <andrew.mcglashan@affinityvision.com.au>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #160 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #165 received at 348046@bugs.debian.org (full text, mbox, reply):

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.

> 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?

What is Incredimail? An MTA, or a Mail service?

>   And if so, is there any way that the Exim4 can work with both
>   OpenSSL and GNUTLS?

You can recompile the packages with OpenSSL.

> 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 kind of fail to understand what you intend to do and what works and
what not.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message #170 received at 348046@bugs.debian.org (full text, mbox, reply):

On 2007-10-27 14:17:24 +0200, Marc Haber wrote:
> You can recompile the packages with OpenSSL.

Is there any reason why this isn't done by default?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #175 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #180 received at 348046@bugs.debian.org (full text, mbox, reply):

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 XXXXXX.xxxx.xxxxx.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

Message #185 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sun, Oct 28, 2007 at 12:16:10AM +1000, Andrew McGlashan wrote:
> Marc Haber wrote:
> >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.

Then you're out of luck.

>   However, if a special package was made available in the normal way,

I do not have time and resources to maintain two of them, and am not
sure about licensing issues.

> >>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.

No, you can connect to exim just fine with an openssl client. Just try
openssl s_client.

You might want to use gnutls-serv as a test target against your
incredimail client.

> >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.

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.

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.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message #190 received at 348046@bugs.debian.org (full text, mbox, reply):

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
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      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
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      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

Message #195 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #200 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Message #208 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Message #216 received at 348046@bugs.debian.org (full text, mbox, reply):

On Thu, Nov 01, 2007 at 11:43:36AM +1100, Andrew McGlashan wrote:
> # 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

After thinking for a while, why did your incredimail not complain
about the server not presenting a certificate?

Please try again and give gnutls-serv the same certificate that your
exim also uses.

For reference, you might want to try openssl:

openssl s_server -cert /etc/exim4/tls/certs/exim.crt -key /etc/exim4/tls/key/exim.key -accept 588 -debug

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Message #224 received at 348046@bugs.debian.org (full text, mbox, reply):

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
 BqEGAgRHKbLBogQCAgEspAYEBAEAAAA=
 -----END SSL SESSION PARAMETERS-----
 Shared 
ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:DES-CBC-SHA:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EDH-DSS-DES- 
CBC3-SHA:EDH-DSS-DES-CBC-SHA
 CIPHER is RC4-MD5


Okay.... then I hit enter on the putty session and more data appeared, so I 
continued to hit enter until I saw this:

 read from 0x80d0b50 [0x80c5538] (5 bytes => 0 (0x0))
 ERROR
 shutting down SSL
 CONNECTION CLOSED
 ACCEPT


Then, IM fails again with "Failed to connect to the outgoing server, 
'myserver'. Please try again later.
- "Socket Error: (0) The operation completed successfully.


Kind Regards
AndrewM

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Message #232 received at 348046@bugs.debian.org (full text, mbox, reply):

On Fri, Jul 28, 2006 at 12:22:03AM -0400, Ian Zimmerman wrote:
> Okay, now gnutls-cli seems to work; immediately after, I try to connect
> with openssl, still same error.
> 
> itz@madbat:~$ openssl s_client -connect localhost:587 -starttls smtp
> CONNECTED(00000003)
> 32522:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:567:

Is there any chance to get some debug info from openssl s_client?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Message #240 received at 348046@bugs.debian.org (full text, mbox, reply):

On Mon, Oct 29, 2007 at 02:05:18AM +1100, Andrew McGlashan wrote:
> Marc Haber wrote:
> >> 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.

The standardized usage of TCP/587 is STARTTLS, so technically,
tls_on_connect_ports=587 is likely to confuse conforming clients. I do
not have an idea how OE or Incredimail behave, but I wouldn't be
surprised that they would choke when expecting a cleartext ESMTP
handshake with STARTTLS and being presented with an on-connect TLS
handshake.

If you want to be sure, try finding out what IM and OE do when you
have them connect to a netcat process on TCP/587 that immediately
shows them a cleartext ESMTP greeting. If they respond with a
cleartext EHLO, then you have your exim misconfigured and need to
remove the 587 from tls_on_connect_ports.

> GMAIL also breaks the RFC then as they only use port 465....

$ gnutls-cli -p 587 smtp.gmail.com -s
Resolving 'smtp.gmail.com'...
Connecting to '72.14.221.111:587'...

- Simple Client Mode:

220 mx.google.com ESMTP 4sm12205522fge.8
EHLO test.client.example
250-mx.google.com at your service, [77.1.33.179]
250-SIZE 28311552
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
STARTTLS
220 2.0.0 Ready to start TLS
*** Starting TLS handshake
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'smtp.gmail.com'.
 # valid since: Mon Jul 30 18:58:07 CEST 2007
 # expires at: Tue Jul 29 18:58:07 CEST 2008
 # fingerprint: 32:66:6C:0A:DC:4F:2D:F9:83:2E:B4:AA:22:A7:E0:E7
 # Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com
 # Issuer's DN: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-server@thawte.com


- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS 1.0
- Key Exchange: RSA
- Cipher: 3DES 168 CBC
- MAC: SHA
- Compression: NULL

502 5.5.1 Unrecognized command 4sm12205522fge.8
EHLO test.client.example
250-mx.google.com at your service, [77.1.33.179]
250-SIZE 28311552
250-8BITMIME
250-AUTH LOGIN PLAIN
250 ENHANCEDSTATUSCODES
quit
221 2.0.0 mx.google.com closing connection 4sm12205522fge.8
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.
$                                      

This looks to me as they have a compliant submission agent on TCP/587
as well.

> > 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
> tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN
> tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN
> tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
> tcp        0      0 192.168.2.2:25          80.161.186.2:63657 
> TIME_WAIT

This indicates a TCP session that has already finished.

> And when OE is 'waiting' on port 587 tests:
> 
> # netstat -an|grep -e 25 -e 465 -e 587|grep tcp
> tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN
> tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN
> tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
> tcp        0      0 192.168.2.2:587         192.168.0.158:2854 
> ESTABLISHED

That looks like the session is still up and either side is waiting.
Might be possible that OE is waiting for a clear text SMTP banner
while the exim (with smtp_on_connect_ports including 587) is waiting
for a TLS handshake. Both sides will wait until timeout.

> 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

This is also an indication of exim expecting the remote side to talk
TLS while the remote side isn't.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #245 received at 348046@bugs.debian.org (full text, mbox, reply):

Hi Marc!  I'm trying to help with debugging this problem.  Can you still
reproduce the problem, or has it disappeared?  You reported it over a
year ago...

What I don't fully understand is whether your problem is between
Thunderbird and Exim4+GnuTLS or between Exim4+GnuTLS and the remote
server?

Could you quote the exact exim4 log messages when this happens?  I
couldn't find them in the bug report.

If the problem is between thunderbird and exim4+gnutls, what would help
to debug this would be if you could run gnutls-serv with --debug and try
to reproduce the problem.  But let's see if the above questions resolve
this bug differently first.

Thanks,
Simon

Message #250 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #255 received at 348046@bugs.debian.org (full text, mbox, reply):

Thanks for prompt feedback, Andrew!

My reading from this is that we can close the IM related part of this
bug report.

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?).

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..

Thanks,
/Simon

"Andrew McGlashan" <andrew.mcglashan@affinityvision.com.au> writes:

> 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

Message #260 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sat, Jan 05, 2008 at 04:32:55AM +1100, Andrew McGlashan wrote:
> I tried adjusting my exim4 config by setting MAIN_TLS_ENABLE to false and 
> restarting exim4.

Since MAIN_TLS_ENABLE is in .ifdef clauses, setting MAIN_TLS_ENABLE to
false will enable TLS. You need to comment out its definition, so that
the macro is not defined at all. Setting it to any value (including
"empty", I fear) will enable TLS. The only way to disable TLS is
commenting out its definition or removing it.

Be aware that Debian's exim doesn't advertise SMTP AUTH over
unencrypted connections, so trying to send authenticated mail to an
exim that has its TLS disabled will cause authentication to fail
(because of other reasons, which might be hidden from your view by the
mail client that is desperately trying not to confuse its users).

It might be a good idea to use a tool like swaks for debugging which
shows you what is actually happening (even when encryption is in use)
or to use wireshark or tcpdump (which will only be useful is
encryption is not used) to see what's goign on on the wire.

> So for me it isn't, I don't think, anything to do with my mail server 
> settings.

Unfortunately, a conclusion based on false assumptions. You didn't
change anything in your mail server configuration.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message #265 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #270 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sat, Jan 05, 2008 at 02:27:26PM +1100, Andrew McGlashan wrote:
> Simon Josefsson wrote:
> > 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.

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.

> 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.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message #275 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #280 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sat, Jan 05, 2008 at 09:02:43PM +1100, Andrew McGlashan wrote:
> 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.

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?

> >>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.... 

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).

> 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?

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.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message #285 received at 348046@bugs.debian.org (full text, mbox, reply):

Marc Haber <mh+debian-packages@zugschlus.de> writes:

>> 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?
>
> I must admit that I have lost the overview over this bug report.

Me too.  I don't understand Andrew's problem, and the 348046 bug
contains too many separate issues, so a "me too" can mean anything.
Andrew, sorry to bother you, but could you describe how you reproduce a
problem using your set up?  Including error messages.  Preferably as a
new bug report against exim (?).

> 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

Actually that was TheBat!...  I'll see if I can find a incredimail
evaluation copy too.

/Simon

Message #290 received at 348046@bugs.debian.org (full text, mbox, reply):

Simon Josefsson <simon@josefsson.org> writes:

>> 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
>
> Actually that was TheBat!...  I'll see if I can find a incredimail
> evaluation copy too.

There is one from <http://www.incredimail.com/> but it just gives an
'Installation script error' when run under Wine..  If we can get a
complete step-by-step description on how to reproduce the problem
between IM and Exim, I can borrow a Windows machine to debug it.

/Simon

Message #295 received at 348046@bugs.debian.org (full text, mbox, reply):

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

Message #300 received at 348046@bugs.debian.org (full text, mbox, reply):

On Sat, Jan 05, 2008 at 09:31:40PM +1100, Andrew McGlashan wrote:
> 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...

yes, it is ports. Typo.

> But I do have the following:
> 
> www:/tmp# grep 587 /var/lib/exim4/config.autogenerated
> tls_on_connect_ports=465:587

So you are not using ESMTP STARTTLS on tcp/587, which might be a
reason why your clients don't work. I am not aware of any software
that is broken _that_ badly to use SMTP over SSL on tcp/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

That looks as properly configured as SMTP over SSL on tcp/465 can be.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Message #305 received at 348046@bugs.debian.org (full text, mbox, reply):

On Tue, Jul 25, 2006 at 06:09:56PM -0700, Ian Zimmerman wrote:
> itz@madbat:/etc/exim4/conf.d$ openssl s_client -connect 127.0.0.1:587 -starttls smtp
> CONNECTED(00000003)
> 20025:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:567:
> itz@madbat:/etc/exim4/conf.d$ 

This is most probably caused by a bug in openssl s_client that
immediately issued a STARTTLS command without saying EHLO before
(which exim rejected). This can be seen when adding the -debug switch.
I have just verified that the openssl in Debian etch does it wrong as
well.

Later versions of openssl (including the one in Debian sid) handle
this correctly. Can you verify this please so that this sub-bug can be
closed?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message sent on to martin@hinterlands.org:
Bug#348046. (full text, mbox, link).

Message #313 received at 348046@bugs.debian.org (full text, mbox, reply):

tags #348046 - help
retitle #348046 multiple GnuTLS issues - please only add information to blocking bugs
thanks

This bug report has evolved into an unmaintainable horrible mess. A
lot of the issues mentioned herein may be unrelated. I am in the
process of moving the different issues to dedicated bug reports.
Please look at the bugs that are blocking this one and only add
information if you are sure that you are experiencing the same issue
that is mentioned in the blocking bug report. If in doubt, please file
a new, unrelated report.

Messages added to #348046 are likely to be ignored.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Tags removed: help Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Fri, 22 Feb 2008 17:00:11 GMT) (full text, mbox, link).

Changed Bug title to `multiple GnuTLS issues - please only add information to blocking bugs' from `exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.'. Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Fri, 22 Feb 2008 17:00:12 GMT) (full text, mbox, link).

Blocking bugs of 348046 added: 459323 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 10:00:11 GMT) (full text, mbox, link).

Blocking bugs of 348046 added: 467136 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 10:09:27 GMT) (full text, mbox, link).

Blocking bugs of 348046 added: 467137 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 10:09:29 GMT) (full text, mbox, link).

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #328 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

block #348046 with #467136
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #333 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

block 348046 with 467137
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Blocking bugs of 348046 added: 467138 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 10:12:02 GMT) (full text, mbox, link).

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #340 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

block 348046 with 467138
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Blocking bugs of 348046 added: 467151 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 11:42:06 GMT) (full text, mbox, link).

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #347 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

block 348046 with 467151
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #352 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

block 348046 with 467152
retitle #467152 GnuTLS issues (A TLS packet with unexpected length was received) (#348046)
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Blocking bugs of 348046 added: 467152 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 12:12:11 GMT) (full text, mbox, link).

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #359 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

retitle 467152 GnuTLS issues (A TLS packet with unexpected length was received) (#348046)
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Blocking bugs of 348046 added: 467158 Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 12:15:19 GMT) (full text, mbox, link).

Information stored:
Bug#348046; Package exim4-daemon-heavy. (full text, mbox, link).

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>:
Extra info received and filed, but not forwarded. (full text, mbox, link).

Message #366 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

block 348046 with 467158
thanks

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Acknowledgement sent to Marc Haber <mh+debian-packages@zugschlus.de>, 348046@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (full text, mbox, link).

Message #371 received at 348046@bugs.debian.org (full text, mbox, reply):

tags #348046 - help
retitle #348046 multiple GnuTLS issues - please only add information to blocking bugs - see message #367
thanks

This bug report has evolved into an unmaintainable horrible mess. A
lot of the issues mentioned herein may be unrelated to each other.

The different issues listed in this bug have been moved out to
dedicated bug reports (#459323, #467136, #467137, #467138, #467151,
#467152, #467158).

Please look at these bugs only and only add information if you are
sure that you are experiencing the same issue that is mentioned in the
respective bug report. If in doubt, please file a new, unrelated
report.

Messages added to #348046 are likely to be ignored as I do not intend
to look at this horrible mess again before all blocking bugs were
resolved.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Changed Bug title to `multiple GnuTLS issues - please only add information to blocking bugs - see message #371' from `multiple GnuTLS issues - please only add information to blocking bugs'. Request was from Marc Haber <mh+debian-packages@zugschlus.de> to control@bugs.debian.org. (Sat, 23 Feb 2008 13:06:04 GMT) (full text, mbox, link).

Acknowledgement sent to SHIMIZU <adominisutoreisyon@gmail.com>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (Sat, 13 Dec 2008 08:33:03 GMT) (full text, mbox, link).

Message #378 received at 348046@bugs.debian.org (full text, mbox, reply):

Package: exim4
Version: 4.63-17
Followup-For: Bug #348046


Hi Andrew,

I encountered the same problem, so I asked a Japanese mailing list.

The resolution is simple:
Just remove the line 'tls_on_connect_ports=465:587'.

Then, I can send a message using 25 or 587 (or probably 465; not tested)
with STARTTLS with Thunderbird.

Regards,

Shimizu

-- Package-specific info:
Exim version 4.63 #1 built 20-Jan-2007 10:20:05
Copyright (c) University of Cambridge 2006
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September  6, 2005)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]        1.5.11etch2 Debian configuration management sy
ii  exim4-base                   4.63-17     support files for all exim MTA (v4
ii  exim4-daemon-light           4.63-17     lightweight exim MTA (v4) daemon

exim4 recommends no packages.

-- debconf information excluded

Message #383 received at 348046@bugs.debian.org (full text, mbox, reply):

Hi Shimizu,

SHIMIZU wrote:
> Package: exim4
> Version: 4.63-17
> Followup-For: Bug #348046
>
> I encountered the same problem, so I asked a Japanese mailing list.
>
> The resolution is simple:
> Just remove the line 'tls_on_connect_ports=465:587'.
>
> Then, I can send a message using 25 or 587 (or probably 465; not
> tested) with STARTTLS with Thunderbird.

I tried removing the entry (commented), I also tried having prots 
25:465:587 -- it was no different with any client.

Kind Regards
AndrewM

Andrew McGlashan
Broadband Solutions now including VoIP

Current Land Line No: 03 9912 0504
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

Acknowledgement sent to Sergey Dorofeev <sergey@fidoman.ru>:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (Sun, 22 Sep 2013 19:44:40 GMT) (full text, mbox, link).

Message #388 received at 348046@bugs.debian.org (full text, mbox, reply):

Package: exim4-daemon-heavy
Version: 4.80-9
Followup-For: Bug #348046

Dear Maintainer,

This error:
2013-09-22 19:33:25 TLS error on connection from (staffburg.cloudapp.net) [137.116.230.253] (gnutls_handshake): A TLS packet with unexpected length was received.
is not reproduced if exim 4.80.1 is built with GnuTLS library of version 3.2.4.
Please consider to rebuild with new version.
I am ready to help with any tests about this issue.


-- Package-specific info:
Exim version 4.80 #2 built 14-Sep-2013 07:12:53
Copyright (c) University of Cambridge, 1995 - 2012
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012
Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM Old_Demime
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot 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

-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 2.6.32-348.4.1.el5.028stab107.2 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages exim4-daemon-heavy depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  exim4-base             4.80-7+b1
ii  libc6                  2.17-92
ii  libdb5.1               5.1.29-5
ii  libgnutls26            2.12.23-5
ii  libldap-2.4-2          2.4.31-1+nmu2
ii  libmysqlclient18       5.5.31+dfsg-1
ii  libpam0g               1.1.3-7.1
ii  libpcre3               1:8.31-2
ii  libperl5.18            5.18.1-3
ii  libpq5                 9.1.9-2+b1
ii  libsasl2-2             2.1.25.dfsg1-6+deb7u1
ii  libsqlite3-0           3.7.17-1

exim4-daemon-heavy recommends no packages.

exim4-daemon-heavy suggests no packages.

-- debconf information:
  exim4-daemon-heavy/drec:

Information stored :
Bug#348046; Package exim4-daemon-heavy. (Sat, 18 Feb 2017 22:00:02 GMT) (full text, mbox, link).

Acknowledgement sent to artfies7@cp428.agava.net:
Extra info received and filed, but not forwarded. (Sat, 18 Feb 2017 22:00:02 GMT) (full text, mbox, link).

Message #393 received at 348046-quiet@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Dear Customer,

Your parcel was successfully delivered February 17 to UPS Station, but our courier cound not contact you.

Postal label is enclosed to this e-mail. Please check the attachment!

Sincerely yours,
Ramon Bradley,
UPS Chief Operation Agent.

[UPS-Label-2610089.zip (application/zip, attachment)]

Acknowledgement sent to jessicameir144@gmail.com:
Extra info received and forwarded to list. Copy sent to Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>. (Sat, 11 Mar 2023 08:24:03 GMT) (full text, mbox, link).

Message #398 received at 348046@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello dear, good afternoon, I'm Jessica Meir. Please, I wrote an earlier
email to you but still no response yet why?

[Message part 2 (text/html, inline)]

Reply sent to Marc Haber <mh+debian-packages@zugschlus.de>:
You have taken responsibility. (Sat, 11 Mar 2023 11:33:07 GMT) (full text, mbox, link).

Notification sent to martin@hinterlands.org:
Bug acknowledged by developer. (Sat, 11 Mar 2023 11:33:07 GMT) (full text, mbox, link).

Message #403 received at 348046-done@bugs.debian.org (full text, mbox, reply):

This bug is a horrible mess and hasnt advanced in 10 years. Triaging is
poiintless. Closing this bug.

If any of the issues reported in this bug still persist, please open a
bug against current exim, and please, one report per issue.

Greetings
Marc

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 09 Apr 2023 07:25:46 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Jun 5 00:11:10 2023; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #348046 multiple GnuTLS issues - please only add information to blocking bugs - see message #371

Debian Bug report logs - #348046
multiple GnuTLS issues - please only add information to blocking bugs - see message #371