Re: [exim] Outlook failing gnutls_handshake after resetting …

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Ron White
Data:  
CC: Exim-users
Asunto: Re: [exim] Outlook failing gnutls_handshake after resetting up on ubuntu 9.10

On Sat, 2010-05-01 at 10:52 +0900, Jeff Wexler wrote:
> I have been googling for three days now to no avail.

I'm not sure that I can help, but my recent toe dipping into Exim4 has
meant a great deal of reading and a couple of things ring a bell with me
- mostly from my time spent here:
http://exim.org/exim-html-4.50/doc/html/spec_38.html#CHAP38

>
> I am able to receive email fine but can no longer send. My configuration
> requires TLS over port 587.

First of all I read somewhere (and I can't find it) that there is an
issue with Microsoft clients and the submission port 587. The gist of it
was it that port 465 is made available for this to satisfy M$ clients
and this little ditty: tls_on_connect_ports = 465 forced TLS to be
required on connect, rather than with STARTTLS.

In effect the main section of my runtime conf looks like this:
daemon_smtp_ports = smtp : smtps : submission
tls_advertise_hosts = *
tls_on_connect_ports = 465
tls_certificate = /etc/exim/tls/cert
tls_privatekey = /etc/exim/tls/privkey

Testing the connection (without using the M$ client to eliminate it:
PORT 25 with STARTTLS:
openssl s_client -starttls smtp -connect 1.2.3.4:25

PORT 465 WITH TLS ON CONNECT
openssl s_client -connect 1.2.3.4:465

PORT 587 (SUBMISSION) WITH STARTTLS
openssl s_client -starttls smtp -connect 1.2.3.4:587


This stood out to me:
>
> - Ephemeral Diffie-Hellman parameters


Looking at the Exim book by Philip Hazel it mentions the need to set
tls_dhparam to a filename to make use of the Diffe-Hellman ciphers and I
confess that I have not been able to construct a suitable file to do
that myself, so currently I don't use that cipher suite. The link above
mentions it.


One last thing, when generating your certificate/key you didn't put a
passphrase in? If you know your previous cert/key worked I would stick
with that.

I'm not sure if any of this will help you at all - but I would rule the
client out first using openssl to connect. Also a quick TCPdump to see
what port the M$ is actually trying to connect on may eliminate any
doubt.

I hope that helps and does not lead you up the garden path.

Warm regards
Ron