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

Alessandro Vesely <vesely@tana.it> Tue, 08 June 2021 08:32 UTC

Return-Path: <vesely@tana.it>
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 B1D1B3A27E8 for <dmarc@ietfa.amsl.com>; Tue, 8 Jun 2021 01:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 8Ssj6xZUXYbo for <dmarc@ietfa.amsl.com>; Tue, 8 Jun 2021 01:32:24 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 73FAC3A27E7 for <dmarc@ietf.org>; Tue, 8 Jun 2021 01:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; 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: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.0000000060BF2B13.0000054A; Tue, 08 Jun 2021 10:32:19 +0200
To: Steven M Jones <smj@crash.com>, dmarc@ietf.org
References: <CAHej_8npHwekgJDLOV=hVPdd0OFoMumJCKL5Yitz5oWrhkQdNg@mail.gmail.com> <a8ef636c-815a-6b40-a955-b7049afba82f@crash.com> <a7fc5ba7-e17b-72b5-e81a-1dd0ac6cb418@tana.it> <CALaySJ+FGMBA2AuNzwUOyA5eccUkQ399Kc3c-oj99oZRov8oPQ@mail.gmail.com> <88957ada-7514-f664-6269-88503c1a81fd@tana.it> <fc795d67-1003-32cd-d99a-fa9256a802a1@crash.com> <c2ae5c84-53fa-8d5e-b912-8433d5798698@crash.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <8f57f42c-735e-0bb3-98a7-06514687342f@tana.it>
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: <c2ae5c84-53fa-8d5e-b912-8433d5798698@crash.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/0LNJw3gfuqc2DwLLZhNQW92rz8Y>
Subject: Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes
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: Tue, 08 Jun 2021 08:32:30 -0000

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

Best
Ale


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
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>