Hi,
I would like to propose adding TLS SNI as an available Postfix milter macro,
for example as {tls_sni} .
Postfix already has TLS-related milter macros such as {tls_version} ,
{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.
Suggested behaviour:
• {tls_sni} is available only after TLS has been negotiated.
• If the client does not send SNI, the macro is empty or absent, matching
existing macro conventions.
• The macro can be used in milter_helo_macros , milter_mail_macros , etc.,
depending on when the site wants to consume it.
• The name {tls_sni} follows the existing {tls_version} naming style.
This seems like a small and compatible extension: existing configurations
are unaffected, and administrators opt in by adding {tls_sni} to their
configured milter macro lists.
I can prepare a small patch to implement this if the approach is
acceptable.
Would this be acceptable upstream, or is there a preferred macro name or
milter stage for exposing this value?
Thanks,
Steve
_______________________________________________
Postfix-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
