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

"Marc Bradshaw" <marc@marcbradshaw.net> Fri, 09 August 2019 04:29 UTC

Return-Path: <marc@marcbradshaw.net>
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 C21621200CE for <dmarc@ietfa.amsl.com>; Thu, 8 Aug 2019 21:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=k6FBUY5s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EAdQpHDX
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 3Ikk_sGTfl8t for <dmarc@ietfa.amsl.com>; Thu, 8 Aug 2019 21:29:40 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B071200A3 for <dmarc@ietf.org>; Thu, 8 Aug 2019 21:29:40 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A98C921F2E for <dmarc@ietf.org>; Fri, 9 Aug 2019 00:29:39 -0400 (EDT)
Received: from imap38 ([10.202.2.88]) by compute2.internal (MEProxy); Fri, 09 Aug 2019 00:29:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=7ZGXUfx 1amW0zt4lZFNDePef2syKmvSKispS8zR5OyE=; b=k6FBUY5spsZ3osb9h/S5vu3 YD/9iDZne2bE6H577Kv7zbiX4fFOlhqBX4yHRU+GdIJXXaZGro27cD0lg7sPo93N d88cW1U0NMmTjKugNLoyeFUmRlwDTiMtbdGI+wblqVckumaf8/LlwyYZuaRD9dzu jqYyjmJXesBH0WbccBMSy/9mxhJskqf/jGduQDgJ4T4LNzAdwTi4vlDIfOA7A267 arEgDHfTorDAu5VtZdJpE9GpPFkz9V24c0SXTG20ZqU5DaznzbwUZJOxOYyKpS/O xR256kiw9+T58Co91qUdOKfljhXTk+tOw6vPRO5j1iOGjzKTZNnHeIFMifz4MZw= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=7ZGXUf x1amW0zt4lZFNDePef2syKmvSKispS8zR5OyE=; b=EAdQpHDXUBzKii7LrgxFV1 2VAXfzD6BpXGnKN1hm2NO4xU6ptTpGcYK7nEuRVTYE7Day2NsCoi/hzpKmq+6QIF Oq6yKHCNNUiTWHIsxKO5acqOL1rVZ4ZIwEqc2ODryxIX35+wgpIEXYlw+x3uwRhw /wMS0wgX4I0jM+w3aZnlyLvAV2YDXqPn6/oHjSaI2IgEi/neORJdg0SDcbmSnJ+f P7m1BE8+mhJ+CBIBq0tUy16/fStZl+j70QWGKuZJRd+f5k4r3Ztk1rX9+oNl+BTL iemrqDnyhIL3ow7LT7Hlo/OJRTxDtdianyFoXGj9KFVUBVL8IWBuTzPOtmHBuRQA ==
X-ME-Sender: <xms:s_ZMXeZUJn7oFcE5uGOkeH9lJaaghZH6u5nP2o4_KXCVYjz9t7PdUQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduiedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdforghr tgcuuehrrggushhhrgiffdcuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvghtqe enucffohhmrghinhepthifihhtthgvrhdrtghomhdpmhgrrhgtsghrrggushhhrgifrdhn vghtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtgesmhgrrhgtsghrrggushhhrg ifrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:s_ZMXVq_xX9sphMgDeJMQ-C0H9r96mZZOb-kzFlWCFQmS94BpgUV9w> <xmx:s_ZMXT9CwEU8X43oC0YWNBb-dvMztTyu_agqiXx-rVmmQ9-bSSCkCQ> <xmx:s_ZMXU_YczFPn22eD51juVEFC6gfEZjyIVWw6IdoA4hiQl-_c-4Geg> <xmx:s_ZMXbwe0TEdXa21ZSkuZ29DNjLyiyeY1y1xogW7pq1HAI6dNEWu1g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 250994C000A4; Fri, 9 Aug 2019 00:29:39 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2
Mime-Version: 1.0
Message-Id: <03c58290-1b4b-4dac-a7f3-d66a4be4d3a0@www.fastmail.com>
In-Reply-To: <bfeb69c0-1e40-435e-930d-2b8578c0aefc@www.fastmail.com>
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> <CAL0qLwaY=YPskxLwZXkm9Gj4yvYEdJTMBSECOxvg6B4+Xb4EJA@mail.gmail.com> <bfeb69c0-1e40-435e-930d-2b8578c0aefc@www.fastmail.com>
Date: Fri, 09 Aug 2019 14:28:50 +1000
From: "Marc Bradshaw" <marc@marcbradshaw.net>
To: "DMARC IETF" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary=3a63167ba2794788bdb5f5eedcdd46c7
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/TfSS8IiLmjfMl9m_spN58HThOr4>
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-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, 09 Aug 2019 04:29:43 -0000

On Fri, 9 Aug 2019, at 12:04 PM, Stan Kalisch wrote:
> On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote:
>> 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?
> 
> 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.

We (Fastmail) do attach IPRev results. We used policy.iprev for the remote IP up until October 2018, although it may have been slightly later when the change made it through to production. I recall the change being made as part of a larger set of changes which came out of an ARC interop working session.
Current code uses smtp.remote-ip for a few reasons, mostly as it is more correct to attach this to the IP to the smtp type, it is also more in line with what some other providers are doing. For context, we are using this when processing messages with a trusted ARC set.

--

 Marc Bradshaw
marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>