One correction for the MILTER_README documentation:
> Steve Short via Postfix-devel:
> > 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.
TLS info can't be available in the EOH stage. Can you update that
for cert_issuer, cert_subject, cipher_bits, cipher, and tls_version,
too?
> 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]
>
_______________________________________________
Postfix-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
