著者: Jeremy Harris 日付: To: exim-dev 題目: Re: [exim-dev] [exim] Exim 4.89 RC6 tomorrow (Wednesday)
On 16/02/17 05:05, Phil Pennock wrote: > On 2017-02-15 at 03:40 +0000, Phil Pennock wrote:
>> We have one outstanding report of message segfaults, on one
>> system. I don't believe these have been reproduced by anyone
>> else, but I'm waiting for more feedback from the reporter: if
>> there is a bug in Exim here,
>
> There's something real here, and I don't see a point in doing RC6
> without it. If you're running RCs, please disable advertising
> chunking until RC6.
>
>> So we should have RC6 sometime on Wednesday.
>
> Nope, that was optimistic.
>
> It seems likely that final release will _not_ happen on Monday.
I've pushed a branch to hummus "debug_store" which provides a
main config option to enabled (on a production system) the extra
memory/variable checks that cf0812d57c63 added under the
testsuite. I'd intended to hold this for the next release-cycle,
but feel free to grab if it's useful for the outstanding 4.89
issue investigation.
Separately, on the TLS / continued-connection front: a branch on
hummus, "transport_tls_continue" with a prototype for discussion.
As discussed between PDP & JGH, this implements a proxying
process to handle the TLS endpoint. Benefit is avoiding a TLS
teardown & rebuild (both ends of the connection), cost is
having to proxy the SMTP across an extra process (client end only).
In a fit of paranoia it's disabled by default, on a transport
option. Opinions on that?
Issues:
- - ordering of message deliveries changes. I don't think that's a
problem.
- - ordering of delivery log lines does not match time-order of
deliveries. In particular, the earliest message gets displayed
last; because the process is busy proxying all the rest before
it gets around to triggering its own log line.
- - The continued-delivery log lines (ones with the "*" marker) are
missing any TLS information; because the process sending the
log info no longer starts the TLS it has no info. So no X=cipher,
CV, OCSP or DS markers on those deliveries; one has to locate
the "initiating delivery" log line (the one for the same host
but lacking the "*".
That last one is worst, I think. Is is bad enough to worry over?
I could pass more strings on the command-line at the exec for the
continued-transport (there's already a couple, for the local IP/port)
but how far to go?
