Re: DMARC methods in mailman (off-topic)

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 23 December 2016 19:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EADD129472 for <ietf@ietfa.amsl.com>; Fri, 23 Dec 2016 11:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ct3X01N_1mlQ for <ietf@ietfa.amsl.com>; Fri, 23 Dec 2016 11:58:08 -0800 (PST)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838F91294CC for <ietf@ietf.org>; Fri, 23 Dec 2016 11:58:08 -0800 (PST)
Received: by mail-pg0-x22c.google.com with SMTP id i5so47252461pgh.2 for <ietf@ietf.org>; Fri, 23 Dec 2016 11:58:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fqBw93sUfOTMSORA5oh2HKOs47FFBrXA2F3uoJuwUnk=; b=a+nC0dLv2IkRgVvYoXR5/ieBkIur9rnvbaGM3YbLPVFoWXkPGqPRdhmVLlP9B3THxQ QtYvJtDMk5ozuC+7a9TdYU0j7RUX66REVrVbAhm8FjF3np4s2FSw5SFVcMAO/24De0TQ fBp2JTkp+XyM96iji4/e8yc9Tozl1Hw1kLrUWh2EbJVtRgf3gddk73eOi6zgS0F2DOh7 3lpETMm75Q3so6stZiWZT92Gje82RGbNdN8qmSGPgeEfzXoqNGMO0grv++OLBmH2bTTM heXiWfH4UAy3FMgsD1Lt1hDHAsAsYbq03GE71XTHGUkQglOChIGXBlgYJgUgWqeh1S4e js8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=fqBw93sUfOTMSORA5oh2HKOs47FFBrXA2F3uoJuwUnk=; b=EgvWa4YWmPAp9FJ4aHmqCIIqhrKputpBm92pRPx9SN6gXA+6u0pdl1mKWQRgDN2Pnb 5hno0bqHOBgn6qcK5fBLT9KfbiJLk1bvL0bUQuBGhR+E45MgUD22eDkBVQxMeLOUgBze RAnPj/ql/iWC6NJDfNGa0gBdbbKQ8bixBvEv2m1Xg7i5E3+1VWXzjc5LeRiiItnlHb9S 1y+nmWP/aVR/dpHW/e/YNQq5EUIyXaHfayHeUfB9w/R5uhP1mpZvpYKNpA4AnGNqr8W5 8790NfIGEnFBDEb8cnqmkoqVTD92FHHp/+eJTwOtdV2Wi0roMlahOML8619SzwKRi05g uReA==
X-Gm-Message-State: AIkVDXIeUFtH+0RGTS//h63yRKUQiHfEp9pcVrO/kZo1Iq2JKs4gQwwOqldcOnMzfuqntA==
X-Received: by 10.99.250.69 with SMTP id g5mr28648358pgk.15.1482523087852; Fri, 23 Dec 2016 11:58:07 -0800 (PST)
Received: from [192.168.178.27] ([118.148.124.104]) by smtp.gmail.com with ESMTPSA id r26sm59315364pgd.42.2016.12.23.11.58.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Dec 2016 11:58:07 -0800 (PST)
Subject: Re: DMARC methods in mailman (off-topic)
To: Hector Santos <hsantos@isdg.net>
References: <6.2.5.6.2.20161222061125.0adacfa0@elandsys.com> <585C41A4.6030008@isdg.net> <6.2.5.6.2.20161222140544.0c9712b8@elandnews.com> <585C920D.40200@isdg.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <025ec2c5-9205-9914-4cc6-2870c0e0693c@gmail.com>
Date: Sat, 24 Dec 2016 08:58:15 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <585C920D.40200@isdg.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1RFFiNDgLpgZweVArhp1CMu8mhk>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2016 19:58:18 -0000

Hector,
On 23/12/2016 15:55, Hector Santos wrote:
> On 12/22/2016 5:46 PM, S Moonesamy wrote:
>> Hi Hector,
>> At 13:12 22-12-2016, Hector Santos wrote:
>>> Is that the new modus operandi within the IETF, that extremely weak,
>>> poorly engineered Informational Docs can be fast tracked as a
>>> "standard" in the IETF?
>>
>> The way to publish an IETF Proposed Standard or IETF Informational
>> document has been the same for over a decade.  I don't think that the
>> IETF has changed its way of doing that.
> 
> Well, for a while now, there has a number of efforts to fast track 
> items using Informational Status submissions which has, no doubt, been 
> leveraged as a means to bypass critical IETF reviews. 

Please read up on the Independent Submission stream of RFCs, how they
work, and what they are for: https://www.rfc-editor.org/about/independent/
It isn't a matter of fast tracking; actually I suspect that it's significantly
slower than the IETF track in many cases.

> DMARC is most 
> definitely one of them.  Lets not fool ourselves.
> 
> For all intent and purposes, DMARC has been pushed as a "standard" 
> work item within the IETF working group(s).

Whether or not it was pushed, it was not accepted and did not gain
IETF consensus, as Informational or anything else. The fact that marketing
managers and journalists can't read plain English is no surprise, but
not something that the IETF can fix. Among ourselves, we should read the
"status of this memo" section of every RFC we consult.

    Brian

> Additional add-ons and 
> higher overhead mail altering suggestions are being proposed to 
> address problems it causes.  The same problem ADSP was abandoned for.
> 
> We might call it a "pseudo-standard" because of wide usage but in 
> reality it is still an informational status document.  That should 
> change so it can get the proper status and wider and more complete 
> engineering reviews, and frankly more serious considerations. Since 
> ADSP was abandoned, a large investment was lost. I have a problem of 
> fully committing to a Informational Status DMARC protocol that has the 
> same problems ADSP had.  Why should I further invest in it?
> 
> I support an IETF standardization effort of DMARC with a charter that 
> includes development of additional options we need in order to support 
> 3rd party Authorization method with the expansion of policy options 
> and plus relaxation of any reporting requirements.
> 
> If we had completed this work when ADSP was the proposed standard, we 
> would of been done with this issue long ago or at least completed to 
> the point where List systems would be in a better position to adjust 
> with a simpler policy DNS lookup protocol.   Its been over 10 years 
> now. Something has to give with this work already.
> 
> Thanks
>