On Wed, Mar 25, 2026 at 06:14:41PM -0400, Deb Cooley wrote:
> That sounds like I should reject it?
That's my perspective, based the below points, that perhaps some might
dispute, so some consideration might be given as to whether my instincts
are sound:
1. The MIME attachment filenames were not intended be
machine-parseable data that carries meaningful
content in addition what's in the JSON report.
MIME filenames are largely just a courtesy to the email
recipient in the that case a report email is actually read by a
human and saved for possible later analysis as a file under a
name resembling the one suggested.
For automation there's already sufficient data in the JSON
payload to deduplicate reports and aggregate the content
into a database, nobody should be parsing the filename. Its
name is RECOMMENDED to (SHOULD) have the suggested structure.
The filename might even in some cases be too long to be used
in some filesystems.
2. True, with DANE the actual recipient domain, unlike the policy
domain, is not then reported. I view that as a privacy benefit
of DANE TLSRPT.
The operator of the MX host has no obvious need to learn which
recipient domain a particular sending domain was trying to
reach. It should be sufficient to know that a specific MX
host's TLSA records are failing to match its certificate chain,
or it is not offering STARTTLS at all, ...
If the recipient domain is essential report metadata, the JSON
syntax should be revised to include it.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Uta mailing list -- [email protected]
To unsubscribe send an email to [email protected]
