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

Seth Blank <seth@valimail.com> Fri, 22 January 2021 15:31 UTC

Return-Path: <seth@valimail.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 6E3373A1315 for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 07:31:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 bapjwMdk2Daz for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 07:31:31 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 04C8A3A0F22 for <dmarc@ietf.org>; Fri, 22 Jan 2021 07:31:30 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id j138so2859054vsd.8 for <dmarc@ietf.org>; Fri, 22 Jan 2021 07:31:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oL5m1BvPtXO1q0sDqqdCDUV7t7x5Ca5xGoZl3LXxrOE=; b=Kzy8+vFrJnlLYqHQsRUIr0niuuYcOTNtv1HiofZ6DmWU0FapQr44jvpDXXi3M4L2Th JfmD0ROxplU3KN6EaiQAa4ye/yIqToYo1wGQhFwJ6MGpwhpJQcC2tkzZ1CjusVcBkv10 9bfylhk/87wud2KnrvFog0voWvDqoR7z9Yc4q+fDS/XiTgVTpBfCsYJMtTekkrzLoiQY U1Db147jkUOJ7kQo1dh+FutvIng5fg6zdcI0YH0eIeK75ZPReXOiG/oxvu8KPciaTVz9 Fp/YOOIh+nzSriapzO8T39X1MEZm+vWcskFu3Zr52cxu5sKl7QoHfWov5oNo4xjmSd5I NWog==
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=oL5m1BvPtXO1q0sDqqdCDUV7t7x5Ca5xGoZl3LXxrOE=; b=bCJt4Zqok8htvzAAEyC2gJ2y6SDSOgIN2VEYfxJVvLqHhwn3yyYPWQuRvB4Qo2JzHD jHeRwFbLuQR4G31ZbER6vPrMjtXzVGQhSUkyUD8puRrp43K1GuwO4JSNXKVOiz4N6E9V nPxc9IWx09Dx4auk0+EpCyG5hxA1naWaKVWZaBSb618CFsCmjLU+ojMSNQUTxvRncMsd 6bZWUkAmkko2AximRMAyz+P7tyTCBvWgOQR6lKiiUWqfLWzHTwnaWQnSWKB+V0Rl5IOV HFLUAxcuQ3R6LnKXHf4qTAM9fLkHYFwGSp8B4ahh0xo6FAW6ZjWjSOlO9Q5YtZ+8vN/H eixQ==
X-Gm-Message-State: AOAM532NQD3j2tyjhCgboo07bFhidqz7IaCIYsEYR8B9CDLH+/wFpxPU /qE+4Nk0lMWjBCxUHgigF+i9pIEdhCiGd9lRgf4XHQ==
X-Google-Smtp-Source: ABdhPJy/Hj3oVHCRpgISEQnF5aK9y9rySqg8WerHcRmdWODjJQaQEN4tZDtYuOfzNty0av5zB17wcSlupRdre5efNE8=
X-Received: by 2002:a67:fd5a:: with SMTP id g26mr3632955vsr.35.1611329489717; Fri, 22 Jan 2021 07:31:29 -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>
In-Reply-To: <CAH48ZfxUAhfdTmPLU1Titj3M3BBtMQ5C3C7bnQv3c4vN1Hadcw@mail.gmail.com>
From: Seth Blank <seth@valimail.com>
Date: Fri, 22 Jan 2021 07:31:18 -0800
Message-ID: <CAOZAAfMZ3wBQ9sp_8an0dUPPLtAPH6=fo4ZWDzQm=xvk80sjyw@mail.gmail.com>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
Cc: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d9dd5e05b97ee18b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Yq9jnn4mZZA9W6gajiNQRkcCT08>
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:31:33 -0000

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.