Re: [dmarc-ietf] third party authorization, not, was non-mailing list

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 20 August 2020 18:17 UTC

Return-Path: <superuser@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 F0BEE3A1180 for <dmarc@ietfa.amsl.com>; Thu, 20 Aug 2020 11:17:10 -0700 (PDT)
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 K7G68cDJcky4 for <dmarc@ietfa.amsl.com>; Thu, 20 Aug 2020 11:17:08 -0700 (PDT)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 3F72F3A117D for <dmarc@ietf.org>; Thu, 20 Aug 2020 11:17:08 -0700 (PDT)
Received: by mail-ua1-x92b.google.com with SMTP id y17so853511uaq.6 for <dmarc@ietf.org>; Thu, 20 Aug 2020 11:17:08 -0700 (PDT)
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=udgZaB2gcQl/soxkMVghWQ+p1FDGnE+fhhFyZJN/DLg=; b=slS3w7ioEvbl4cHphHO10s0VWjacAwPp49QKmTN0W5F/L73gkjpfmoWjOGX/k1y3a/ 9xekwO4Pov6IGfMPJSuYQrW+4Z6VKTOyaQLPDbsa9wzAY8UxIeYKtwrig1oAdtqlAYzW 7oHNZdWrST+Kh8KSe83fKhUQtncppZg50fD7BvyN7/EbNDnXF8SpVaRbSHXOIp5FL/kl iKjQEMhOM/gW6AICrLAF+oFye6F27OHdo5/ypfuJz5X4+S0iiNhDrxEJ3MFL8pfPJZc4 9JgcsT3GQMArdpJNapaT8g4KckNtXdDX4/5PGjnLXWUPmh81MvCm21n7wQRw93MfWKpk pcGg==
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=udgZaB2gcQl/soxkMVghWQ+p1FDGnE+fhhFyZJN/DLg=; b=K6XEBUb3RvuN4P9CYPJyiViDYXOjev1sD73M0PDnAr6zGFd2e2FOd+CWjerjaUvDAq n463pTdv18WJnBxdgXppl+B86yGIKiv5cjSshbcEDFD0Dapc1L6kBJO+AxGx1qXMIW0g 9JaRm3wyqG7YPrvPSiIQSaBGdJqjBB2hWuXXcG4y0xwZfxx4rTBr3N3Sbs6JeaW2FNss s/Utev8DO0tIX79USSCTJT7gXUjbMlGcoK9nZX1zG0E2iMGhC+0zqWH3WHFaVWJzeDFL eQN0FNbt+oFyoXLd0WVa0YqlxiIMj0Krf46M3nhb2r1itjpccKJ7km+0IR+8DO5O6n3E IZJg==
X-Gm-Message-State: AOAM5307cvbN21ioMb/QQHg4G0xRG2XFuxTndqS/ApC3ZiLhgkvG3wvx uBcZYLf/y6vCd3/YAcR4fwOqy7CEA3N4sbp3TvQ=
X-Google-Smtp-Source: ABdhPJyU69a+jMMxyhLz0Sea0wNcMN16cd32mUsThkVvuexiyQGHZUi6xRHwBk0cElEbv4pvFARX3zEHuIpW1+ipANA=
X-Received: by 2002:a9f:26a5:: with SMTP id 34mr2807812uay.67.1597947427037; Thu, 20 Aug 2020 11:17:07 -0700 (PDT)
MIME-Version: 1.0
References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <CAL0qLwacyBbJscEM_a4-nvugO0HBaSAdPqUPkfYYOOb++cOjQQ@mail.gmail.com> <5F396A77.3000109@isdg.net> <CAL0qLwYaqsU-U8yTcr5_cw0LmEomz8JbqUXuWNJ-bnkN6ceXyA@mail.gmail.com> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <CABuGu1qdZdXBSsAwCvk4244szskz6Pf9x83kRUGd8jHDafEMGQ@mail.gmail.com> <CAL0qLwYY8ZWq4k3wobOgSJSVnabsefPRiCtcVPrb_iF1JEUZag@mail.gmail.com> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it>
In-Reply-To: <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 20 Aug 2020 11:16:55 -0700
Message-ID: <CAL0qLwb-SG-dsNkiiGtYkUz_AwsZSd6f5cKFX07Kzme5iXoZJA@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>, Tim Draegen <timd@dmarcian.com>
Content-Type: multipart/alternative; boundary="000000000000c22af605ad532035"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Jxl3qrT6GsCV9a06C_6prPeeTRY>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
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: Thu, 20 Aug 2020 18:17:11 -0000

On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely <vesely@tana.it> wrote:

> I am wondering whether companies like Dmarcian could implement third-pary
> whitelisting.  As they receive and analyze DMARC aggregate reports on
> behalf of many mail sites, they probably are able to distinguish various
> level of authentication failures, from mailing lists to misaligned ESPs, to
> actual abusers.  In that case, they could maintain a whitelist tailored for
> any given client.  The client would set, say:
>
> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
> client-id@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"
> [...]
>

Having spent a lot of time and energy building a DKIM-based reputation
system that (IMHO) showed promise, I made it available for people to try
for free.  There was no uptake, even after presenting its promising results
in places like M3AAWG.  Times may have changed, but in retrospect I think
there are too many "what-ifs" for add-ons of this nature to be seen as
feasible.  The issues seem to be:

- it has no hope of being universally accurate; participants have to accept
that false positives and false negatives will happen

- if it's perceived as effective, demand for this will skyrocket; the host
needs to be resilient to this

- participants have to trust the company providing the service to do so
reliably and honestly (e.g., no paying to be listed or get a reputation
boost)

- depending on failure modes, the host could become a DoS target; they need
to be resilient to this

- the "lag" to which you refer might be unacceptable in some situations;
participants need to be willing to tolerate this

- there will be demands for accuracy and timely responses; interfering with
someone's mail flow for whatever reason can draw unwanted legal attention
(e.g., MAPS)

I imagine large operators already have enough information to know where the
lists are, so for them this might be moot.  It's smaller operators without
the infrastructure to make such determinations in real time that need to
collaborate on something like this.

-MSK