Let me know soonest if this should be marked as something other than 'hold for document update'.
Deb Sec AD On Tue, Sep 23, 2025 at 3:20 PM RFC Errata System <[email protected]> wrote: > 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]
