On Tue, Jul 15, 2014 at 07:17:47AM +0000, Eray Aslan wrote:
> Nice. I am guessing the motivation is making dane easier to deploy,
> especially for early adopters, by decreasing the fall out in case the
> receiver domain makes a mistake in his/her settings. Thanks.
Something like that, but potentially also useful with "secure" and
especially "fingerprint", where remote configuration changes make
authentication fragile.
> > smtp_tls_audit_template (default: empty)
> >
> > Optional template for tls audit logging at the completion of each
> > mes-
> > sage data transfer. If empty (the default setting) no TLS audit
> > log
> > entries are generated.
>
> Flexibility is nice. Let's not lose it but my guess is having a/some
> predefined template(s) -none, low, high?- will make it easier to
> maintain. Otherwise, I am afraid it will just be copy and paste from
> some web page and parsing logs will be harder than it needs to be.
> There will be too many varations around to use a standart script.
I mostly see two variants, one with spki digests, and one without.
If you can suggest specific combinations, please do. I am not
worried about parsers, all the logged fields are of the ", key=value"
variety. The "tlsaudit:" prefix should perhaps be a fixed element of
the tls audit log (when enabled).
> A general discussion for postfix logging might be in order as well.
> This parameter will set the expectations for (future?) log
> configuration.
There could be a lot more templates I guess, not sure whether this
is worth the trouble. As for the TLS audit log, another option is
perhaps to log this as part of the delivery-agent per-recipient
log entry, but then it is repeated lots of times, and absent for
recipients deferred by a non-final MX.
The current log entry is written for any transaction which gets
past EHLO/STARTTLS/AUTH to attempt to deliver an envelope. (XFORWARD,
MAIL FROM, ...). There is no TLS audit logging when SMTP session
setup fails.
--
Viktor.
