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 N or F, then the TLS negotiation will be considered to have failed.
The probe has the form:
transport-info|app-info|channel|cert-subject|cert-issuer|cert-user
The 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 transport-info and 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.
| Flag | Description |
|---|---|
| $<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.
See also:
