Re: [exim] General protection error

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Phil Pennock
Dátum:  
Címzett: Pawel Rutkowski
CC: exim-users
Tárgy: Re: [exim] General protection error
On 2011-09-11 at 18:49 +0200, Pawel Rutkowski wrote:
> Yes, now more information:
>
> (gdb) bt
> #0 0x000000000046b660 in smtp_read_response
> (inblock=0x7ffff18bad50,buffer=0x7ffff18b9d10 "220 proksima.home.pl ESMTP
> IdeaSmtpServer v0.70 ready.\r", size=4041, okdigit=50, timeout=300) at
> smtp_out.c:512
> #1 0x0000000000491950 in smtp_deliver (addrlist=0x16f07820,
> host=0x16f07a60, host_af=2, port=25, interface=0x16f07ba0 "193.99.999.99",


"193.99.999.99"?

I'm trying to help, but this sort of editing of the stack backtrace does
_not_ help. :(

Can you make the coredump and binary available, please? This is for an
outbound connection, so Exim will have re-exec'd and any authentication
credentials from the client will not be in there, and you're talking out
on port 25, so I'm assuming no auth there. If you're using an SSL
client certificate, that might be an issue.

When this stacktrace occurs, the "buffer" parameter has already been
used for storing the line read from the server, so this is a problem
parsing the connection banner.

In the 4.76 release, line 512 is checking the status code at the start
of the line; there's a small assumption that the buffer will always have
been more than four characters large (always true), so that the count<3
check is not ensuring that a '-'/' '/'\0' will have come from the remote
server; if there's any kind of problem here, it's that a
heavily-fragmented response which only returned three characters might
spuriously return ERRNO_SMTPFORMAT. Certainly no segfault from this.
And besides, we can clearly see that we _did_ get a full response.

In testing myself, Exim does _not_ segfault; instead, there's a "550
5.1.1 User not found" in response to <postmaster@???>; but
hey, it got further than the connection banner. It also successfully
negotiated TLS and got the second connection banner, and this is using
OpenSSL (albeit a more modern version).

Checking up a level, smtp.c:945 is clearly before the TLS negotiation,
so that doesn't enter into it.

Without a coredump and executable (with debugging information), I'm at a
dead end and can't investigate further.

-Phil