[dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype?
Alessandro Vesely <vesely@tana.it> Mon, 11 November 2019 09:23 UTC
Return-Path: <vesely@tana.it>
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 61BDF120897 for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 01:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 vdRIWEvOqWQv for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 01:23:08 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9C91201DB for <dmarc@ietf.org>; Mon, 11 Nov 2019 01:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573464186; bh=55SRjIEcGIdwEjqEVH4hgLwVmLY+AjppfzAkeohhSxc=; l=3150; h=To:Cc:References:From:Date:In-Reply-To; b=BEA7Jyp/71yDkozfy4+AsTgjzrr1YUtTFYH4bCPSmNkPlMJnzk2mXjkM7D8mEBs3B adqhohz71PU8ZNbKjlgU3tleC8xtOXT3xwr6T8dJY/b/RD/BhEl4Twdszzixonyv9w hSALzuffvn8CyvrrHQ2PgPba7Nf5rOeyaR1GCsZrJqFiLiKS/YSNwHJFXOqJP
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC076.000000005DC92879.00007FB2; Mon, 11 Nov 2019 10:23:05 +0100
To: "Murray S. Kucherawy" <superuser@gmail.com>, "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
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> <CABuGu1ogeUjW181MMOv3kApZR5njMMH6_84EnHxF0tDq6bhBkA@mail.gmail.com> <db4b1289-31cc-9b9e-bb5c-01bf8d6a37b3@tana.it> <CAL0qLwZcBGL8syD8FyOUkVqMzsmj4=uYM0NaSU2O3hte02AZVg@mail.gmail.com> <e45b7175-713e-da69-cc18-d0e4b59410c3@tana.it> <CAL0qLwZEEzvdvydrUUrBRRDfB-+3_7_9HB244qRC-+361cgwSg@mail.gmail.com> <CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=dxK5w@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <c1983dac-09ed-ce16-29a9-f4a734ed64c3@tana.it>
Date: Mon, 11 Nov 2019 10:23:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=dxK5w@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/H0ZERkvNR704eNolqSQ2ip9pWXo>
Subject: [dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype?
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: Mon, 11 Nov 2019 09:23:09 -0000
On Mon 11/Nov/2019 08:48:01 +0100 Murray S. Kucherawy wrote: > On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy wrote: >> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote: >>> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote: >>>> >>>>> On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote: >>>>> >>>>>> Note that RFC8617 section 10.2 ( >>>>>> https://tools.ietf.org/html/rfc8617#section-10.2) does add in an >>>>>> smtp.remote-ip method item. >>>>> If the definition of ptype smtp were "a parameter of the SMTP >>>>> session used to relay the message" it would be perfect. I'd propose >>>>> that policy.iprev be deprecated and smtp.remote-ip used instead >>>> Given that RFC8601 was published just last month, it'll probably be a >>>> while before this happens. >>> Wouldn't an accepted erratum be enough to change the wording in the IANA >>> page? >> That's not what the RFC Editor erratum system is for. The document >> reflects what the WG intended to publish at the time, so this isn't an >> erratum, it's a new change to the specification. Yes, as DE you could change it without an erratum. However, an erratum would serve as a justification to any reader who followed the definitions and noticed a mismatch. The ptype table was introduced by rfc7401, Section 3: +--------+-------------+----------------------------------------+ | smtp | RFC 7001 | The property being reported is a | | | Section 2.2 | parameter to an SMTP command used to | | | | relay the message. | +--------+-------------+----------------------------------------+ Rfc7601 and rfc8601, both in Section 6.4 claim to be a complete restatement of the definition and rules for this registry, and direct IANA to update this registry to show their Section 2.3. However, IANA still has the above definition. > Just to be clear: The policy for changes to that registry is "Expert > Review", but since the action that put it there was a document with IETF > consensus, I'm pretty hesitant about just approving this change based on a > formal request. I'd rather at least see some consensus discussion about > it, or even better, a revision/update to RFC8601. > > -MSK, this time as DE I think this group would make a better use of its time by discussing rfc7489bis than rfc8601bis. If group consensus can be enough for the time being, an erratum can also serve as a reminder. So I ask for it: Does the WG agree to an erratum as follows: TYPE: technical SECTION: 2.3 ORIGINAL TEXT: smtp: Indicates information that was extracted from an SMTP command that was used to relay the message. The "property" indicates which SMTP command included the extracted content as a parameter. CORRECTED TEXT: smtp: Indicates information that was extracted from a parameter of the SMTP session that was used to relay the message. The "property" indicates which parameter included the extracted content. NOTES This change makes the "smtp" type consistent with the definition of smtp.remote-ip given in rfc8617 Section 10.2. ? TIA for answers Ale --
- [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