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

Alessandro Vesely <> Tue, 08 June 2021 08:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1D1B3A27E8 for <>; Tue, 8 Jun 2021 01:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Ssj6xZUXYbo for <>; Tue, 8 Jun 2021 01:32:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73FAC3A27E7 for <>; Tue, 8 Jun 2021 01:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1623141139; bh=bYDIM9CsKYuuSvuwU9NRlzNWfev0VjR+I0FNMXJ8JiQ=; l=2303; h=To:References:From:Date:In-Reply-To; b=DRpFveOtWlgp1jP/gNyWjSSp8zy8PNwG+oXP+FMz4IduBW/sAHLT5grUjaAuTNCwl ZVqP63ZYNCRn4L9wfftjldqUpVX0zzjPNFAwpEYJYAh7kneUcrtZK59MgoZdN+VAqj wQn4rSYEKm8WVo3yCR20QxsuJAU9tn6jVDy8NYbWiLssMs5qVBgyG0jsFy4cf
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC02A.0000000060BF2B13.0000054A; Tue, 08 Jun 2021 10:32:19 +0200
To: Steven M Jones <>,
References: <> <> <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Tue, 8 Jun 2021 10:32:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Tue, 08 Jun 2021 08:32:30 -0000

Thank you Steve, this confirms size limits are a useless encumbrance on reporting.


On Tue 08/Jun/2021 01:20:55 +0200 Steven M Jones wrote:
> 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.]
> --Steve.
> _______________________________________________
> dmarc mailing list