I've been working on improving improve Postfix logging for TLS related features, and decided to add one relatively small field to Postfix delivery status logging.
- The logging is inserted between the "delays=a/b/c/d" and the "dsn=x.y. (random text)" information. This might trip up some log analysis tool, so it can be turned off if needed. r The general format is "tls=feature-status/feature-status/...". See below for examples. - The first feature name is the TLS security level: 'none', 'may', 'encrypt', etc. Other features are shown only if activated. Generally, feature? means that a feature could not be usd due to connection failure, !feature means the connection was not used due to policy violation, and (feature) means that security was relaxed as allowed by policy (for example '(may:none)' for opportunistic TLS that falls back to 'none' when a server does not support STARTTLS). More theory is at https://www.postfix.org/postconf.5.html#smtp_log_tls_feature_status Wietse Examples for TLS: tls=none A connection that did not use TLS. tls=may Opportunistic TLS. The connection was used after a successful TLS handshake. tls=may? Opportunistic TLS. The status was undecided because no server could be reached. tls=(may:none) The remote server did not support STARTTLS, and the connection was used in plaintext as permitted by an opportunistic TLS policy. tls=dane DANE policy compliant, no downgrade. tls=(dane:encrypt) Opportunistic DANE. The connection security was downgraded to 'encrypt' because none of the TLSA records were usable. tls=(dane:may) Opportunistic DANE. The connection security was downgraded to 'may' because no TLSA records were available (according to a DNSSEC-signed response). Examples for TLS with REQUIRETLS (almost ready for production): tls=may/(requiretls) Opportunistic TLS + opportunistic REQUIRETLS. After a successful TLS handshake without server certificate checks, the server announced REQUIRETLS support, and the connection was used with REQUIRETLS as permitted by an opportunistic REQUIRETLS policy. (strict REQUIRETLS would require a server certificate match, i.e. TLS level of 'dane', 'secure' or some other level stronger than 'encrypt'). tls=dane/requiretls DANE and REQUIRETLS policies were fully enforced, non-error case. tls=dane/!requiretls DANE and REQUIRETLS policies were fully enforced. The connection was not used because the server did not support REQUIRETLS and enforcement of REQUIRETLS was not relaxed. tls=dane/(requiretls:none) DANE was fully enforced. The remote server did not support REQUIRETLS, and the connection was used without REQUIRETLS as permitted by an opportunistic REQUIRETLS policy. tls=dane?/requiretls? DANE and REQUIRETLS policies were undecided, because the connection failed before or in the TLS handshake. _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
