Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 02 August 2019 19:58 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 DF01D1200E9 for <dmarc@ietfa.amsl.com>; Fri, 2 Aug 2019 12:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 sfahIhM0njDB for <dmarc@ietfa.amsl.com>; Fri, 2 Aug 2019 12:58:45 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 9B1AA1200E5 for <dmarc@ietf.org>; Fri, 2 Aug 2019 12:58:44 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id p17so73953126ljg.1 for <dmarc@ietf.org>; Fri, 02 Aug 2019 12:58:44 -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=TEDbwlSZzLxK26R3DqYYFmgpFhsFEJNVwiIZB7k6EOI=; b=YxZBBtfo4L80GXe3bk3TWWsWTBXGR0Sa1cDA7YlW+FqUO7PCu+ZnQHSFalqhoMO3eg /MTVopzMIVxaHJ+ICUBHi2MZDiP+SLk6MpBg+OPlVb1K4AcDPRyu2A8TghxdVrZXZHIv Di0kXYtZTH0cWnpWd7Bi/orWcNZ3YfkG6XvHHxIO8N1RgSpB6T/HUpkOILXppRVc1h7c uWLgfuI7wD4DiPkZnfIWFuRbvwe7CKGqXxt0B4nxxX5TxN9yYv0is6T5X0KDRg1emrdA fgw1UPIU5bg7r5mt+4UeNtVBfgW+X/pNqcG8qEyINgml/MMSdr/SUrybWhNJ8fb5vYwo wjnw==
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=TEDbwlSZzLxK26R3DqYYFmgpFhsFEJNVwiIZB7k6EOI=; b=dJT5cOOPHGhSDttyRSfQWKARXlqEuKYI0EEJhgZsoQHLDAUmRsrBszRwZocmIUPTl4 HI2GQUAxJp0Ty5O2dP3K1UMcfXqYwpIa6S4atR34slKxrP447rj4cWoojLaXwxwQ9YGB 6SBcGJdBIugS67g2Myi2Ba6VvxT47nT5uTIHHLPa5NvlmFN9ce4ci6jS720quANrUDO9 y+x9XRoiedASp2OI20VZTwMtR8F9hxRuY6aw0NCAhziqYPpeVD8OZL6tyf7NyX9l/yzv zAE4oDTKIaQGiV5lsOXEJQIOYO7EEf7RWT4T24CVUoNx2cZdDzXkKIQEwgqy3xONhVnJ aOaA==
X-Gm-Message-State: APjAAAW1nvXks5i7erHFC7CvfjrZPrLlKQ8IYI1IqFxSdVtvQpApKy6i wmEQcUHTeSaSpf/0PAzez56H8v0RxdAHZfVBRy0aBTbm
X-Google-Smtp-Source: APXvYqyC2lRv/71+yKhbcJFT9N41sgjH5it5QBbMqHmlVsiRLZtR+0zrGsKeXC3Kp2y3AwGcIeApfF2biyz2upd7ZI8=
X-Received: by 2002:a2e:9a19:: with SMTP id o25mr72862611lji.63.1564775922650; Fri, 02 Aug 2019 12:58:42 -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> <CAL0qLwb5FAaYZ7AX_H=aeUFkv8cvY+xd1bQ5uCDp4tmrbx2CQg@mail.gmail.com> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> <C1E711A8-F3A6-4A20-B71D-53FA773A61D9@kitterman.com> <aca25d30-3b01-4eaf-6d0b-3bae6f3f796b@tana.it>
In-Reply-To: <aca25d30-3b01-4eaf-6d0b-3bae6f3f796b@tana.it>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Fri, 2 Aug 2019 12:58:30 -0700
Message-ID: <CAL0qLwaY=YPskxLwZXkm9Gj4yvYEdJTMBSECOxvg6B4+Xb4EJA@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000005daba058f27c916"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/mCbI9oPe4icdkCGplfEd-4bpl3U>
Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: 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: Fri, 02 Aug 2019 19:58:47 -0000

On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <vesely@tana.it> wrote:

> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
> does not contain the term "policy".
>

Wow.  I'm amazed I got away with that.

But it is clear from the things in the registry that that's how you do it.

My recollection is that reporting the
> client IP is immaterial, as for SPF.  The term policy.iprev is certainly
> misleading, since the value is not related to a locally-defined policy,
> and is
> not a reversed ip.  To stick with A-R semantics, it should have been named
> tcp.ip, remote.ip or some such.  If a property warrants deprecation, it's
> policy.iprev.
>

The choice of "policy" for "iprev" is rooted in history, because the
earlier versions of the document (as you well know) demanded that the
things being reported had something to do with the message itself.  "iprev"
was an exception the community chose to allow.  It pre-dated RFC5782 which
introduced DNSxLs formally.

For guidance here, I would rely on anecdotes of implementation.  Has anyone
implemented something that attaches "iprev" results?

Now for dnswl.  Knowing which zone was queried is substantial in order to
> interpret policy.ip, because there is no standard format.  Yet, an
> implementation could just throw a DNS query to a given local IP, instead
> of a
> FQDN to the default DNS server.  In that case, one would have, for example:
>
>    dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2
>
> In that case one can hardly tell which is which.  A meaningful ptype helps.
>

Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"?
I would expect it to have that knowledge, not downstream things.  Again, I
don't know what the value of "dnswl=pass" is if the thing attaching it
doesn't even know how to interpret the result it got.

-MSK