Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports

Dave Crocker <dhc@dcrocker.net> Sat, 01 June 2019 17:54 UTC

Return-Path: <dhc@dcrocker.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 3B84F120167 for <dmarc@ietfa.amsl.com>; Sat, 1 Jun 2019 10:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 9Gb6d1zHB6rE for <dmarc@ietfa.amsl.com>; Sat, 1 Jun 2019 10:54:24 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568C41200FE for <dmarc@ietf.org>; Sat, 1 Jun 2019 10:54:24 -0700 (PDT)
Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x51Hq7RZ020097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2019 10:52:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559411530; bh=WhSe6twbiUWe7wFcx/Ih5GVQBmc/zhyRK8LoQ6Pt20U=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=fKJNGQ7d6MMBqS4sOWhNBtdcN30OUwMONsqxDZ7VcM59XV7b+Tp6TDPZX4g+i1+4g vVNRyfuM03g3LeufCBv84DEes3+v3zafShoBjadC20IkYKRwZwrBPHKT3yz5kXgY/i p0al5W+saUTcN5pAMW3rU5engYjGq3+zFJEQ7rgQ=
To: "Murray S. Kucherawy" <superuser@gmail.com>, Alexey Melnikov <aamelnikov@fastmail.fm>
Cc: IETF DMARC WG <dmarc@ietf.org>, Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> <CAL0qLwZpCmOV58Zc=ALJzfTsX-4F=5=d882+RYyRXFvkhb4PSQ@mail.gmail.com> <f5c5ea46-71ec-4fdd-36bb-fce37271d894@dcrocker.net> <B21CC6FB-2F2C-4AA6-8DAA-05B026DF0E4E@fastmail.fm> <CAL0qLwYb+giO9_HuZ2zXHTO5EgHrN+a2ssTOK+gRAx1-DZydCw@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Message-ID: <32202ca2-6ed4-8c48-dad2-82893601dd95@dcrocker.net>
Date: Sat, 01 Jun 2019 19:49:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwYb+giO9_HuZ2zXHTO5EgHrN+a2ssTOK+gRAx1-DZydCw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wqRgiDB0HSRwiWOTO-U7E7j4Tu4>
Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports
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: Sat, 01 Jun 2019 17:54:27 -0000

On 6/1/2019 5:38 PM, Murray S. Kucherawy wrote:
> My understanding matched Dave's originally, but then I found this:
> https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/


Interesting.  I've never seen that before.  I suspect few others have.

I was educated on the model I described by having a design change -- I 
don't remember whether it fixed a design error or added an enhancement 
-- refused for the errata record and I was told errata were only for 
documentation errors -- that is for cases in which the document did not 
adequately described "what was intended".  So, anything that alters what 
was intended by the wg and/or authors was declared out of scope.

While this was some years ago, I'm quite sure it was long after the date 
of the IESG document.

FWIW, it strikes me as a little crazy to have errata admittance rules be 
different for different streams.  What is the possible benefit that is 
major enough to warrant the additional complexity?  But that's just me.

Taking the current case, while it's nice that Alexey is friendly to 
adding this item as a hold, I'll suggest that the decision should rest 
with the troops already tasked with assessing the submission.  There 
doesn't seem to be a good reason to require an AD to make that decision.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net