TLS ACCESS mapping table

(New in 8.0.1.) The  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&#x27;s certificate issuer. If the mapping returns a   or , then the TLS negotiation will be considered to have failed.

The probe has the form: transport-info&#x7c;app-info&#x7c;channel&#x7c;cert-subject&#x7c;cert-issuer&#x7c;cert-user The   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   field will be empty in the case of the SMTP/LMTP client. See discussion of the   mapping table, or the    mapping table, for discussion of the   and   portions of the probe string, but note that the   will be limited in cases where TLS negotiation occurs before an EHLO/HELO command is issued.

 +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:
 * TCPIP channels
 * maytls Option
 * sndopr_prefix MTA Option
 * sndopr_priority MTA Option
 * Access mapping tables
 * Mapping tables