Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

Hector Santos <hsantos@isdg.net> Fri, 09 November 2018 16:32 UTC

Return-Path: <hsantos@isdg.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 924FD12D4F0 for <dmarc@ietfa.amsl.com>; Fri, 9 Nov 2018 08:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=c/VfRt6O; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=kjGH8osh
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 wHOosR0z-5yT for <dmarc@ietfa.amsl.com>; Fri, 9 Nov 2018 08:32:30 -0800 (PST)
Received: from demo.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2A59B128CF2 for <dmarc@ietf.org>; Fri, 9 Nov 2018 08:32:29 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2495; t=1541781147; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=fWS36cQaHt9uyKRahvRO+dPjSDo=; b=c/VfRt6OVrb506p5t+KPBnjpPJ6NB7ILPhx7894O5i6kyLS/MdSMB3F42rB6UZ PgIJMwH2XDB9YJTC+qROUC9H5lO20yrSyod7ykSo2ePcnXqTUbDh6V0BiuqXXyrL RBXFEQtd3lCOnKQjiBmOss8XwN9R3LHnSBIgbKL/rNpfs=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 09 Nov 2018 11:32:27 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 778097247.1.1828; Fri, 09 Nov 2018 11:32:26 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2495; t=1541781041; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gwD37FV n78N89trTRVaZIjEafiGg5icZpSeY64hGtQs=; b=kjGH8oshTpnvl68z0xmlcJJ XUNIwUCgrLyF1YCPv20Jqq19CM/16FkqV1pwpFaNsV32tA06OFCMGM9IesmpOCf0 UO+THxu242WIrO81v4icYId6RiLjD2OMzgQJR1QhThLzQFWvKGspOcrx2GcXDEhI KStG4LjzqTSm7mScqDp8=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 09 Nov 2018 11:30:41 -0500
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1326086641.9.305472; Fri, 09 Nov 2018 11:30:40 -0500
Message-ID: <5BE5B693.9060706@isdg.net>
Date: Fri, 09 Nov 2018 11:32:19 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dmarc@ietf.org
References: <CABuGu1o4E-Svt9N++RaFvO4SATt3Wh1w7gZb1OdBSVRCm7Odmg@mail.gmail.com> <CAC4RtVCQmV5agORght0XWr27kDD+OkaEZcKcaDtE8wLG0Yi-YA@mail.gmail.com> <dee0fd86-40e3-e01d-6c70-2f467759be8b@tana.it> <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <AB35FEF5-74C9-400D-9A7F-543F9CAA215D@kitterman.com> <CABuGu1pXaXioyPTV6OXD3hWBXVjt5+kk0dqaZwbDcKaU+Y6q5A@mail.gmail.com> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> <CAL0qLwZF55yaxZKYY8AQdcRfUr2WjMwfpd2FVWn3hCR67_E5eg@mail.gmail.com>
In-Reply-To: <CAL0qLwZF55yaxZKYY8AQdcRfUr2WjMwfpd2FVWn3hCR67_E5eg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/izuFT0IM1dSh0PxbLAauf2Gdh7o>
Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
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 Nov 2018 16:32:32 -0000

On 11/8/2018 1:19 PM, Murray S. Kucherawy wrote:
> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely <vesely@tana.it
> <mailto:vesely@tana.it>> wrote:
>
>
>     > and maybe it can solve the "PSL problem" if we can constrain the problem
>     > space to just the DMARC issues instead of recreating the
>     > DBOUND-solve-for-all morass.
>
>     This problem is simpler than DBOUND.  Looking up text policies is
>     common to a
>     handful of protocols.  A careful wording might make some
>     statements reusable in
>     general, even if the focus is kept on DMARC.
>
>
> Sure, the DMARC case is half of what DBOUND tried to tackle.  If
> DBOUND had focused just on the DMARC use case, it would've succeeded.
>
> If possible, we should be careful to create a solution that's
> extensible to other use cases, not exclusive of them.  Reviewing what
> DBOUND tried to do might be very instructive here.

+1 (although I am not too keen on depending on a new RRTYPE)

I think we should be focusing on working on a DMARC proposed standard, 
Standard Track status document and codify the many implementation 
issues, including:

   - The Author Domain identity (ADID) policy Lookup procedure with
     support for minimal organizational lookup concepts,

   - alignment issues (clarifications),

   - rejection logic (clarifications), and

   - ADID Rewriting implementation logic for List Systems, in order to
     maintain (as much as possible) the original organizational POLICY
     security.

The above are the key implementation issues I am currently going 
through as I am updating/migration/augmenting DMARC into my existing 
ADSP/ATPS/DKIM package but one where we would like to finally add and 
honor the (risky) policy disposition logic (rejection, quarantine).

For all these years, we did the Auth-Res header generation/recording 
with the idea of using a future filtering module. We are at this point 
now, especially since the industry has finally "accepted" after more 
than a decade, the original proof of concept, DKIM Author Domain 
Policy model.

Anyway, there is good new proposed work, but in my opinion, since this 
is really all time consuming (and costly), and it will take a long 
time, I think we should view the new work as part of DMARC and finally 
focus on working on the IETF-sanctioned DMARC "Standard Track" status 
specification and get all the learned implementation details codified 
and worked out.

Have a good weekend,

Hector Santos/CTO
Santronics Software, Inc.