I am having some problems with the STARTTLS feature in exim on one server.
Basically, when a mail is sent, encrypting it always fails and only
after quite a while (but there is not much entropy on this system).
Here is a partial exim -d+tls output:
88.198.37.140 in hosts_avoid_tls? no (option unset) SMTP>> STARTTLS waiting for data on socket
read response data: size=18
SMTP<< 220 TLS go ahead
initializing GnuTLS as a client
generating 512 bit RSA key...
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
generating 768 bit Diffie-Hellman key...
wrote RSA and D-H parameters to file
initialized RSA and D-H parameters
no TLS client certificate is specified
initialized certificate stuff
initialized GnuTLS session
LOG: MAIN
TLS error on connection to elrond.llorien.org [88.198.37.140]
(gnutls_handshak
e): A record packet with illegal version was received.
ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1 first_address is
not NULL
88.198.37.140 in hosts_require_tls? no (option unset)
LOG: MAIN
TLS session failure: delivering unencrypted to elrond.llorien.org
[88.198.37.1
40] (not in hosts_require_tls)
When not encrypted, delivery runs fine.
I manage tens of other exim servers with the exact same version and OS.
I even removed exim and gnutls and reinstalled them just in case a
package was corrupted. 88.198.37.140 (which also runs exim) is know to
work in TLS with all the other servers, so the problem is not there.
I suspect there is an application layer firewall which breaks TLS
somewhere at the ISP side. What do you think about this?
And if there is an application layer firewall, how could I prove it
actually exists.
