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]
