Re: [dmarc-ietf] New authentication method, DNSWL
"Murray S. Kucherawy" <superuser@gmail.com> Thu, 01 August 2019 05:27 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 01B9A120026 for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 22:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9Kt1c1ipw4OQ for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 22:27:27 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 6711412000F for <dmarc@ietf.org>; Wed, 31 Jul 2019 22:27:27 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id i21so68042389ljj.3 for <dmarc@ietf.org>; Wed, 31 Jul 2019 22:27:27 -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=NJI3DgqvOmPoMeAUTmMSHqKBui0sCh3MtDixQwOuP1o=; b=BRYfO4ZuqUKnaUtcH2w5x3mqEG6IC2oRjrMNRppzBmpXaiWyYhmkPuTWToMnzBLaZe CuCg/cCbpvJOWspJHYfeB3PR9b+iQBV+zLHK9qxcOB/54oqfjOV6h70soLxk3Uf0pWzl f2+DCZuiuqkfYVL46N/neT9TAKCHw9WjscK/NOjw/eTRfrKm4oLbuJVKG28B7KqMKus9 CcWiyziWdF0F66ledVpoKwGt5K0wQQD2ftt4PkttDCdmD6GUhwyqq++FkdwG9gGHo01R r+FHs/8d9u5/ds0wD4K023Ke6WOLy2hhmOEpxjQCqSacBzQyWrOoetIMXcFWXxtvzb++ 1ZmQ==
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=NJI3DgqvOmPoMeAUTmMSHqKBui0sCh3MtDixQwOuP1o=; b=qlibXeZWdA/oObHefXHj2leYhIzp8qcfE6y9MlqUxILNXUZSRm9shod7yprV54AuxX B19Qi4ck8hvpCNJigQUCxluCQvHpv9xNoJc1MghQHwBhGFXJcFFfsn2Ns3VZfgZ4mZGG TGvpbRQu9WbgCL64PhURIftwfYYSYftDn7n/rhEJdPwpXgae1nZo9pMmM83QJTp9Ng98 sM2l29187iXga68k2daMEzDyYNpIgmQ/FXTDrVfXEMkkwyeHhK+IJ8rrUBvllP5zjvWR eVDmveZuz7wLlOoFga8FEyHphrEGqTiHl8QdSc8w3PrNU0wIaQnqS1uoGHQep6rP9Gw6 E5xA==
X-Gm-Message-State: APjAAAWmwYIwn9mKnLM36l7N2/fiIH75BsGCG8mO4/hsJ6DV1hakndsZ uH7LwZs3pJG+STBvk4JEqQx9/VPU+qikYfMhZBg=
X-Google-Smtp-Source: APXvYqyKPgo5oJRiddwJyt/IkBQJZFJ+ySL6FsRwklzZ16K0v8Tg8ewpYjlQ/2V0hnPMOnlyzrTjHrJUHTswVDnUL08=
X-Received: by 2002:a2e:870f:: with SMTP id m15mr66737820lji.223.1564637245586; Wed, 31 Jul 2019 22:27:25 -0700 (PDT)
MIME-Version: 1.0
References: <e580ada3-d9b5-0e5b-9ac3-eade41ac92d2@tana.it> <CAL0qLwa5yR5dVzkDSD48MDgpUa11+ri=KOwrNSqOxi8fB2i6PA@mail.gmail.com> <eabefc6b-7542-1a46-4272-b786433ed0b5@tana.it> <4783309.BXR8ZdE9c3@l5580>
In-Reply-To: <4783309.BXR8ZdE9c3@l5580>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 31 Jul 2019 22:27:10 -0700
Message-ID: <CAL0qLwb5FAaYZ7AX_H=aeUFkv8cvY+xd1bQ5uCDp4tmrbx2CQg@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000039c0a2058f077fc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/UmyJ40_Yx-KNvYxlMvlHM9jvYUY>
Subject: Re: [dmarc-ietf] New authentication method, DNSWL
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, 01 Aug 2019 05:27:31 -0000
On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman <sklist@kitterman.com> wrote: > Can we discuss this choice? I know this has been implemented already, so > I'm > at least slightly reluctant to do the semi-standard lets rename existing > stuff > dance that the IETF often does, but I really don't like this. There isn't > an > email authentication system out there that doesn't rely on DNS. I think > DNS > as a ptype is way too broad. > > Also, if I rsync a copy of the list and process it locally, is it still OK > to > use the dns ptype when there is no DNS involved? > > What about something like extpolicy: The property reported relates to an > external policy input? > > Would you be willing to do something like that? If so, I think we could > also > register dns, but with status of decprecated since it's in use and > documenting > in use stuff is good. Then Courier can change at some point when it's > convenient, but still be using a registered paramet. > <designated expert hat on> Thanks for commenting on this. I'm overdue to provide a review and feedback. I rejected this application prior to RFC8601 primarily because the language used then to restrict what goes in the registry didn't allow for registrations of stuff that wasn't actually part of the message, and a DNS whitelist or blacklist result is not (nor for example is the client IP address, or the result of any query entirely external to the message body, header, or even envelope). The good news is that the language of RFC8601 is more relaxed, in particular in Section 2.3 it allows for a property/ptype that covers "some other aspect of the message's handling", so that's no longer a blocking factor. To counter Scott's point, "dns" is a ptype that would exist within the method of "dnswl", so I think it's hard to see how it could be misinterpreted. But I'd like to see how this discussion plays out. I can see his point about "dns" being a rather broad ptype. Appendix C of RFC8601 goes to some length to discourage the practice of including all the details that were inputs to the evaluation, specifically because the result of the evaluation at the border MTA is the only thing that should matter. I thus have some trouble understanding why "policy.ip" and "policy.txt" are desirable things to include. And even if that were not true, I'm concerned that "policy.ip" could be interpreted as an IP address even though that's manifestly not what this is. Nevertheless, Scott's point about documenting current use is well taken and I like his idea in principle. The only concern I have is that allowing this directly into a "deprecated" status still reserves the name "dns" should anyone later devise a use for it that's appropriate in breadth. I suspect though we could just ask IANA to register both, one deprecated and one current, should that somehow ever come to pass. Alessandro, others: Comments? -MSK
- [dmarc-ietf] New authentication method, DNSWL Alessandro Vesely
- Re: [dmarc-ietf] New authentication method, DNSWL Murray S. Kucherawy
- Re: [dmarc-ietf] New authentication method, DNSWL Alessandro Vesely
- Re: [dmarc-ietf] New authentication method, DNSWL Scott Kitterman
- Re: [dmarc-ietf] New authentication method, DNSWL Murray S. Kucherawy
- Re: [dmarc-ietf] New authentication method, DNSWL Murray S. Kucherawy
- Re: [dmarc-ietf] New authentication method, DNSWL Alessandro Vesely
- [dmarc-ietf] Do is need a new ptype? Was Re: New … Scott Kitterman
- Re: [dmarc-ietf] New authentication method, DNSWL Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] New authentication method, DNSWL Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Kurt Andersen (b)
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Jeremy Harris
- Re: [dmarc-ietf] Do we need a new ptype? Was Re: … Scott Kitterman
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Stan Kalisch
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Marc Bradshaw
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Tim Wicinski
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Jeremy Harris
- [dmarc-ietf] Call for rfc8601 erratum (smtp.remot… Alessandro Vesely
- Re: [dmarc-ietf] Call for rfc8601 erratum (smtp.r… Kurt Andersen (b)
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … John Levine
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Scott Kitterman
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Murray S. Kucherawy
- Re: [dmarc-ietf] Call for rfc8601 erratum (smtp.r… Murray S. Kucherawy
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … John R Levine
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Scott Kitterman
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely
- Re: [dmarc-ietf] Do is need a new ptype? Was Re: … Alessandro Vesely