I have closed the subject ticket and incorporated relevant text changes in draft-ietf-dmarc-dmarcbis-02, which will be published on Datatracker as soon as the chairs have a chance to do so.
On Tue, Jun 8, 2021 at 4:32 AM Alessandro Vesely <ves...@tana.it> wrote: > 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 > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
