Thanks Wietse and Viktor. I have taken your comments into consideration and I will a) update the documentation and b) soften the wording on the usefulness of this for tenant identification.
Regards Steve From: Viktor Dukhovni via Postfix-devel <[email protected]> Date: Friday, 26 June 2026 at 15:57 To: [email protected] <[email protected]> Subject: [pfx-dev] Re: Proposal: expose TLS SNI as a Postfix milter macro External: Pause and review the sender's email address, any URLs before clicking links, opening attachments, or following requests. When in doubt, contact the Service Desk. On Fri, Jun 26, 2026 at 12:42:40PM +0000, Steve Short via Postfix-devel wrote: > {cipher} , {cipher_bits} , {cert_subject} , and {cert_issuer} . SNI is > similarly connection-level TLS metadata, and Postfix already records it > internally for TLS certificate selection/logging. Exposing it to milters > would let policy/filtering services make routing or tenant attribution > decisions. > > The use case is a multi-tenant SMTP server where different customer > hostnames terminate on the same Postfix listener. The recipient domain is > not always a reliable tenant signal, and HELO is client-provided. SNI is the > cleanest server-side signal for the hostname the client intended to connect > to. I should temper your expectation of receing meaningful SNI indications. - This of course depends on the multiple tentant domains MX hosted by a common backend each using its distinct MX hostname. That's a not a good practice. Best practice, and Far easiler to manage correctly in terms of certificate provisioning, DANE provisioning, ... is a single common MX hostname across all the tenant domains. - You can't expect SMTP clients to consistently send the nexthop MX hostname as the SNI name even when the tenant MX hostnames happen to be distinct. For example Postfix default to not send SNI unless doing DANE (or perhaps MTA-STS). So while the SNI name can be useful forensically, relying on it for routing decisions would be unwise. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ Postfix-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Postfix-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
