Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

Steven M Jones <> Mon, 07 June 2021 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66D133A1677 for <>; Mon, 7 Jun 2021 16:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eHAJTDQSseTc for <>; Mon, 7 Jun 2021 16:21:00 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D22AD3A1676 for <>; Mon, 7 Jun 2021 16:21:00 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2/cci-colo-1.16) with ESMTPSA id 157NKlfT080205 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jun 2021 23:20:55 GMT (envelope-from
DKIM-Filter: OpenDKIM Filter v2.10.3 157NKlfT080205
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201506-2k; t=1623108057; bh=6y3XjHEzj61hxsexAisvOkx6WZKQ0BMQF3hCwBpTecg=; h=Subject:To:References:From:Date:In-Reply-To; b=W+puBuaNZjOFOMcUQn6hwQ3+9MH/k+uMHOgcOq95cji5p52lxuyqMuPQn8lBamSEv hpYeBtIBV2kQz8bsi34/Rs/cd/YB+1UitUcdr8Qt3DTm44Tj/tSsUx/6NanT40QPbv h0TxmeWVREARjACLDyxBU8gopTFPCQO1eXX6473bcstY6ajHckGTg7OpL8by06OOpi Y+divscic5LYCW261ONBQQ4tLnwOlSGyUSPP/ESrrLi9hOkuwSrP43j2GoaQdR9diR IE2B1XsLpATzAjxLoEl14T7jIMWGctFLToOChGMMq2gWZr8m5yDApSN7SlafYd146k 5btRTJ75vH0UQ==
X-Authentication-Warning: Host [] claimed to be
References: <> <> <> <> <> <>
From: Steven M Jones <>
Message-ID: <>
Date: Mon, 7 Jun 2021 16:20:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Mon, 07 Jun 2021 23:20:55 +0000 (UTC)
Archived-At: <>
Subject: Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jun 2021 23:21:07 -0000

On 5/31/21 15:49, Steven M Jones wrote:
> I think we can get the input needed to resolve this by Todd's requested
> deadline, and be able to show we did the due diligence to back up the
> decision.

I got three responses - unfortunately I discovered I don't have as many
of these contacts as I used to. So it's still anecdotal, but it includes
two of the (I don't know) dozen top mailbox providers in the world - for
whatever positive or negative weighting that may carry with you.

I'm about to add the following comment to the TRAC ticket:

I offered to try and get information on the frequency of use of this
feature from mailbox providers/report generators. I received three
responses, which I will rephrase to protect the sources. They can speak
up if they wish to go on the record.

1. Global mailbox provider A: Our code doesn't handle the syntax, and
will try to send to the address including the size specification. So if
you use that in your domain's RUA tag, our reports to you are probably
bouncing. There's a bug filed to fix it, but no commitment to do so.

2. Global mailbox provider B: We had the same bug, but fixed it - so
reports will be sent to the correct address. But regarding the limit, we
checked to see if anybody who specified a limit was receiving reports
large enough to trigger it, and nobody was. Large operators who might
actually trigger it, didn't specify a size. So we never implemented it.

3. National mailbox provider: I wrote code to implement it, but to my
knowledge it has never been triggered. Maybe our operation isn't big
enough. But implementing it was painful - guessing what the compressed
size would be, how to trim or truncate the report to fit the limit, who
to notify in the event of truncation and how... I would prefer removal,
but failing that please simplify it. [I can share the suggestions if we
go that way. --S.]