Trimming... On Thu, Nov 28, 2024, at 07:24, Daniel K. wrote: > The fields are really defined in dmarcbis 4.7, and those values are used > here. If there are definitions elsewhere, there needs to be a reference. > It is not immediately obvious to me how we can put all the gritty > details in the prose, after all, it is the XSD that defines the format > for the reports. I think that you do need prose. It will be a longer document (much!) but then it will be comprehensible. Some structures will be as simple as "the following fields are child elements of "x", following the definition in Section X of [Y]" or something like that. But then at least you will have defined the semantics. >> The title says aggregated and there is mention of counts, but the language in a >> couple of places strongly implies otherwise. > > You have the advantage of new eyes. Could you point out which sentences > you think implies no aggregation? "When validation of the message occurs" - singular Section 2.1.5 uses "the message", singular, throughout If the document was up front about how things were aggregated, this wouldn't be a problem, but without context, the impression is that there is some per-message information being presented. Each of these refer to groupings of messages that are given the same disposition, but that's just not clear. >> S2.5 says "the Mail Receiver MAY send a short report indicating that a report >> is available but could not be sent" - how? > > By email. This is for the case when the report exceeds the announced > size-restriction. Then the Mail Receiver can send a short message saying so. Say that. But then you need to define the format of that message. Or maybe you don't, but you should explain what to expect as a Domain Owner. > GZIP is enough for everyone. It might be worth noting that. > We always try to be compatible as much as possible, any incompatible > future changes to the format could be handled with an increase of the > value in the "version" element in the report, or by changing the xmlns. Again, notes to that effect are good. I suspect that you would need to supplement the rua attribute as well, or risk having the Domain Owner be unable to use the new format. (This approach is almost directly against all the best advice we use for HTTP, FWIW.) > It is helpful to have unique filenames, e.g. if the reports are stored > in a directory, before processing. Why would the filename chosen by the sender (a potentially malicious entity) be used for that? >> In the acknowledgments, this looks like a serious error: "Kvå (U+00E5)l". Are >> you using <u>? > > My name is... interesting to deal with, wrt. foreigners. Hence the From > header: "Daniel K." The name may be transliterated as "Kvaal" when the > ASCII gods are asserting their will. Don't kowtow to those gods. They are mean and selfish, which you do not need to respect. Use Unicode. The format supports a simple "Kvål" now, so use that. (I also hear that email is tolerant of Unicode as well, so the systemic abuse need not continue.) -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
