Re: [dmarc-ietf] New authentication method, DNSWL
Alessandro Vesely <vesely@tana.it> Fri, 02 August 2019 10:10 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 C93701202A4 for <dmarc@ietfa.amsl.com>; Fri, 2 Aug 2019 03:10:49 -0700 (PDT)
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 6utIdTGcehE2 for <dmarc@ietfa.amsl.com>; Fri, 2 Aug 2019 03:10:48 -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 26EB81200C1 for <dmarc@ietf.org>; Fri, 2 Aug 2019 03:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564740645; bh=W8YMlc4kViZhEXdNo6lJcmu0nRuVMv3oZooV4fM2YC0=; l=1313; h=To:References:From:Date:In-Reply-To; b=A5sP/4kTctvXybzlO7di/eOcfwGBthjSaAkeOSpOTyewMDbgVhn+4k4jrO0HZ/P5Q bFaSZ3vbjmUWXT91SuZB1Ovu4Iqogm5roWlBHeWulveU5OiJXEbLxYTEUE9IT9vWJQ /nIFGHqgIzMEkvP2oHTuO8lnKEQd/r8UlxME68++x+wmzA8n1v+eZBQhNWkHu
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.000000005D440C24.00003220; Fri, 02 Aug 2019 12:10:44 +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> <CAL0qLwZJ=1r8Za0G3AsxX-L00o4qukJFVATKQCwX9V7yE0v7xQ@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <d442a08b-621b-d577-54bb-a8ad8ef6fe93@tana.it>
Date: Fri, 02 Aug 2019 12:10:44 +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: <CAL0qLwZJ=1r8Za0G3AsxX-L00o4qukJFVATKQCwX9V7yE0v7xQ@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/_iJfGdTX3tplflF-t9ooDx5vxM8>
Subject: Re: [dmarc-ietf] 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 10:10:53 -0000
On Fri 02/Aug/2019 08:18:20 +0200 Murray S. Kucherawy wrote: > On Thu, Aug 1, 2019 at 9:32 AM Alessandro Vesely <vesely@tana.it> wrote: > >> Let me narrate a use case. Courier-MTA can be configured to reject on >> SPF -all early in the SMTP dialogue, except if whitelisted. It writes SPF >> as well as dnswl results in the header, but does not interpret the >> policy.ip. Downstream filters can interpret the field based on the >> dns.zone. I use that feature to pass messages tagged "Heuristic" by the >> antivirus filter if policy.ip has a positive trustworthiness.>> > > I think this is a bit unusual, but RFC8601 doesn't preclude it. Seems to me > you're effectively throwing away the result, "pass" or "fail", if downstream > agents actually know more about the applied algorithm than the border MTA > adding it. In the case at hand, in fact, failed lookups are never reported. If no dnswl query is configured, it makes no sense to configure which trustworthiness value is needed to counterbalance which negative heuristics. The "pass" just confirms it's mere presence. In general, however, a filter may want to distinguish dnswl!=pass from no dnswl query at all. A negative query (NXDOMAIN or NO DATA) would be dnswl=none. No "fail" is provided for in the I-D. Best 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