On Wed, Dec 17, 2025, at 21:56, Hannah Stern wrote: > Hi! > > On 12/16/25 19:13, John Levine wrote: > > It appears that Hannah Stern <[email protected]> said: > > >> May c: instructions in body recipies (r=) overlap? This would allow > >> attempts to have verifiers use excessive memory/CPU like this: > > >> Message-Instance: v=1; ... (Referring to a one-line body) > >> Message-Instance: v=2; r=c:1-,c:1-,c:1-,c:1-; ... > >> Message-Instance: v=3; r=c:1-,c:1-,c:1-,c:1-; ... > >> (and up to 96 more of those) > > > I can't think of a plausible reason to have overlapping recipes. Unless > > I've > > missed something it sounds like we should have a section on implementation > > limits > > and put that in it. > > If we define them as invalid, that constraint (c: recipes may not > overlap) could perhaps be rather specified "in place" in the main > specification of theirs. > > Followup question: Can c: recipies be non-monotonic? (c:4,c:2) > > If they should be specified to be monotonic, an implementation could > stream and discard already processed chunks of the input version of the > mail body, on the assumption that if it has seen a c:1000 recipe, it > won't ever need lines 1-1000 of the input again.
I think that's fine - we could say that for both header and body recipes, that they have to be monotonic and non-overlapping. I can think of cases where you might not do so, but they're all kinda bullshit "maximal compression" nonsense (e.g. reusing a mime boundary) which I'd be happy not to allow given the additional risks it adds for very minimal benefit. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
