Re: [dmarc-ietf] Reports helping spammers? (#81)

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.com@dmarc.ietf.org> wrote:

> On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster <
> dougfoster.emailstandards@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.herr@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
>