On 03/08/2017 06:01, Jim Fenton wrote:
On 08/01/2017 10:17 PM, Leif Johansson wrote:
On 2017-08-01 22:08, Jim Fenton wrote:
I don't think I was suggesting anything involving Subject. There's
already some of this in Section 5.3, and I'm not crazy about doing that
either, especially since it's only a SHOULD (so the report recipient
can't really depend on it being formatted that way).
On the contrary. A SHOULD basically means you follow the spec unless
you have a good reason not to do so.
In this case, you're depending on all of the domains that send TLS
reports not to have a good reason not to do so. Maybe I'm just
extra-careful, but I don't know what good reasons might come up (maybe
some agent rewriting the Subject header field?) so I would be inclined
to not depend on it. If this Subject header field formatting stands, is
there some requirement that the requirement isn't a MUST (like the
TLS-Report-* header fields)?
Even so, recipients need to be able to handle any Subject header field
that anyone throws at them, at least to discard those messages and not
This is true.
For that reason, I think it's a good idea to minimize
the number of things that require robust checking. Isn't this
information in the payload of the report anyway? I'm not a fan of
redundant information that can be inconsistent.
Yes, this information is available in the JSON report itself, but it is
hard to extract without downloading and parsing the whole report. If one
writes an application which is mindful of bandwidth it is using (e.g.
using IMAP) and such application wants to find all reports that have a
particular property (e.g. all reports from or about a particular
domain), it is more bandwidth and CPU efficient to extract this
information from some header fields.
Uta mailing list