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
