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

Douglas Foster <> Fri, 22 January 2021 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45EE03A0C9C for <>; Fri, 22 Jan 2021 06:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QnQF9fGF5yRK for <>; Fri, 22 Jan 2021 06:02:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E01D13A0C47 for <>; Fri, 22 Jan 2021 06:02:48 -0800 (PST)
Received: by with SMTP id o186so3052792vso.1 for <>; Fri, 22 Jan 2021 06:02:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2VQ57Q+peRBSDsExcQurgF7t7N0pxrAVpgOM0+wqN2Y=; b=JosS4NkQluyweREdNUO4zMUH24OOGc9yPMs2mY1K/qCdrWDHiTmEGaAV8U/lHJ3wsB tPHk89YMUEdQcaz1lpzXFGZ0/LbOw/sxU7cEwRX6IR4jT1fSEOPcnghCbwfEvkklPHuq NDeFsvXnIcaeLFXGqJyCHOkR8uJfkIVZTkqDL/xfkSWtvRFfRKWCyQBxrpKpz5khD5Bb b2rGSyy7jwiWO6+EBOnrB/dQ554RlzUXJDWRDanyN224DpB+DaU1GWvgYwoMz1ZTXq/K e9WuO3oGuoiZNeLOrAQlDeUbjl/WghOGSWD2nIbqK2UhCjnWOQHGwnd1+d5GipbW5Vgg czAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2VQ57Q+peRBSDsExcQurgF7t7N0pxrAVpgOM0+wqN2Y=; b=e171gAO1FwV3UqAjMzLLL2coJZDZ10HaPtXHK94zlCi5W11gGurqzmf2vd7Ycrs9FJ z9t0Mi9jwxb4isIlZEkEGceMwwOrm3tG2LGlbPl+bCzxxzdwvFnPfPgpWvqv+wNhHkP8 EKgMQ+gW+ZFazI4y712LrFFjYge5flXouddazPv6NF3FgjTEHxWSx/6uw4zcJOjNvIV5 Jv9bPh4U8mALUtTJSO2PV6y/4GY9aha6zNKa8ztoZt1ev+d2puE9d7HV5EON1dDxpNNE ab7hIlOHYSRQaj7KapqCv7P0Ba+qqgPns1IL7UgdXfg4HwOAypfvpItx+ECBmfot4gaL z6GQ==
X-Gm-Message-State: AOAM531M74ZyETS/WaGVRxlD3eH6n8sHX3mJ2RPnsnCHWLPtihwjtBFd lFrsq68fItq1WULx2jpllp8fiqhngbUkxsC/Ub4=
X-Google-Smtp-Source: ABdhPJwQvDRYzAjMcwx0iBCoa5OqUNLkLQV4Rm6zB9BHfJ6AIn70LyiK3AtG5lzigQ5Y++HfnOT6wMd6eUVjmAOtRNE=
X-Received: by 2002:a67:507:: with SMTP id 7mr761023vsf.42.1611324167688; Fri, 22 Jan 2021 06:02:47 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Fri, 22 Jan 2021 09:02:35 -0500
Message-ID: <>
To: Todd Herr <>
Content-Type: multipart/alternative; boundary="000000000000a2170305b97da455"
Archived-At: <>
Subject: Re: [dmarc-ietf] Reports helping spammers? (#81)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2021 14:02:51 -0000

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.

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.

On Fri, Jan 22, 2021, 8:41 AM Todd Herr <todd.herr=> wrote:

> On Fri, Jan 22, 2021 at 7:00 AM Douglas Foster <
>> wrote:
>> 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.
> You're using the phrase "disposition was different from the sender policy"
> in a way that I don't understand.
> Sender policy is a request for handling when a message fails DMARC
> validation checks. In your examples of possible misuse of disposition
> information, one you're citing is 100 rejected messages when DMARC passes;
> that's not a disposition that's different from sender policy, because DMARC
> pass is no guarantee of a message being accepted, and again, sender policy
> only concerns the state of DMARC failing validation checks. The DMARC
> policy statement isn't a vehicle for requesting handling when the message
> passes DMARC checks. Beyond that, I'm not even sure that a condition exists
> where a message would have a disposition of "rejected due to DMARC" when
> the DMARC validation result is pass, but I've been accused in the past of
> lacking imagination, so perhaps it could happen.
> For your example of DMARC failing and all 120 messages being delivered,
> I've never personally met a spammer (every conversation I ever had started
> with "I'm not a spammer")  but I can't conceive of a spammer configuring
> his domain with a DMARC policy of p=reject and sending mail that doesn't
> authenticate as a way of probing things, but I suppose it could happen.
> Because aggregate reports only come in once every 24 hours from most
> places, he's not going to get immediate gratification like he would simply
> by having a few test or seed accounts at the target domain, but maybe he's
> patient. Of course, DMARC isn't the sole arbiter of whether or not the
> message made it to the Inbox and not the Junk or Spam folder, so results
> would be inconclusive at best. His test accounts will tell him much more
> than DMARC reports will tell him.
> I can't speak for any mailbox providers, but I suspect that the work of
> updating their reporting tools to handle an exception list and curating
> such a list is more expensive to them than whatever risk might exist in
> generating a DMARC aggregate report for a few spam sending domains. Maybe a
> note in Security Considerations or something? *shrug*
> --
> *Todd Herr* | Sr. Technical Program Manager
> *e:*
> *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