TLS_ACCESS mapping table
(New in 8.0.1.) The
TLS_ACCESS mapping table, if it exists, will be consulted by the SMTP server after a successful STARTTLS negotiation, and by the SMTP/LMTP client after a successful STARTTLS negotiation, to determine whether the MTA is happy with the STARTTLS negotiation. This allows the MTA to, for instance, decline to permit TLS use based upon a remote side's certificate issuer. If the mapping returns a
F, then the TLS negotiation will be considered to have failed.
The probe has the form:
channel field will be the source channel in the case of the SMTP server, or the operating channel in the case of the SMTP/LMTP client. The
cert-user field will be empty in the case of the SMTP/LMTP client. See discussion of the
PORT_ACCESS mapping table, or the
MAIL_ACCESS mapping table, for discussion of the
app-info portions of the probe string, but note that the
app-info will be limited in cases where TLS negotiation occurs before an EHLO/HELO command is issued.
|$<string||Send a string to syslog.|
|$>string||Send a string to syslog if a negotiation failure is forced ($F or ($N is also set).|
|$N||(New in 8.1.) Force TLS failure and close the connection, even though negotiation succeeded, with error string string. On outgoing connections $N differs from $F in that it allows fallback to an unencrypted connection.|
|$Fstring||Force TLS failure and close the connection, even though negotiation succeeded, with error string string.|
|$Sstring||(Incoming connections only.) Switch to channnel string.|
|$B||(New in 8.1.) (Incoming connections only.) Block any subsequent channel switch by the tlsswitchchannel channel option.|
+To use multiple flags with arguments, separate the arguments with the vertical bar character,
|, placing the arguments in the order listed in this table.