On 2012-06-01 at 22:49 +0100, Jeremy Harris wrote:
> 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.
Good plan.
> - Should I hide it behind an EXPERIMENTAL compile-time feature test?
If the fundamental API is likely to change, then yes; otherwise no. I
hit OCSP behind that because the current interface requires too much
admin scripting support: it will let us gain experience, but the real
API will change.
I suspect EXPERIMENTAL is not needed here, *except* for the issue of the
variables ...
> On the other hand the secondary feature
> (use of TLS by verify-callouts) *will* activate automatically.
Please not unless specifically requested: TLS is quite heavy and that
adds to the verify burden. Can you make this something that has to be
enabled, either by "verify_tls" on the transports, or a flag on the
ACL control modifier?
> - 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?
What I did for GnuTLS was bundle all of these up, and make it possible
to "activate" either set of names with a function call that mostly just
repoints pointers, not doing anything fundamental beyond that.
Did this help at all? Would it help if I did something similar for
OpenSSL? We're 1/4 of the way there already, with the "callback" data
structure used for SNI.
I favour $tls_in_* and $tls_out_* and keep the existing names, resetting
as appropriate. Mark the existing names deprecated and state that we're
likely to remove them in, say, Exim 5.
We should plan on making Exim5 get rid of $1/$2/... in authenticators,
$tls_notinorout, and any other historical baggage.
Established stance was the miniconf a couple of years back was that if
there's a major new feature, we'll jump to 5, otherwise 4.99 will just
be followed by 5.00.
*If* we don't have a major new backwards-incompatible feature, I suspect
we should plan on cutting over sometime in the 4.9x line and try to make
5.00 have ~no new features, just get rid of the historical cruft and
force a config update.
I start a new job in a couple of weeks and am about to once more have
~no time for Exim, or I'd start acting on some elaborate plans for
native list-type support and revamping a chunk of the language and make
that 5. Tony Finch has some similar vague ideas, I believe.
-Phil
