Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

Dotzero <dotzero@gmail.com> Wed, 19 August 2020 10:30 UTC

Return-Path: <dotzero@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 C206E3A174E for <dmarc@ietfa.amsl.com>; Wed, 19 Aug 2020 03:30:23 -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 Qxx3rtT-LCsB for <dmarc@ietfa.amsl.com>; Wed, 19 Aug 2020 03:30:19 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 754FB3A0846 for <dmarc@ietf.org>; Wed, 19 Aug 2020 03:30:19 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id h21so17337357qtp.11 for <dmarc@ietf.org>; Wed, 19 Aug 2020 03:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1Eq5ZzO7125doyckTsgSQ10C/T07NjSn+Cx6MS2Verg=; b=PH/NXrad42/KtTAB6jCEmpHiC6Ay/Oevd/zqghIv2A46Ey5CnN8Iiz42d82kk9BdBH 1bOa9u2zhT7hRsKdVw2hfhxqyJVVnsl6IbaMb6QMv/SFZuT0nTuMkGJHAY9UQOTORkJY 44Ich6nH2rcBh8Xyi24ia5e0bM3ODwCYDMJLKUE5rtFZqEFcqz111N6Fk8tZH4BSqASG ELqHsL0HeWpSrSqM09wtj+QOURU2F3OS5Yh5JSwLyNQ5uXr0xNqxU/kuyX/2m0OplIlH gM22p9FqL50dDq98FUdulPeAapaWiAvz+v9tza11eBLQwrylUa4cgm+Qvdv5gDiJqcuz zWHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1Eq5ZzO7125doyckTsgSQ10C/T07NjSn+Cx6MS2Verg=; b=por10nbkzmWEEehI3I62nO8H/c5Mn/ZUlqppNuZVg6hf5BMPr8zDcJUlLKDp6BhQZu QW1CR+baftTjX846+wqyE063paVp3S3qnphQOQW3LkiVaJElc4a2SPDMRwqys86O7+Ue phCabhxkIl16ZhjOXB+Kv8NkFX5kmB0hu/fK2VX0GQz/9joMAQQ8MRGACtWQtJJ/4Yy1 7S9lhhc9GIqmKGCf6yP7CXX0IHFKmYeliHtdKmbLg4nIGBgLyFI5m3BK3PMkXWl36udC 2kgL4vzKjm5j1O/uXbCFwyn0J9h+Wnjg9BczhW5LDJVVdOvjp8vHtCwxXYQkMkohNSlo pr4g==
X-Gm-Message-State: AOAM531VMOIQdYll3GxVopl7E20MmoeRBXRgavVdVci5yOLb3BSbpUXs x9MERIhnNHJjHCkkzBhdb+0MYD+X2o3Kgesib/lW0Qv+rKE=
X-Google-Smtp-Source: ABdhPJyQw5wYc24W8GErc/XggGHZNlgQEMWIiEHhFOBg6xOSiG/4eaxBIna0VYjZu3jCZCLlN9GWDLNIrVfF92fKtCQ=
X-Received: by 2002:ac8:660f:: with SMTP id c15mr22315145qtp.34.1597833018455; Wed, 19 Aug 2020 03:30:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:fcd0:0:0:0:0:0 with HTTP; Wed, 19 Aug 2020 03:30:17 -0700 (PDT)
In-Reply-To: <20200819004724.16EE11EED520@ary.local>
References: <CAJ4XoYcue16VU6otKOzQBFy_59nD8DGcDQb8H=Z0MsX-XLah8w@mail.gmail.com> <20200819004724.16EE11EED520@ary.local>
From: Dotzero <dotzero@gmail.com>
Date: Wed, 19 Aug 2020 06:30:17 -0400
Message-ID: <CAJ4XoYfFKe1yKK5OBx91qJOxZNHSNptu7kHS_bKnyGo_wGLB_w@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000079b96905ad387db2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PTVmKKMYRoxueDIZke-59IUbVjM>
Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01
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: Wed, 19 Aug 2020 10:30:24 -0000

On Tuesday, August 18, 2020, John Levine <johnl@taugh.com> wrote:

> In article <CAJ4XoYcue16VU6otKOzQBFy_59nD8DGcDQb8H=Z0MsX-XLah8w@
> mail.gmail.com> you write:
> >This is just wrong. While I appreciate the enthusiasm for using the Sender
> >field, unless there is a mechanism for establishing a relationship between
> >the From domain and the Sender domain then we have basically broken DMARC.
> >Using what has been described above, any malicious actor can bypass the
> >wishes of the From domain and send whatever they want.
>
> Aw, come on.  Surely you of all people know that DMARC aligned doesn't mean
> it's not spam.
>
>
Aw, come on. Surely you of all people know that DMARC broken doesn't mean
it's good and real. 🤔 You are presenting a false dichotomy that centers
only on mailing lists.


> the whole reason we're here is that we have abundant evidence that at
> least where mailing lists are involved, the policy published in DMARC
> often doesn't express the actual wishes of the domain publishing it.


You paint with a broad brush. As one of the creators of DMARC, I fully
intended that ANY messages purporting to be from the domains I set p=reject
for to be rejected if they failed to pass either aligned DKIM or SPF. No
user accounts at those domains other than direct support accounts and
billions of emails served with no intermediary problems other than a few
vanity domains on the receiver side. Our position from the beginning was
that they are not authorized by us to use our domains in that manner. For
us,protecting end users,most who were not even our customers was much more
important than the small fraction of a percentage of dropped mail. And yes,
we tracked all sorts of metrics on an ongoing basis.

Please don't tell me that our published policy did not represent our actual
wishes. Your representation that you know better than ALL people/domains
which publish DMARC what they wish is akin to saying you know better than
all people screwing up their DNS records what they actually want. You
sidestep a lot of important issues by reducing everything to the one edge
case you are concerned about.

If the people you claim don't want the outcome they have as a result of the
DMARC policy that they published then maybe they should publish a different
policy. Have you considered contracting them, any of them, to tell them you
know their wishes better than they do?

Michael Hammer