Ok On Fri, Jan 22, 2021, 10:31 AM Seth Blank <s...@valimail.com> wrote:
> 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 < > dougfoster.emailstanda...@gmail.com> 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= >> 40valimail....@dmarc.ietf.org> wrote: >> >>> On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster < >>> dougfoster.emailstanda...@gmail.com> 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:* todd.h...@valimail.com >>> *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 >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > > *Seth Blank* | VP, Standards and New Technologies > *e:* s...@valimail.com > *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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
