Re: [exim] the great TLS mystery

Inizio della pagina
Delete this message
Reply to this message
Autore: WJCarpenter
Data:  
To: exim-users
Oggetto: Re: [exim] the great TLS mystery

> % exim -bV
> % exim -bP | fgrep tls


Here you go....

===========================

Exim version 4.71 #1 built 08-Feb-2011 21:53:28
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.8.24: (August 14, 2009)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS
move_frozen_messages Content_Scanning DKIM 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
GnuTLS compile-time version: 2.8.5
GnuTLS runtime version: 2.8.5
Configuration file is /etc/exim4/exim4.conf

===========================

acl_smtp_starttls =
auth_advertise_hosts = ${if or {{!eq{$tls_cipher}{}}
{eq{$received_ip_address}{$sender_host_address}}} {*}{}}
no_gnutls_compat_mode
gnutls_require_kx =
gnutls_require_mac =
gnutls_require_protocols =
log_selector = -acl_warn_skipped +address_rewrite +all_parents
-arguments +connection_reject +delay_delivery +deliver_time
+delivery_size -dnslist_defer -etrn +host_lookup_failed -ident_timeout
-incoming_interface +incoming_port +lost_incoming_connection
+outgoing_port -queue_run +queue_time +queue_time_overall -pid
+received_recipients +received_sender +rejected_header -retry_defer
+return_path_on_delivery +sender_on_delivery +sender_verify_fail
+size_reject -skip_delivery +smtp_confirmation -smtp_connection
-smtp_incomplete_transaction -smtp_no_mail -smtp_protocol_error
-smtp_syntax_error -subject +tls_certificate_verified +tls_cipher
+tls_peerdn -unknown_in_list
received_header_text = Received: ${if def:sender_rcvhost {from
$sender_rcvhost\n\t}{${if def:sender_ident {from
${quote_local_part:$sender_ident} }}${if def:sender_helo_name
{(helo=$sender_helo_name)\n\t}}}}by $primary_hostname ${if
def:received_protocol {with $received_protocol}} ${if def:tls_cipher
{($tls_cipher)\n\t}}(Exim $version_number)\n\t${if def:sender_address
{(envelope-from <$sender_address>)\n\t}}id $message_exim_id${if
def:received_for {\n\tfor $received_for}}
tls_advertise_hosts = ! +aio_hosts
tls_certificate = /etc/acceptio/acceptio-wild.crt
tls_crl =
tls_dhparam =
tls_on_connect_ports = 465
tls_privatekey = /etc/aio/aio.key
no_tls_remember_esmtp
tls_require_ciphers =
tls_try_verify_hosts =
tls_verify_certificates =
tls_verify_hosts =

(The "aio_hosts" mentioned in the config is just a list of my servers.)

> Are you 100% sure that the error message corresponds to the telnet
> sessions, not just Thunderbird?


Right, let's ignore Thunderbird for the moment and concentrate on the
direct telnet connections. TB is just what got me started. If I can
get to the bottom of the telnet mystery, I'm confident of being able to
sort out the TB stuff. (And I switched that particular user to
immediate TLS on port 465, so he's operational and the time pressure is
off.)

I can tell the telnet entries because the user and I literally did "ehlo
foo", and the "foo" shows up in the logged timeout line. Here's a
complete example:

2011-02-23 16:23:05 SMTP command timeout on TLS connection from
adsl-074-166-089-153.sip.asm.bellsouth.net (foo) [74.166.89.153]:50998

(The connections from his TB are similar, but distinct.)

Here is how I have more ports configured in exim4.conf:

daemon_smtp_ports = 25 : 8111 : 587 : 465
tls_on_connect_ports = 465

Port 8111 is for people who need to escape firewalls. My user's telnet
was to port 587. I've tried all of 25, 8111, and 587 with equivalent
results (different from his results). I've asked my user to try port
8111 but don't have those results yet. One of my hypotheses is that his
ISP is transparently proxying SMTP and injecting the AUTH advertisement
into the EHLO response (for reasons unknown, but clearly looney if
true). If that's so, they may be watching ports 25 and 587, but they
will be unlikely to be watching port 8111 (for SMTP anyhow).

His ISP is bellsouth.net. Does anyone know of any weird
firewall/filtering junk they might be doing?