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

Todd Herr <todd.herr@valimail.com> Fri, 22 January 2021 14:15 UTC

Return-Path: <todd.herr@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 0012C3A12E7 for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 06:15:49 -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 VARLL26iPTCb for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 06:15:47 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 A7EB33A12ED for <dmarc@ietf.org>; Fri, 22 Jan 2021 06:15:47 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id z22so4138640qto.7 for <dmarc@ietf.org>; Fri, 22 Jan 2021 06:15:47 -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; bh=6sa2zTUMdrTujsalFhaoRW1+uQOaFiKjwyRNMOVZGc0=; b=WtM/unnYavts7S2K6HbubLwPYyWZtqAaCMOjYhqU5A9PVqvH5i8th8uJoX42nx+D7o eMAZsseO9kEZFsp9HwKFXaF62m7B3U8qtR/IdJTSgWy/WO2shIHrCJIUGBOuku2KXTQb vOR0HiiWOtJlVkGUPgm5f+HEwQ12IB8lVNSgqBg6pFEa3MGKf2SR6zzayS4rLTw7Zuu/ 6OX5+F8xvTrcEQXveow5bt2jdEjQUZrpsEsMvuwtHsA6rznMk+5+4ixO/XpvR5ogS2Uw +hLQgq4C1wnTPrRScS790qUlP8rIXgC279qNT+8O4vN/hER7MgLpMf5Dl3uPrJ4/Ltid R95w==
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; bh=6sa2zTUMdrTujsalFhaoRW1+uQOaFiKjwyRNMOVZGc0=; b=a+ZR/1vxVu4g5i43q8MerOEVXpHofDGV3b5Q9HClAIyKxmiJXbJKyQfLfr18kpmxYo fJ+mgKF7roy8KcuLAxa03QlnotrQ0B4ARclqUmyrigeFVUJcYXjauTmlNnchj7DMvUg3 eH/RquEYrjyssoFUdRuic15MdcM37xize53+aoG9ARTj/5zNCgASEdfm3qeLoPb4E5xu Gc4dLI3DOdySvk73H5BzKxBt6I4jKhdsgL6+t2ytmfuQTjWHAl9zucGFORecr/RLvRGc zH8s7xtuCej3brpGkJP1CQwTYy1gZbshVH3Ldz+4JuI9jOXL3KxU/1uPGh7choyAoY5Y 1SLw==
X-Gm-Message-State: AOAM531GoPAj1GXH2iv4oXTGPOAt/Vib6UdKQZTDXbJ6n9u6hiO7gyjU i17SmhdrYob4WNGWd3JOBtcO4lO/ep4JcZDIsCKgvCpE5jzj4w==
X-Google-Smtp-Source: ABdhPJzuo1KFRgmjcaB0W6JCmDe/W6IO/04dmLt8/AYC0Uxc/IpLLr+s2ACHOsN3ufrS4vpMgtmyN9ZqGyqVhlfszho=
X-Received: by 2002:ac8:6b44:: with SMTP id x4mr4467877qts.224.1611324945718; Fri, 22 Jan 2021 06:15:45 -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>
In-Reply-To: <CAH48ZfxMs+M48-C0MEPBRY1fBDiuOQrnQ_BFtXbc=G+0bCJasg@mail.gmail.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Fri, 22 Jan 2021 09:15:29 -0500
Message-ID: <CAHej_8nGRmzus23z9C0A58D7ZSAgNsiFO+DeQj3t=0zs6nx=_Q@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000001f6b805b97dd332"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/v0CBCArlVBFXuwtzqGTxXzo5qZY>
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 14:15:50 -0000

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.