On Tue, Oct 21, 2025 at 12:50 PM Alessandro Vesely <[email protected]> wrote:
> On Tue 21/Oct/2025 00:31:43 +0200 Todd Herr wrote: > > Here are my comments on the subject document: > > > > > > Second paragraph of the Introduction contains the phrase "Sender domain". > > DMARCbis defines the term "Author Domain", which is I think what's meant > > here, and I would argue that "Sender domain" should be changed to "Domain > > Owner of the Author Domain" here. > > > "Sender domain" was in the Michael's proposed text[*]. "Domain Owner of > the > Author Domain" seems to be overly long, also because the Author is faked > in > this case (direct domain abuse). How about just "Domain Owner"? > The full sentence at issue to which my comment refers is this: "On the other hand, they can allow the Sender domain to quickly identify and address harmful messages involving direct domain abuse." I'm fine with just "Domain Owner" instead of "Sender domain". > > > I'm not quite sure that section 7.2 (Report Recipients) is even > necessary. > > One presumes that a Mail Receiver has reviewed its policies before > deciding > > to go ahead and do failure reporting (or not), and the seemingly implied > > need in section 7.2 for a Mail Receiver to do independent additional > > vetting of a Report Consumer goes against any claim of scalability > > associated with DMARC. Maybe pull a sentence or two out of it and add it > > the first paragraph of Privacy Considerations, something like: > > > > "The generation and transmission of DMARC failure reports raise > significant > > privacy concerns that must be carefully considered before deployment. > > Additionally, Mail Receivers must be aware that Report Consumers may be > > able to extract and/or infer metadata from the reports, metadata that is > > not necessarily directly associated with the failed message." > > > > I don't offer the "Additionally...." sentence here as a possible > > contribution to the text so much as I present it as a placeholder for > what > > might be pulled from section 7.2 if the authors go that route. > > > I have no particular preference in this regard. However, Section 7.2, as > it > stands, could be interpreted as a suggestion toward a policy along the > lines of > "Report entire message if the destination is not external, otherwise only > headers." The proposed replacement is not as impactful. > "Report entire message if the destination is not external" seems to assume that the Domain Owner sent or at least authorized the sending of all messages that failed authentication, and we know that's not always true. As I wrote back in https://mailarchive.ietf.org/arch/msg/dmarc/enW-Ef9U_yuOsG9uWZy2VVGLOpE/ For the following scenario: - A is the domain owner that published the DMARC policy and consumes reports - B is the entity sending email that makes unauthorized use of A's domain - C is the recipient of said email, an entity heretofore unknown to A - D is the report generator Any report generated by D that is sent to A and that contains any of C's PII creates a privacy concern for D and also by extension an exposure of that PII to A. Given this, I don't think that "Report entire message if the destination is not external" is necessarily good guidance here. Maybe just delete the first paragraph from Section 7.2 and change the section title to something that references the ability of Report Recipients to potentially harvest other data from the failure reports? The second paragraph seems to me to have specifics (traffic analysis and metadata) that the first lacks. > > > I'm confused by the Example Failure Report (Appendix A) in two respects: > > 1. There is no redaction in the example, not even of the To: address > > > Setting up a consistent redaction, as required by RFC 6590, is not > trivial. > For example, it's unclear whether the local-part of the recipient's email > address should also be obscured in general places, i.e., not in an > addr-spec. > In fact, many spam messages begin with "Dear local-part," so if you don't > obscure it there you can allow it to be inferred. OTOH, a local-part > which is > also a word in the message language can appear in a sentence in the > message > body, where it can be deduced if it's obscured. > > Without redaction, the example is much more straightforward. > Fair enough. I know redaction is difficult, but I also guess that the lawyers who might decide whether or not a Receiver will generate Failure Reports are likely to blanche at any example that would show a recipient's PII. > > > 2. There are two Authentication-Results headers in the example, one of > > which reads, in part, "auth=pass (details omitted)" and so I'm not sure > how > > this would appear in a Failure Report. > > > That is one of the four Authentication-Results fields that appear in the > message/rfc822 part of the report. It was written by the consumer.example > MSA > after authenticating the user's login. Neither forwarder.example nor > gen.example bothered to remove it, so it was reported. > > > > I wonder if perhaps a more straightforward example, one that doesn't > > attempt to show a message that passed through a mailing list as this one > > seems to but rather is just a direct point A to point B message that > > failed, might be better? > > > I adapted the example from a report I received. And I only received > mailing > lists failures. > Given the fact that authentication breaks most often (for legitimate mail, anyway) when it's forwarded/sent through a mailing list, are Mail Receivers more or less likely to send failure reports for such mail? I genuinely don't know the answer to that question, but I think it would be helpful if perhaps examples of both types of failures (one forwarded, one direct) could be shown in the document. -- Todd
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
