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

Douglas Foster <dougfoster.emailstandards@gmail.com> Fri, 22 January 2021 15:40 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D173A131F for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 07:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeoY0pChL8JM for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 07:40:55 -0800 (PST)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122D23A131B for <dmarc@ietf.org>; Fri, 22 Jan 2021 07:40:54 -0800 (PST)
Received: by mail-ua1-x930.google.com with SMTP id u27so1933237uaa.13 for <dmarc@ietf.org>; Fri, 22 Jan 2021 07:40:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WIvXZC5LpVMnfCmozERJj8NJ54jXDn/Sku1hhSlLfws=; b=gQPek2qqPAOE4lHkxblvE32AamBCRt5t2I6r9bYEWLG/Nr968eeE7lgzfroNlTpZ8R mLv2GR9KBE6MJnyz9Coe3P8Ce4QS0KJNF4qduhwtTou4s2D6X2h9FVMpUTORUKluptuQ 2/xJqM1u2nDW5s1620SQsKsCThGTtVJDqu0NeJgp6GwGNaGz8hTzNKpNkyZCLxNcMrqL DxdcdpPMmYMmOWDSOSVZ1qVhEepqmEnkRjqglNJNKpXLS/w9K3lDnEIoD7MPC0+okpVc ljgEw2VJA844qmOk5Lwp+X8MCzLW4Tg5c9skFNJWoX3ZT5r9oqF2Tp80d6jWdaaJbuMK pUxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WIvXZC5LpVMnfCmozERJj8NJ54jXDn/Sku1hhSlLfws=; b=dM7gAYaAFxycbqnKSGSgjgIosPcZ2075OGv6yjdBLlqVqTiyeRBixPeMxFcp67Z1Wu p/hNp9H7XgnoGSLb4Tp/Y9M1EYaMMnSEdt2YCTtuMLMR3WA/iOjuovoms/8PxI4wlESl Ua2oXmiVXg8/fFIFaVCnqRJirzO2ReDwpzM3lICG9PnXUJ/leJPyrXH6QVWPARPwWlnx 2cktCcpikfvZGjXKqKLPeyfu4jwhwK07cf+DMfbDImudaAafO6srrcz/BhmfzRDz2r/5 UYtgDcg+1qOJ2dTeVtSEk2dKNfErx7Tfxw0I5c1X+faRnJZU0iWMezOSk7iTH3k5fjMd PE+g==
X-Gm-Message-State: AOAM532yNQBi1ONcTmfNcoe3ygkfrbx9pGMhJp4/Rein9mCWsr7mNC5Z tL8iiQ8vri/d1+ED1uSz6n2mrwz1q3AstHTWzeY=
X-Google-Smtp-Source: ABdhPJx24YWmJQIt3OmbbmZzZzP5yaQdc/pMT8o6ToL+zlYyaL3SPMRDpAkNXBujSRcO6RB7jrWPnAXsDN5CickoCO4=
X-Received: by 2002:ab0:3043:: with SMTP id x3mr366826ual.88.1611330053812; Fri, 22 Jan 2021 07:40:53 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB43515A1079F57BD6F6EE0A80F7A19@MN2PR11MB4351.namprd11.prod.outlook.com> <CAH48ZfyJDB9r5-2u2xQF_Dk+UBCz2TTD2WLkbd08NAUNwThWbA@mail.gmail.com> <CAHej_8nJ60G+OHa=5OHXABHzG4wNSNhJ3mvME6Rk=U4z_GbyjA@mail.gmail.com> <CAH48ZfxMs+M48-C0MEPBRY1fBDiuOQrnQ_BFtXbc=G+0bCJasg@mail.gmail.com> <CAHej_8nGRmzus23z9C0A58D7ZSAgNsiFO+DeQj3t=0zs6nx=_Q@mail.gmail.com> <CAH48ZfxUAhfdTmPLU1Titj3M3BBtMQ5C3C7bnQv3c4vN1Hadcw@mail.gmail.com> <CAOZAAfMZ3wBQ9sp_8an0dUPPLtAPH6=fo4ZWDzQm=xvk80sjyw@mail.gmail.com>
In-Reply-To: <CAOZAAfMZ3wBQ9sp_8an0dUPPLtAPH6=fo4ZWDzQm=xvk80sjyw@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Fri, 22 Jan 2021 10:40:35 -0500
Message-ID: <CAH48ZfzMG4zBBS55K7OODjaf+D0ZMy41kFnknJxrWjRfU6DtcA@mail.gmail.com>
To: Seth Blank <seth@valimail.com>
Cc: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007938c505b97f0376"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MZ4N_JcM-3m_CP-WvNNcrfDe2Ak>
Subject: Re: [dmarc-ietf] Reports helping spammers? (#81)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2021 15:40:57 -0000

Ok

On Fri, Jan 22, 2021, 10:31 AM Seth Blank <seth@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.emailstandards@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.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
>>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
>
> --
>
> *Seth Blank* | VP, Standards and New Technologies
> *e:* seth@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.
>