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
- [dmarc-ietf] Revisiting the Race Condition in dra… Todd Herr
- Re: [dmarc-ietf] Revisiting the Race Condition in… John Levine
- Re: [dmarc-ietf] Revisiting the Race Condition in… Dave Crocker
- Re: [dmarc-ietf] Revisiting the Race Condition in… Dotzero
- Re: [dmarc-ietf] Revisiting the Race Condition in… John Levine
- Re: [dmarc-ietf] Revisiting the Race Condition in… Alessandro Vesely
- Re: [dmarc-ietf] Revisiting the Race Condition in… Dotzero
- Re: [dmarc-ietf] Revisiting the Race Condition in… John R Levine
- Re: [dmarc-ietf] Revisiting the Race Condition in… Dotzero
- Re: [dmarc-ietf] Revisiting the Race Condition in… John R Levine
- Re: [dmarc-ietf] Revisiting the Race Condition in… Dotzero
- Re: [dmarc-ietf] Revisiting the Race Condition in… Murray S. Kucherawy
- Re: [dmarc-ietf] Revisiting the Race Condition in… John R Levine
- Re: [dmarc-ietf] Revisiting the Race Condition in… Kurt Andersen (b)
- Re: [dmarc-ietf] Revisiting the Race Condition in… Joseph Brennan
- Re: [dmarc-ietf] Revisiting the Race Condition in… Douglas E. Foster
- Re: [dmarc-ietf] Revisiting the Race Condition in… Alessandro Vesely