The following errata report has been submitted for RFC8460, "SMTP TLS Reporting".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8582 -------------------------------------- Type: Technical Reported by: Ömer Güven <[email protected]> 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. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- 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]
