On 2012-11-02 at 13:32 -0600, The Doctor wrote:
> 2012-11-01 22:08:42 1TU8XV-0006bT-9B == [email protected] R=dnslookup
> T=remote_smtp defer (-1): smtp transport process returned non-zero status
> 0x000b: terminated by signal 11
> 2012-11-01 22:09:42 1TU8Yn-0006h2-F0 == [email protected] R=dnslookup
> T=remote_smtp defer (-1): smtp transport process returned non-zero status
> 0x000b: terminated by signal 11
That means that the Exim delivery process is crashing with a SIGSEGV,
because of the TLS usage. So you're crashing inside OpenSSL.
To date, there have been three reasons for this:
(1) memory corruption on a bad system, flipping bits
(2) Exim built against a different version of OpenSSL than running
against
(3) Unknown cause, happening deep inside OpenSSL.
The third case was fairly recently on exim-dev. Only one report so far,
so if this is the problem you have then you'd make report #2.
The problem here is that Exim is setuid, so crash-dumps are normally
inhibited by the kernel and it requires a lot of potentially dangerous
fiddling to override that. So proving where this happens requires some
diagnostic and C programming skill.
For this third case, so far it looks like a mystery crash inside OpenSSL
and we haven't yet found a cause or anything that Exim is doing to
trigger it.
Building against GnuTLS avoids the issue.
Can you tell us more about how OpenSSL was built?
-Phil
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
