> > an exim problem with openssl on the server, and it returned an error about
> > being unable to verify because it was "unable to get local issuer certificate."
>
> Looks like you have no root CAs installed in your system.
It turns out that Debian's openssl is kind of broken, and this is a known issue
(
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/396818). I've tried
rebuilding it (and Exim), but `openssl s_client -starttls smtp -connect
smtp.gmail.com:587` still doesn't work without `-CApath=/etc/ssl/certs` (which
were installed by Debian's ca-certificates). I think this might be affecting
exim, because the main issue is, like you said, that there aren't any root CAs
(that it can recognize, at least). For building openssl, I've tried to set a
few different permutations of `./config --prefix=/usr --openssldir=/etc/ssl`,
but I haven't managaged to get this working. Is this not actually a problem,
and I've misconfigured Exim's recognition of mailserver SSL, or is it not
recognizing the right openssl, or something?
I've tried both ways of including OPENSSL in Local/Makefile (with and without
pkg-config), but neither worked. I figure this is the root of the issue, so how
should I configure the build of Exim/openssl/some other package to handle this?
> Typically 30-60s delays are due to waits for DNS responses. Check your DNS
> environment: contents of /etc/resolv.conf, name servers operation, etc.
This stuff is just default. The Digital Ocean droplet config uses their DNS
servers, and the log doesn't show any significant DNS resolution delays.
/etc/resolv.conf and resolution of https/ftp stuff (like with wget) looks fine.
> You can also run "strace -Tfp <exim_daemon_pid>" to look which syscalls
> lead to those delays.
I did this, and it's getting stuck on `rt_sigsuspend(~[ALRM RTMIN RT_1, 8`. I'm
not really sure how to read these logs, though.
