Re: [exim] postfix ssl_accept error and exim remote_smtp def…

Pàgina inicial
Delete this message
Reply to this message
Autor: Phil Pennock
Data:  
A: Jelle de Jong
CC: exim-users
Assumpte: Re: [exim] postfix ssl_accept error and exim remote_smtp deferterminated by signal 11
On 2009-06-19 at 19:09 +0200, Jelle de Jong wrote:
> I would also like to point that signall 11 is SIGSEGV Core Invalid
> memory reference aka segmentation fault that happens on the exim side,
> that does not sound good, but I don't know why it is happening, I hope
> somebody can help.


This is not normally a sign of a problem in Exim itself, which has a
mature codebase, but a sign of something like a library conflict, with
Exim built against one version of a library and then another version
being used.

The next version of Exim will hopefully report conflicts like this; see:
http://bugs.exim.org/show_bug.cgi?id=745

> The postfix server has no other ssl_accept errors and is able to receive
> tls secure mail from other servers. I just don't see what goes wrong.


nb: -qff runs the entire queue, you want -M <message id> instead.

exim-server-a-information-discreet.txt shows successful delivery over
SSL, with the message accepted by the remote side. Twice.

I'm not seeing here evidence of the problem which you're reporting.

I don't read postfix logs well, but well enough to see that you didn't
censor the logs quite well enough to avoid showing via /etc/mailname
which serverb is. Note though that censoring data from the people
you're asking for help is somewhat frowned upon.

In this case, you seem to be showing logs from a different connection,
since postfix is complaining:
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept:before/accept initialization
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90 [B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from alphaip2.servera.nl[12.34.56.789]: -1

and since server-a showed successful delivery, with the message accepted
and logging the recipient's transaction message id (BAB1C5E883 and then
later 4D1135E883), these clearly don't line up.

-Phil