I'm about ready to push this feature into the mainline. I'd like to
do it soon so that it gets exposure well before the next release.
Questions:
- Should I hide it behind an EXPERIMENTAL compile-time feature test?
I'd rather not as the code changes are invasive, and #ifdeffing them would
be a whole bunch of work and introduce complexity (therefore, bugs). The
main feature does not activate unless specifically requested, using new syntax
(control = cutthrough_delivery in an ACL) so there should be no inadvertent
use by existing configurations. On the other hand the secondary feature
(use of TLS by verify-callouts) *will* activate automatically.
- There's currently an incompatible change in the $tls_* variables.
Because the feature introduces the possibility of two concurrent open
TLS conversations, the controlling data for them was duplicated.
For those items exposed via variables, the traditional variable names
now access the data for the inbound (server mode) connection.
New variables named $tls_out_* access the data for the outbound (client
or delivery mode) connection. The incompatibility arises when the
old names are used in the context of an smtp transport (cf. the Fine Manual
ch. 30 section 3).
Is this change acceptable? Or should I introduce $tls_in_* (for consistency)
and reinstate the context-dependent meaning of the old names? Or
remove the old names entirely?
There's a git branch "cutthrough-2" on tahini for anyone who cares to
look at the implementation. It's moderately recent; I need to add a couple
more test cases and the documentation.
--
Thanks,
Jeremy
