> On Nov 21, 2018, at 11:28 AM, J. Thomsen <l...@jth.net> wrote:
>
> This may be true in the production phase, but hardly an issue in an
> implementation phase, when the
> implementor needs to know, if the system is acting as expected and the
> loglevel is increased.
So it seems you're NOT asking for more verbose routine logging under
"normal" ("production") conditions. That changes the discussion.
Any fine-grained TLS log mask beyond the legacy "levels" (0, 1, 2, 3, 4)
is essentially an implementation artefact. So this is not described in
the documentation of "smtp_tls_loglevel", and may change incompatibly.
The"smtp_tls_loglevel" and "smtpd_tls_loglevel" parameters are two rare
departures (no others immediately come to mind) from the Postfix design
principle of no undocumented features. The syntax that you see for the
"-L" option with posttls-finger(1) is actually also available with the
"smtp_tls_loglevel" and "smtpd_tls_loglevel" parameters.
Perhaps this thread can resolve the tension between making sure that the
interfaces we document are stable, and also making sure we don't have
undocumented features.
The idea would be to document for "smtpd?_log_level" only 0--4 (as is now
the case), but also note that more fine-grained logging options are
available as described for the "-L" option in the posttls-finger(1)
manpage. The posttls-finger "-L" log mask is not a stable interface, all
I can say is that it does not change capriciously.
So to be clear:
* No promise that any "loglevel" other than 0--4 will work in production.
* However, values documented for posttls-finger(1) for the *same* Postfix
release should work in practice.
It seems you're looking for:
smtp_tls_loglevel = summary, certmatch
Or perhaps even:
smtp_tls_loglevel = summary, certmatch, verbose
Maybe along with:
smtp_tls_fingerprint_digest = sha256
Repeat warning: unstable interface.
--
Viktor.
