Douglas, what I'm hearing in this thread is that the information in a DMARC report is well understood, and mailbox receivers are especially sensitive to information leakages to spammers who could abuse that, and after seven years of operational experience, are telling you such leakage does not occur from DMARC aggregate reports.
I'm not opposed to saying such a thing in the considerations if there's group consensus to do so, but let's wrap this thread and move on to others tickets now, please. Seth, as Chair On Fri, Jan 22, 2021 at 7:19 AM Douglas Foster < [email protected]> wrote: > Your second point seems to address my question, asserting that the value > of information sharing exceeds the risk. This is debatable, so I think it > should be documented in security considerations and reacting options should > be articulated. > > The first point still escapes me. If we are providing information about > all messages received, and are providing disposition information about all > those messages, then it includes information about messages that were > acceptably authorized. Sender policy is irrelevant. All that matters is > which messages are reported with disposition results. > > On Fri, Jan 22, 2021, 9:16 AM Todd Herr <todd.herr= > [email protected]> wrote: > >> On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster < >> [email protected]> wrote: >> >>> Not sure what is unclear about my concern. >>> >>> The spec provides for reporting whether the actual disposition was >>> different from the sender policy request, and the reason that this was done. >>> >>> >> "DMARC=(Pass), Disposition = (20 delivered, 100 rejected) -- possibly >> means that my system needs 20 messages to learn how to identify bad content" >> >> >> As I said, the above is not an example of the 'actual disposition being >> different from the sender policy request', because the sender policy >> request does not cover the scenario where DMARC passed. It only applies to >> those cases where DMARC fails. There is no facility for a domain owner to >> use DMARC to request message treatment when the DMARC validation result is >> 'pass', nor should a domain owner assume that a message that passes DMARC >> checks will be accepted solely based on that information. >> >> >> >>> Ale suggests that "disposition" must be narrowly defined to mean only >>> the disposition based on DMARC staus. This still means that local policy >>> is revealed under some circumstances. >>> >>> I do not see why local policy should be revealed at all. >>> >> >> Consider the opposite case, one where a hypothetical financial >> institution publishes a policy of p=reject and receives aggregate reports >> showing mail that it did not originate failing DMARC but not being >> rejected. That is information that might prompt a conversation between the >> financial institution and the DMARC validator, in an effort to ensure that >> its mutual customers aren't exposed to possible abuse vectors. >> >> Yes, that would still be communicated in your scenario of highly trusted >> correspondent domains, but I don't believe that the work necessary to >> curate such a list provides enough ROI for the report generator to override >> whatever minimal risk there might be in revealing its DMARC handling >> policies to miscreants. DMARC aggregate reports are not the only source of >> such information for the miscreant; the bad guys already have accounts at >> their target mailbox providers, and they're sending mail to those accounts >> and learning what happens from those accounts and from their own bounce >> logs. >> >> -- >> >> *Todd Herr* | Sr. Technical Program Manager >> *e:* [email protected] >> *p:* 703.220.4153 >> >> >> This email and all data transmitted with it contains confidential and/or >> proprietary information intended solely for the use of individual(s) >> authorized to receive it. If you are not an intended and authorized >> recipient you are hereby notified of any use, disclosure, copying or >> distribution of the information included in this transmission is prohibited >> and may be unlawful. Please immediately notify the sender by replying to >> this email and then delete it from your system. >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* [email protected] *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
