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

Alessandro Vesely <vesely@tana.it> Sat, 03 August 2019 15:40 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 6138412008F for <dmarc@ietfa.amsl.com>; Sat, 3 Aug 2019 08:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=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 kGrxMyTvu_Us for <dmarc@ietfa.amsl.com>; Sat, 3 Aug 2019 08:40:26 -0700 (PDT)
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 0D85C12008B for <dmarc@ietf.org>; Sat, 3 Aug 2019 08:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564846823; bh=/0ffeyS0dXtrucm5BdlPbkMbEojx0GYoNfjTYh1OSLQ=; l=617; h=To:References:From:Date:In-Reply-To; b=A5BDZS+Ph1WShFYvJHnaxFkLsWG4/GMER625zOxlfh3FtrB8Mb6Z35XPpH0ZaVHGD ZIGxz/bH/N6tbhN4xJlob5JVm+DMd4rjGwXYSzGkdzqeKpJbCfT6//K3ZRRG76w2U1 ZuGFKH7540wRWwNnAwgXNYI3NFurfYqeUTRJ30In2v3KQ30LSVypSurcc1xdD
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 00000000005DC042.000000005D45AAE7.00000834; Sat, 03 Aug 2019 17:40:23 +0200
To: 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>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <db4b1289-31cc-9b9e-bb5c-01bf8d6a37b3@tana.it>
Date: Sat, 03 Aug 2019 17:40:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CABuGu1ogeUjW181MMOv3kApZR5njMMH6_84EnHxF0tDq6bhBkA@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/nli31UHaq6CR3Grk0eAsbaRX7P8>
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: Sat, 03 Aug 2019 15:40:28 -0000

On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote:

> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <vesely@tana.it> wrote:
> 
>> To stick with A-R semantics, it should have been named tcp.ip, remote.ip
>> or some such.>>
> 
> Note that  RFC8617 section 10.2 (
> https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
> smtp.remote-ip method item.


That's much better.  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.


Best
Ale
--