Steve Short via Postfix-devel:
[ Charset windows-1252 converted... ]
> 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?
I think this is OK. In the SMTP server you would use the
TLScontext->peer_sni field if not NULL. TLS related information is
currently not available in the cleanup daemon, so they can be used
only in HELO, MAIL, DATA, EOH, EOM.
You would also update
https://www.postfix.org/MILTER_README.html#send-macros
Nice to have: an additional attribute in the SMTP server's check_policy
client (two lines of code), and documentation in
https://www.postfix.org/SMTPD_POLICY_README.html#protocol
Wietse
_______________________________________________
Postfix-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
