Skip to content

update Received headers for rfc8314 (tls trace)#4

Open
rtdean wants to merge 1 commit into
bruceg:masterfrom
rtdean:feat-add-tls-info-to-received-headers
Open

update Received headers for rfc8314 (tls trace)#4
rtdean wants to merge 1 commit into
bruceg:masterfrom
rtdean:feat-add-tls-info-to-received-headers

Conversation

@rtdean
Copy link
Copy Markdown

@rtdean rtdean commented May 22, 2026

RFC8314 outlines the use of TLS for email submission, access, and transport. As a part of this, in section 4.3, they build on the trace capability defined in RFC3848 for recording the ciphersuite and dh group information in the Received trace header.

While working to modernize a qmail stack using mailfront, I noticed that mailfront didn't emit any type of TLS trace headers today, unlike the qmail-smtpd tls patch that had been in use.

This attempts to bridge that gap (lack of TLS trace information in Received headers) in a RFC-compliant way.

As for why gnutls_ciphersuite_get(), 8314 indicated that they really wanted the IANA-registered TLS ciphersuite string, and gnutls_ciphersuite_get provided that. If it doesn't exist (gnutls too old), it just degrades into not adding the TLS trace information.

RFC8314 outlines the use of TLS for email submission, access, and
transport.  As a part of this, in section 4.3, they build on the trace
capability defined in RFC3848 for recording the ciphersuite and dh group
information in the Received trace header.

While working to modernize a qmail stack using mailfront, I noticed that
mailfront didn't emit any type of TLS trace headers today, unlike the
qmail-smtpd tls patch that had been in use.

This attempts to bridge that gap (lack of TLS trace information in
Received headers) in a RFC-compliant way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant