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
