Re: DMARC methods in mailman (off-topic)

Hector Santos <> Fri, 23 December 2016 02:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FC301295D6 for <>; Thu, 22 Dec 2016 18:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=wYamMBQM; dkim=pass (1024-bit key) header.b=nNLTQ6XQ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1eJ_z3fNdkAS for <>; Thu, 22 Dec 2016 18:55:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5AE1B129492 for <>; Thu, 22 Dec 2016 18:55:15 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2085; t=1482461709;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=8o+DE+X4wsIhV8ucEaZKUwdcLWE=; b=wYamMBQMRqbQcWx3Dh7Q/JaVu5yPAe0mYcstw4/GU+tylCun3euARqwcNviuoL WKs2eMp7eZRUETE5SIl1IQvrpKrDDKbjljk8wtIV5AqkNkRHNyopJZ+tU7dxGQYA Ix6etIC43OoFx6FdB/hLZd3cO44onioL2mvSZOiO2C3u0=
Received: by (Wildcat! SMTP Router v7.0.454.5) for; Thu, 22 Dec 2016 21:55:09 -0500
Authentication-Results:; dkim=pass header.s=tms1; adsp=pass policy=all;
Received: from ([]) by (Wildcat! SMTP v7.0.454.5) with ESMTP id 4000633940.1.5684; Thu, 22 Dec 2016 21:55:07 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2085; t=1482461598; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=8sXtjUO ms/rfrnZrnKTe54uyfdOTrLL0xGSy6MmXW34=; b=nNLTQ6XQvz2RvZ5tJbtlIiG t12JJ9t8/KDwCp/hUPRfESN57sPMnrCbDYD9YcUNL6KBBdCCuhCphPAzedgPURzU 4GXft6/4UlB5q8W+VZ34Q1lxNq7OMRKbRIDpzDWc93Y0l72hQ37or3DaQDN59Z85 fSnLJ8jqAE5QBC8MVfmk=
Received: by (Wildcat! SMTP Router v7.0.454.5) for; Thu, 22 Dec 2016 21:53:17 -0500
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.5) with ESMTP id 3997061953.9.654728; Thu, 22 Dec 2016 21:53:17 -0500
Message-ID: <>
Date: Thu, 22 Dec 2016 21:55:09 -0500
From: Hector Santos <>
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:, S Moonesamy <>
Subject: Re: DMARC methods in mailman (off-topic)
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Dec 2016 02:55:17 -0000

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.  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).  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.