Re: [exim] Cutthrough routing

Góra strony
Delete this message
Reply to this message
Autor: Jeremy Harris
Data:  
Dla: exim-users
Temat: Re: [exim] Cutthrough routing
On 2012-01-21 20:02, Heiko Schlittermann wrote:
> Do you think, that your cuthrough extension can be even more extened to
> provide "normal transports" (including all that TLS options) for smtp callouts?


I'm not quite clear what you're asking here.  Since an smtp connection is being
made by the verify-callout code, it's fundamentally similar to the smtp transport
and different from all the others (apart maybe from lmtp?).  Are you you talking
about the options on transports?  I suspect a few may work but not all, depending
on if they are handled by the routing-and-transport lookup for the destination
rather than some code in the smtp transport.   There *is* a call in the verify
path to a transport set routine, commented
       /* If verification yielded a remote transport, we want to use that
       transport's options, so as to mimic what would happen if we were really
       sending a message to this address. */
so the odds are good.    But I've not checked in detail.


Separate versions of the "in" and "out" variables are maintained for
$tls_certificate_verified, $tls_cipher, $tls_peerdn. The existing variable
names get the inbound set; $tls_out_peerdn et.al. get the outbound set.
This is an incompatible semantics change we may need to think hard about
(cf. para 3 of http://exim.org/exim-html-current/doc/html/spec_html/ch30.html ).

Transport filters are not supported.

Really what's needed here is a major refactoring so that the same code is used
for both the traditional routing and transport and the verify-callout. What we
have currently is the same job being done in two places, duplicating a lot of code.
However, that's more work that I was prepared to put in. A consideration for
the future Exim 5, perhaps.


I agree with you that having (even non-cutthrough) callouts able to use TLS
is a good thing - it reduces the visibility surface to snoopers. One thing though
that isn't handled is AUTH. I expect certificate use to become more common
over time, and that will need adding too. I don't think it's too difficult for any
architectural reason.

There could be some handling of SIZE; missing at present. I didn't feel that
PIPELINING was worthwhile, and I didn't even think about 8BIT.

SMTP-over-SSL is coded for as well as TLS, though I've not tried it.


One thing I forgot to make clear in the announcement mail: only a single
destination recipient is handled; any more and the outbound connection is
cancelled. This holds for both multiple received RCPT TO: commands and
for addresses generated by routing.

-- 
Cheers,
     Jeremy