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

Douglas Foster <dougfoster.emailstandards@gmail.com> Fri, 22 January 2021 12:00 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 3B28D3A114D for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 04:00:44 -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=ham 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 Speg0zl3YOPm for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 04:00:42 -0800 (PST)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 3197C3A1145 for <dmarc@ietf.org>; Fri, 22 Jan 2021 04:00:42 -0800 (PST)
Received: by mail-ua1-x932.google.com with SMTP id t15so1735355ual.6 for <dmarc@ietf.org>; Fri, 22 Jan 2021 04:00:41 -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=eURGtIiO83gutt9qswPTlQmVXGhmk1+cIhkIsSGqHQk=; b=OR5/8bts7i9YA9fibktm57IWx3fgxtJDpGB+/GvcP4K7v6DHrpWRm6ybt/rSLuNPtH sFFpNQATF16d3uHlOAAmURgAXf4GfFcI23xdgBtVYXyUihGcT/FG6Zl0Z/B6OTYMK5A8 y/aOjqfS73MA2BIRD3nBKAoOumGPTws4gNdoHUXFU+d8+gxQKQZJfTfjTsBgq8xSwyE9 ReOPlgESkQvisqv9ggt0/baPG+s3IAGdwCC6Egaw6zr7DTA1OUaVpEQDTJnqcEVF+l5+ 7hzCI/tXRPDpWzCu/vLN+yFNSNSNr8tBOJ9mQtouRuwb497b6s5+HadcEN+ajIlecUXW fLzg==
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=eURGtIiO83gutt9qswPTlQmVXGhmk1+cIhkIsSGqHQk=; b=Fq2n5lXiboRanOfMziZNC+bOc4k/yhx+jZrkWF0ZsmhW5ewjNud16S5uuEPWdM2FfW 62+ywm6fvqSrEy7mP7rY+HlPIRRxccYRDH2wpuqMBZbCK0qxX018mw0d27uqchdTnvdv 5Zqb2P8B8uSJ3Exva2ccCkDX1cyTX5Ne7DvNPRBj8jSBhyuKWDSa6yVaHl+uByXk/OJp nI1j+vlOOmfcWZASzCLsd5TDR4IQTDa1iGlxnTyxPoPZ5TBNSLH+jDdrMlciduAgx60l xUcqL3ewHEa9+ruyEZmyCFS4x5nLcqYpW6K9XeH5RjvtsnAKW7pGMGTSpIPtVzuT4BvY tRMQ==
X-Gm-Message-State: AOAM53206MhVbv2iaLvLkED4Zd9fZBfSMmlKX3lqRZbNn+5uG0Vn+byu VI9aRm7etdWAmyCTQOQXAa2TpctF/qrpAGl4SjRVZFzeVmM=
X-Google-Smtp-Source: ABdhPJwbzLWHRrFnoaVQYE80iReAOW/gz3qb61cn0SqTK0mFCuNzP4nOu1RS+0XHdPjOzvIYZuwnNZQWBTks4qjB3O4=
X-Received: by 2002:ab0:5e6:: with SMTP id e93mr96418uae.109.1611316841001; Fri, 22 Jan 2021 04:00:41 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB43515A1079F57BD6F6EE0A80F7A19@MN2PR11MB4351.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43515A1079F57BD6F6EE0A80F7A19@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Fri, 22 Jan 2021 07:00:30 -0500
Message-ID: <CAH48ZfyJDB9r5-2u2xQF_Dk+UBCz2TTD2WLkbd08NAUNwThWbA@mail.gmail.com>
To: "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000edb96e05b97bef06"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/rSXEifCWd3yYn96WDchlsloddfY>
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 12:00:44 -0000

My specific concern is with disposition information.    Whether the message
presents with acceptable credentials is the sender's responsibility, and I
have no problem with documenting whether it passed SPF or DKIM or both,
including which DKIM scope was used for the evaluation.     I have no
problem with reporting the sender policy that I retrieved from DNS.

But should I report the disposition applied, and the reason that my
disposition was different from the sender policy?    That seems like
information leakage about my defenses which should only be revealed to
highly trusted correspondent domains.

Consider what is likely to happen If I call an organization's help desk and
say,
     "My emails to Sally are not getting delivered, and I want to know why?"
The answer should be, and usually is,
     "Have Sally open a ticket and we will discuss the problem with her!"
Should not the same policy apply here?

Possible misuse of disposition information:
- DMARC=(Fail), Disposition = (120 delivered) -- probably means that my
system does not enforce DMARC at all
- DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
means that my system needs 20 messages to learn how to identify bad content

I suggest that disposition information should be redacted by default, and
only included on an exception basis for highly trusted source domains.

Doug Foster

On Thu, Jan 21, 2021 at 4:00 PM Brotman, Alex <Alex_Brotman=
40comcast.com@dmarc.ietf.org> wrote:

> Hello folks,
>
> Thought I'd see if we could come to a conclusion on this ticket.  The gist
> is that the reporter believes that (aggregate?) reports can help spammers
> to determine some effectiveness of their message attempts.
>
> Full Text:
> -------------
> Spammers could use DMARC reports to monitor the effectiveness of their
> campaigns, and we do not want to help them. Do existing implementations
> send reports to any domain that requests them, or only to those domains
> that are considered "acceptable"? If reports are only sent to acceptable
> domains, what sort of criteria have been useful?
>
> System administrators will appreciate such advice. Product developers will
> need guidance about the features they should provide so that a system
> administrator can control which domains do not receive reports.
> -------------
>
> >From an operator side, I don't agree with this assessment.  The reports
> do not show if/why a MBP may place a message in the Junk folder.  Could it
> be DMARC quarantine?  Sure.  It could also be any number of things from a
> large matrix of decisions, none of which are shown in a DMARC report.
> Also, the reports are typically sent once per day (seems like most ignore
> the 'ri'), quite likely some time after the end of the reporting period.
> Additionally, they probably have more efficient/immediate methods of
> evaluating their success rate.
>
> If you believe something has been overlooked, please feel free to share.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>