Re: [exim] [Exim] Exim4 trying to talk to GMAIL

On Fri, 2007-11-09 at 20:36 -0800, Phil Pennock wrote:

> You probably also want to try port 587 to avoid hitting any port 25
> restrictions imposed by your ISP.
>

Thanks for your reply. OK I'll bear that in mind. I don't _think_ that's
the problem here though. How would I change the port if I wanted to do
so?

> I can confirm success using TLS and authentication to talk to Gmail. My
> configuration is rather more complex than needed though, as it handles
> multiple smarthosts for this laptop driven by a pair of external config
> files and it's not really helpful for you (beyond saying use SASL PLAIN
> (or the LOGIN gunk) authentication once you're past the TLS hurdle, and
> be aware that no matter what you put in the SMTP Envelope Sender, Gmail
> will replace it with the email address that you authenticated with).
>

That's cool -- I don't care who the email looks like it came from, as
long as it gets to the other end ;-)

> > 2007-11-07 23:05:02 1IplWg-0002Qp-Uo <= mark@satellite U=mark P=local
> > S=370
> > 2007-11-07 23:06:44 1IplWg-0002Qp-Uo TLS error on connection to
> > gmail-smtp.l.google.com [64.233.179.109] (SSL_connect):
> > error:00000000:lib(0):func(0):reason(0)
> > 2007-11-07 23:06:44 1IplWg-0002Qp-Uo TLS session failure: delivering
> > unencrypted to gmail-smtp.l.google.com [64.233.179.109] (not in
> > hosts_require_tls)
>
> You can stop the rest of the output by using hosts_require_tls for
> gmail.
>
> hosts_require_tls = *.google.com

Yeah, the log file said something about that -- unfortunately I couldn't
find in the readme where that hosts_require_tls should be set and a
Fletcher classic find / grep combination of the exim-relevant
directories I know about failed to turn up which file this setting needs
to be in. Could you enlighten me?

>
> > Now that actually has got me thinking -- is exim4 trying to do a
> > STARTTLS without first doing a HELO??? Is that configurable?
>
> No. Exim has to do the EHLO to get the ESMTP capabilities returned in
> response, whereupon it sees STARTTLS advertised. You can submit an
> email with debugging enabled and trace the SMTP. See the "-d" option to
> Exim; SMTP commands are included in the default output.
>

Thanks. Didn't know that.

> So the problem here is that your SSL library is failing when it tries to
> set up SSL to the remote side, with no apparent logging of why. My gut
> instinct reaction is to suspect that you're compiling Exim against
> differently versioned headers of OpenSSL than the library you're
> getting. Which version of "libssl-dev" is installed and which version
> does "ldd" report that Exim is linked against?
>

Unfortunately, it doesn't appear to be that.

ldd /usr/sbin/exim-4.63-1 gives the following output:

mark@satellite:/usr/sbin$ ldd exim-4.63-1
        linux-gate.so.1 =>  (0xffffe000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7f31000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7f1b000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7eed000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ec8000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ec4000)
        libdb-4.4.so => /usr/lib/libdb-4.4.so (0xb7dc9000)
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8
(0xb7d89000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8
(0xb7c4f000)        libc.so.6 => /lib/tls/i686/cmov/libc.so.6
(0xb7b1e000)
        /lib/ld-linux.so.2 (0x80000000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7b0a000)

/usr/lib/i686/cmov/libssl.so.0.9.8 is contained in the Debian package
named libssl0.9.8, version 0.9.8c-4etch1 of which is installed on my
machine. The version number of libssl-dev I have is... wait for it...
0.9.8c-4etch1. While we're about it, libcrypto.so.0.9.8 is also provided
by libssl0.9.8 and hence is at the same version.

I had a look at the files in the libssl-dev package, and that led me to
look at /usr/include/openssl where a ton of files are provided by this
package. There I found a tls1.h which is just a bunch of #defines --
including a TLS1_VERSION set to 0x0301. Clearly this doesn't relate to
the version number of the openssl library but it was a piece of
information I didn't have before, which someone might make something
of...

Any other ideas?

Mark