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, 2 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
--