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

Todd Herr <todd.herr@valimail.com> Fri, 22 January 2021 13:40 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 06D953A12B0 for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 05:40:31 -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 GgMAE3c4N3PZ for <dmarc@ietfa.amsl.com>; Fri, 22 Jan 2021 05:40:28 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 A23993A12AF for <dmarc@ietf.org>; Fri, 22 Jan 2021 05:40:28 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id o18so4039362qtp.10 for <dmarc@ietf.org>; Fri, 22 Jan 2021 05:40:28 -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=b+QI96/jUrAviaaICsa0QYhYQDQmyjwMTjrv7oU4/5o=; b=bFpTUHINySgHq4jVKkI9SHtJVkcqly//Dtrf2FHQysr9JPKuCZC2f16GTomOM82izi eBxxPMtrlSsOWBNfFWLcgB1OPwsdU8oMbg8wc5A549oWjNYMgflb8BESpbJK/j/rPGlx v5uMg/6wtSpVRyVCrfQLpmvYCtcCKReaPkICMDUJE3+s/QEWfr27KIWJQUk1xxqVjpYO yW2ye5LS/10HN+HrpEQzidxMUzkiLidhzeLW45+GmbQ0aqQjfQ6Lm7DlJ/rRQkL2N4BA uD3KEbwn6/CaEiViyeIPA7IV4wsIkLdDgU6OT2Twh1IM6chY7DGhAO+5nQgFTkyUH7cp C5Ug==
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=b+QI96/jUrAviaaICsa0QYhYQDQmyjwMTjrv7oU4/5o=; b=VuoS7FniqU7zpC0073bPT1L3zTGW+pLJO82R/HaE0vQPfnuzGTQFUAkJ4tWyKN1cfm ZA9JTzZZUt5QTwlaXtUxW9jDOD0BtSuOV0fdJZvNE9hfunusHg9co9HZlri+lZgXL7gB iV+ZOTFfIxaALxWn9nuF6vMmMXFAH2y10gasKjHXL1k72nVP/75xEtFuDD+/ESv4+WOq EQLPFTNE6YhR3T+vu+onyHmTffsq74LBPsfP1js/SibFKtFdmo0yDn037hBL6DQfMEeC jnDkPzWDCphbg6p4oWe7ESzNiGQRBq32KkcRj+RT2aclvrPDl0GAj77BT31d9ONfl7v2 Idkw==
X-Gm-Message-State: AOAM532nnGD7Ah/oJ7HV7jeA5ib4/oiG/lqgUv0UGZGLpEplhW9TAR5P qlcptrphjsUBLBusvb4xrpmPUOqGnL1dWog7cMs43N10zfg=
X-Google-Smtp-Source: ABdhPJwwYJYltZJ3wBf2s1yzkonBrMuKw9Dq2+RCbsqbRS5+AiMMUl4YOLqW4gpqrUlAYYf2xu2mitNsoDxGX97ycos=
X-Received: by 2002:ac8:6b4b:: with SMTP id x11mr4263072qts.220.1611322827288; Fri, 22 Jan 2021 05:40:27 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB43515A1079F57BD6F6EE0A80F7A19@MN2PR11MB4351.namprd11.prod.outlook.com> <CAH48ZfyJDB9r5-2u2xQF_Dk+UBCz2TTD2WLkbd08NAUNwThWbA@mail.gmail.com>
In-Reply-To: <CAH48ZfyJDB9r5-2u2xQF_Dk+UBCz2TTD2WLkbd08NAUNwThWbA@mail.gmail.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Fri, 22 Jan 2021 08:40:11 -0500
Message-ID: <CAHej_8nJ60G+OHa=5OHXABHzG4wNSNhJ3mvME6Rk=U4z_GbyjA@mail.gmail.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd4b7105b97d547c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/XMPB4py-jwiTSm2pjGhpn01Lcf4>
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 13:40:31 -0000

On Fri, Jan 22, 2021 at 7:00 AM Douglas Foster <
dougfoster.emailstandards@gmail.com> 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:* 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.