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

"Stan Kalisch" <> Fri, 09 August 2019 02:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06BD912002F for <>; Thu, 8 Aug 2019 19:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Zt0SGPx4; dkim=pass (2048-bit key) header.b=rTL6V9ea
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qFOy7P9RJbOK for <>; Thu, 8 Aug 2019 19:04:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E04B412008A for <>; Thu, 8 Aug 2019 19:04:27 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id EF05E22091; Thu, 8 Aug 2019 22:04:26 -0400 (EDT)
Received: from imap6 ([]) by compute7.internal (MEProxy); Thu, 08 Aug 2019 22:04:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=b8tTJ4HLlimFa4ujXDoWafxCsn7Z 1Qmm2R2pSQ/eNXA=; b=Zt0SGPx4AIqmGtQU8+wdd/tY6Za1DF2qE1lmtrRE8Ajp m2QM4ka4TttujHP/qDsgtINT6FmCtiLndNVYvKNTqk/PzWmdjhUaTe2RCVFqphoi EoSdeWAKHR2bUp+wzBwo2Akk2e0uRgens0YDDa/zHMRhBDj4jLuqtiycLqDyij0k +CssUUr42e3q89iSWVFhaYtYlXmT9LIZlFrX2acUb+YIhATqQI45Scd/TWE+uqE8 zIY6zYd51+Ag09fnq17kCRKbHG9JXbY9fzbt+fc/MzOBz1Ga5qBcB/irEsdZCi6Y cseGS6HCcw7hchA9q4BYNmTRhlb4HaWaZXZx4nqZIg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=b8tTJ4 HLlimFa4ujXDoWafxCsn7Z1Qmm2R2pSQ/eNXA=; b=rTL6V9eaNd3CqgQ0DppxAh 5CyPCXjqO8w+eXxGKvb2t9oXpjqSX3fXQRFaMVqjNWx8E/pVmstFf79+/X9EKtgx jriuq28t0RTiJ5MAGhkyZaS1MY6jn4iK7Xf2DjpYy93mnaXhtsBWnIToGOsiXDS5 w2RzEmoVPLhbcfRZZYpsZWlTclEm6iI27WhjsBrgYOyHh77XHIB95wEttwAw5urk ws8EImbxVca/2N8BeVY1nKmhKIMbrAcLqFyKJh2KaFl2JOYJCs8T3ljzIT0QX6m6 +JdQqthi85rTWNDf4FbivCJZWVrBqYYY5BcGi/YwVw6bJ3LCkkmAY0gFG/F8JxwA ==
X-ME-Sender: <xms:qdRMXRbCwWFO2BHAWeRPRxBg5DR-_eAcfmJtXjyW99ZlEatP4_qCaQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduiedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuthgr nhcumfgrlhhishgthhdfuceoshhtrghnsehglhihphhhvghinhdrmhgrihhlfhhorhgtvg drnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhn rdhmrghilhhfohhrtggvrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:qdRMXaEChEc-lwYwSLWmrpigRrg5Xj1qaGQkc6GHaRyEMZYuosVvUA> <xmx:qdRMXXZ1_BSBimaKzr15jP-scieLLiqS9zGbEXuC_WQgxnj9P-x0tA> <xmx:qdRMXff8PLfcoWJ-plxO-eAsDYS_tVibgCf49lgxJPLbsyS4r9n7SQ> <xmx:qtRMXZ3XL0SHHXTfTvBgaB8bqwai_JcqMls6V2s_a22B-Il82IUr6A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BEE951400EE; Thu, 8 Aug 2019 22:04:25 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <4783309.BXR8ZdE9c3@l5580> <> <> <> <> <>
Date: Thu, 08 Aug 2019 22:04:25 -0400
From: "Stan Kalisch" <>
To: "Murray S. Kucherawy" <>, "Alessandro Vesely" <>
Content-Type: multipart/alternative; boundary=3bdef50581294b7b922ba417f524b809
Archived-At: <>
Subject: Re: [dmarc-ietf] =?utf-8?q?Do_is_need_a_new_ptype=3F_Was_Re=3A_New_a?= =?utf-8?q?uthentication_method=2C_DNSWL?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Aug 2019 02:04:30 -0000

On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote:
> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <> 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?

IIRC, Fastmail's Authentication Milter does. But I also have some vague recollection that they stopped using policy.iprev, specifically.

Now looking at headers from my Fastmail customer account, it appears to me that this is indeed what they did, although I would have to recheck the actual distribution they share with everyone else to be sure. I'm sure someone at Fastmail can comment on what actually precipitated the move.


>> 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=
>> 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.