Re: DMARC methods in mailman (off-topic)

Brian E Carpenter <> Thu, 22 December 2016 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0A8D1297AB for <>; Thu, 22 Dec 2016 13:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ffI_5bQPvOi2 for <>; Thu, 22 Dec 2016 13:30:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65A03129766 for <>; Thu, 22 Dec 2016 13:30:23 -0800 (PST)
Received: by with SMTP id f188so101613570pgc.3 for <>; Thu, 22 Dec 2016 13:30:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=be5Y7fFXfthFiEGj3zTUKyGjKe6r6ZzcgP4UIi+1flA=; b=V0gqWEXbvl3AHas3WHbqLmZeeRJjazm93gcVPTKlULPx4moQB3QL+mP0241TjS3hYo HziK4kf10e9h9yAh+myWihg6aARHluZJpr4VqTgF5+ACmp/pPSF/UIL/iGQYzNuY3ZHG iG4MUaAT6q94SIQTuF6cOrHgy8jVFtZwvULuVqNk0xMWGEV2PjaW73Q3Q2eViL0FoDUS 7a3I+6ExANsVUA4OB/R4HnN7/ADe+Ds3VItwH+Lvo6irZC+G2YEz7DoEfXLCzjoe6mB9 ajbEv3h9WV00SYWfD2kVLSKrLm+SiCurIQNTihxOj4WvjPmKvWPcTRR15TJgii1VfVbH 9t5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=be5Y7fFXfthFiEGj3zTUKyGjKe6r6ZzcgP4UIi+1flA=; b=qndWpSgrXQ5Fw5G2+4ig9PIrHfC8s4KEUHwxmDfmcj8GAnV9wy+bHdPk/kUeQG5bkx h0yCg6shOlJPUtVjiA7+1EhWBXHswHsKZmfgdRt7Bo4Z/plC+mVm8Lp2gs5mi7Ubiha8 03PDZhfCykvhXGp5Is4mTJbRcB5onn/Gxx+JlDyJa+OOGJYMXiMtugUs1/Qw4gg4h6G9 pXL9MUBD3Y7jqATtHUt/sLL6W/XfQrgzip9TbG4k6eEOd5AlG468lUPVWre4BOuaN4LR qXjcnvE7JuTd+Hsw4WLTZXznASHOjBZyHs+767+/eNwkotcqsq8SLvRc8TwoZzVJyjco hxlA==
X-Gm-Message-State: AIkVDXLtI3up39cXqBrLcqaQglCsSQPt1/D1BGuZR8lIz5n42dgWGcah/O0ZZrqcSU8RFQ==
X-Received: by with SMTP id h8mr20123432pgc.93.1482442222968; Thu, 22 Dec 2016 13:30:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e5sm56857806pfd.77.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Dec 2016 13:30:22 -0800 (PST)
Subject: Re: DMARC methods in mailman (off-topic)
To: Hector Santos <>,
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 23 Dec 2016 10:30:29 +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: <>
Content-Type: text/plain; charset=utf-8
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: Thu, 22 Dec 2016 21:30:24 -0000

On 23/12/2016 10:12, Hector Santos wrote:
> Hi,
> 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?

No, that's just standard marketing lies. If anybody actually reads the
RFC in question, it says:

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.


> I hope not. Especially when a proposed standard ADSP rfc5617 was 
> officially abandoned for the 100% same issues and problems its 
> replacement "Super ADSP" a.k.a. DMARC has.   So if we abandoned ADSP 
> for reason X and DMARC suffers the same exact X problem, shouldn't it 
> be abandoned as well?