The following errata report has been rejected for RFC8460, "SMTP TLS Reporting".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8582 -------------------------------------- Status: Rejected Type: Technical Reported by: Ömer Güven <[email protected]> Date Reported: 2025-09-23 Rejected by: Deb Cooley (IESG) Section: 5.1 (and 4.4) Original Text ------------- filename = sender "!" policy-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension Corrected Text -------------- filename = sender "!" recipient-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension Notes ----- Section 5.1 currently mandates that the TLSRPT filename be constructed with policy-domain. The policy-domain as defined in Section 1.1 may differ from the recipient domain (MX host for DANE and undefined for no-policy-found cases) and is already included in the JSON. In practice, TLSRPT filenames almost always contain the recipient domain, which is defined earlier in the RFC but never included in the JSON itself. Implementing Section 5.1 literally (using the policy-domain instead of the recipient domain) would break TLSRPT for shared report mailboxes. For example: - Multiple customer domains sharing an MX provider - External MX smart hosts implementing DANE, where the policy-domain is the MX hostname providing TLSA records In these cases, the report recipient cannot reliably determine which recipient domain the report is aimed at if only the policy-domain is used in the filename. Suggested correction: 1. Update the filename ABNF to use the recipient domain instead of the policy-domain to reflect the status quo. 2. Include a consistent recipient-domain field in the TLSRPT JSON for unambiguous identification. This ensures parsers can reliably determine which recipient domain the report is intended for, preserves TLSRPT’s usefulness for shared mailboxes, and allows easier and standardized implementation across different reporting environments. --VERIFIER NOTES-- The MIME filename hint does not have semantic significance. This is a RECOMMENDED value, and a receiving system should generally ignore this entirely, and process the report JSON payload without regard to the filename. For obvious security reasons the filename must not be trusted, and the report might never be stored as a separate file, with results stored in a database or transformed into an API call. The recipient domain is not a better choice, but it really should not matter, the filename is a nonce, it has no semantic value. -------------------------------------- RFC8460 (draft-ietf-uta-smtp-tlsrpt-23) -------------------------------------- Title : SMTP TLS Reporting Publication Date : September 2018 Author(s) : D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher Category : PROPOSED STANDARD Source : Using TLS in Applications Stream : IETF Verifying Party : IESG _______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
