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

[Todd Herr]

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  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

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

[Alessandro Vesely]

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

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

[Steven M Jones]

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

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

[Steven M Jones]

I'm not philosophically or religiously opposed to removing the size
limit but I would like to have some data, or at least informed feedback,
to justify the decision.

This feature was not in the original December 2011 specification, but
was added in the March 2012 revision (both were pre-IETF). I'm betting
that was done because of first-hand operational issues, though of course
things have changed in ~10 years and it may no longer be necessary.

I appreciate Ale's anecdote that his size-limit code has never been
triggered, that kind of information is useful. I think the larger report
generators are the best place available to get this information, and I
will try to chase down people who can provide it this week.

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.

Thanks,
--S.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Mon 31/May/2021 01:41:08 +0200 Barry Leiba wrote:
Yes,  but you’re speaking as a report CONSUMER.  Steve said “report 
generator”, and the point is that there is no evidence that anyone generates

this.  Yes?



No, I meant recognizing the suffix and aborting as producer actions.  That is 
roughly documented by saying: "If the size limit is exceeded, the child is 
killed with SIGTERM."

https://www.tana.it/sw/zdkimfilter/zaggregate.html


Concoction about Google's behavior originated from Brandon's sentence: "We 
already generate multiple reports to address because of size constraints."

http://lists.dmarc.org/pipermail/dmarc-discuss/2020-January/004326.html


Best
Ale
--


On Sat, May 29, 2021 at 5:29 AM Alessandro Vesely  wrote:
[...]

What I do is to recognize the ! suffix and abort sending if that is
exceeded.  I heard that Google instead do a real chunking[...]
















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Barry Leiba]

Yes,  but you’re speaking as a report CONSUMER.  Steve said “report
generator”, and the point is that there is no evidence that anyone
generates this.  Yes?

Barry

On Sat, May 29, 2021 at 5:29 AM Alessandro Vesely  wrote:

> On Sat 29/May/2021 02:30:47 +0200 Steven M Jones wrote:
> > On 5/28/21 08:46, Todd Herr wrote:
> >>
> >> Consensus on Ticket #53 
> (Remove
> >> reporting message size chunking) was reached during the May 27 DMARC
> Interim
> >> to remove the feature and update the IANA registry and ABNF grammar as
> necessary.
> >
> > I support the removal, unless a report generator speaks up by June 11th
> saying
> > they support the feature.
>
>
> If, by supporting, you mean coding, then I, for one, support it.  What I
> do is
> to recognize the ! suffix and abort sending if that is exceeded.  I heard
> that
> Google instead do a real chunking; that is, they'd send a truncated report
> followed by the remaining chunks, all within the limits.
>
> However, despite my coding, that feature was never triggered.  And I never
> heard about the top aggregate report sizes at large provider's.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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

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

[Alessandro Vesely]

On Sat 29/May/2021 02:30:47 +0200 Steven M Jones wrote:

On 5/28/21 08:46, Todd Herr wrote:


Consensus on Ticket #53  (Remove 
reporting message size chunking) was reached during the May 27 DMARC Interim 
to remove the feature and update the IANA registry and ABNF grammar as necessary.


I support the removal, unless a report generator speaks up by June 11th saying 
they support the feature.



If, by supporting, you mean coding, then I, for one, support it.  What I do is 
to recognize the ! suffix and abort sending if that is exceeded.  I heard that 
Google instead do a real chunking; that is, they'd send a truncated report 
followed by the remaining chunks, all within the limits.


However, despite my coding, that feature was never triggered.  And I never 
heard about the top aggregate report sizes at large provider's.



Best
Ale
--















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

On 5/28/21 08:46, Todd Herr wrote:
>
> Consensus on Ticket #53 
> (Remove reporting message size chunking) was reached during the May 27
> DMARC Interim to remove the feature and update the IANA registry and
> ABNF grammar as necessary.


I support the removal, unless a report generator speaks up by June 11th
saying they support the feature.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Fri, May 28, 2021 at 2:01 PM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote:
> >>
> >> Consensus on Ticket #53 
> (Remove
> >> reporting message size chunking) was reached during the May 27 DMARC
> Interim to
> >> remove the feature and update the IANA registry and ABNF grammar as
> necessary.
> >
> >Agreed.  However, the grammar should be retained in order to not
> invalidate
> >existing records.  Any !10m tail should just be ignored.
>
> What I heard at the interim was that not only does nobody implement size
> limits,
> some large receivers don't recognize the !nn suffix and the reports fail.
> Take
> it out so the spec agrees with reality.
>
> R's,
> John
>

+1 to what John wrote.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

It appears that Alessandro Vesely   said:
>On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote:
>> 
>> Consensus on Ticket #53  (Remove 
>> reporting message size chunking) was reached during the May 27 DMARC Interim 
>> to 
>> remove the feature and update the IANA registry and ABNF grammar as 
>> necessary.
>
>Agreed.  However, the grammar should be retained in order to not invalidate 
>existing records.  Any !10m tail should just be ignored.

What I heard at the interim was that not only does nobody implement size limits,
some large receivers don't recognize the !nn suffix and the reports fail.  Take
it out so the spec agrees with reality.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote:


Consensus on Ticket #53  (Remove 
reporting message size chunking) was reached during the May 27 DMARC Interim to 
remove the feature and update the IANA registry and ABNF grammar as necessary.



Agreed.  However, the grammar should be retained in order to not invalidate 
existing records.  Any !10m tail should just be ignored.



Best
Ale
--
















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc