Your message dated Wed, 26 Dec 2012 11:14:22 +0100
with message-id <[email protected]>
and subject line Re: Bug#517394: exim4-daemon-heavy: Incoming connection fails
with "(gnutls_handshake): A TLS fatal alert has been received."
has caused the Debian Bug report #517394,
regarding exim4-daemon-heavy: Incoming connection fails with
"(gnutls_handshake): A TLS fatal alert has been received."
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
517394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517394
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: exim4-daemon-heavy
Version: 4.69-9
Severity: normal
In Lenny, incoming connection from one server (only) fails with the following
error message:
2009-02-27 09:36:56 TLS error on connection from mail.example.com (example.com)
[1.1.1.1] (gnutls_handshake): A TLS fatal alert has been received.
With etch connections worked fine:
2009-02-09 16:46:30 1LWYL8-0001xb-Cl <= [email protected] H=mail.example.com
(example.com) [1.1.1.1] P=esmtps X=SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24 DN=""
S=3725 [email protected]
Sending *to* the same server (it is apparently both the outgoing and incoming
server) with TLS works just fine:
2009-02-27 10:45:05 1LczGy-0002Bj-Ml => [email protected] <[email protected]>
R=dnslookup T=remote_smtp H=mail.example.com [1.1.1.1]
According to the 200 welcome message, the remote server runs CommuniGate Pro
5.2.7:
220 gerstel.com ESMTP CommuniGate Pro 5.2.7
I consider this a bug in exim4 as TLS communication with this particular server
worked fine with etch but broke in lenny - though I of course know that
CommuniGate might be to blame.
Disabling TLS for this particular host (see below) apparently fixes the problem
but I see it as a workaround and not a real solution.
I am unsure how to proceed now (I have no control of the remote server
whatsoever), but I will gladly debug, help and provide information on this.
I have the following TLS-related configuration (also see my
update-xim4.conf.conf later):
root@gere:/etc/exim4# cat /etc/exim4/conf.d/main/00_local
MAIN_TLS_ENABLE='true'
daemon_smtp_ports = smtp : submission : ssmtp
tls_on_connect_ports = 465
MESSAGE_SIZE_LIMIT=512M
CHECK_RCPT_SPF='true'
CHECK_RCPT_IP_DNSBLS = sbl-xbl.spamhaus.org : dnsbl.sorbs.net : bl.spamcop.net
CHECK_RCPT_DOMAIN_DNSBLS = rhsbl.sorbs.net : rhsbl.ahbl.org
REMOTE_SMTP_HOSTS_AVOID_TLS = 1.1.1.1
MAIN_TLS_ADVERTISE_HOSTS = !1.1.1.1 : !mail.example.com
Regards
/Rasmus Bøg Hansen
-- Package-specific info:
Exim version 4.69 #1 built 30-Sep-2008 18:26:44
Copyright (c) University of Cambridge 2006
Berkeley DB: Berkeley DB 4.6.21: (September 27, 2007)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc 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 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
# /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='internet'
dc_other_hostnames='a.b.c.d:[a.b.c.d]:gere:gere.example.dk:/etc/exim4/domains'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='10.0.0.0/24 ; 127.0.0.1 ; ::1'
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
mailname:example.dk
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.28.7 (SMP w/2 CPU cores)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to da_DK.UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages exim4-daemon-heavy depends on:
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii exim4-base 4.69-9 support files for all Exim MTA (v4
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [
ii libgnutls26 2.4.2-6 the GNU TLS library - runtime libr
ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries
ii libmysqlclient15off 5.0.51a-24 MySQL database client library
ii libpam0g 1.0.1-5 Pluggable Authentication Modules l
ii libpcre3 7.6-2.1 Perl 5 Compatible Regular Expressi
ii libperl5.10 5.10.0-19 Shared Perl library
ii libpq5 8.3.6-1 PostgreSQL C client library
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra
ii libsqlite3-0 3.5.9-6 SQLite 3 shared library
exim4-daemon-heavy recommends no packages.
exim4-daemon-heavy suggests no packages.
-- debconf information:
exim4-daemon-heavy/drec:
--- End Message ---
--- Begin Message ---
Version: 4.70~cvs+20091017-1
On 2009-03-03 Andreas Metzler <[email protected]> wrote:
> On 2009-03-02 Rasmus Bøg Hansen <[email protected]> wrote:
> > Andreas Metzler skrev:
> [...]
> >> Could you doublecheck whether disabling certificate verification works
> >> as a workaround?
> >> MAIN_TLS_VERIFY_CERTIFICATES = /dev/null
> > This does indeed fix the problem!
> Looks like we found another instance of #482420 or #515999.
Marking is fixed, therefore.
* Do not set 'tls_try_verify_hosts = *' by default anymore. Some clients
(e.g Outlook) will terminate the SSL connection when the server presents
the long list of accepted TLS certificates after STARTTLS. If TLS
certificate validation of clients is needed you'll need to set
MAIN_TLS_TRY_VERIFY_HOSTS again and point MAIN_TLS_VERIFY_CERTIFICATES to
a file containing only the accepted certificates.
Closes: #515999, #316522, #482012
--- End Message ---
