Hi Mauro, But you know that about 90% of the worldwide email infrastructure (sendmail, exim, postfix, and others) runs C on C++ based?
Rust is only a side-note here. Regards, Timo It looks like Mauro De Gennaro aimed to say: > Hi Timo, > > I don’t do C anymore but here’s running Rust code of a full DKIM2 > implementation. Please do try to break it: > > mail-auth.png > mail-auth/src/dkim2/mod.rs at main · stalwartlabs/mail-auth > <https://github.com/ > stalwartlabs/mail-auth/blob/main/src/dkim2/mod.rs> > github.com > <https://github.com/stalwartlabs/mail-auth/blob/main/src/dkim2/mod.rs> > > <https://github.com/stalwartlabs/mail-auth/blob/main/src/dkim2/mod.rs> > > > Best, > Mauro > > PS: https://xkcd.com/386/ <https://xkcd.com/386/> > > > >> On 24 Sep 2026, at 8:43 pm, Timo Gerke <[email protected]> wrote: >> >> Hi Mauro, >> hi all, >> >> Yes Mauro, Streaming JSON would be possible, if it were a stream, >> but it is encapsulated. When I hear SAX, I need to think about >> music. >> >> BTW: Hannah also said "That's not nice, that's DoS. [...] Change >> the spec to forbid additional items in the top-level JSON >> Object. ", think about it. >> >> Mauro, if you think, that the actual design has no flaws, >> provide running C code. >> >> Best, >> Timo >> >> It looks like Mauro De Gennaro aimed to say: >>> Hi Timo, >>> >>> Every conclusion in your message rests on assumptions about how a >>> particular >>> parser happens to be implemented. >>> >>> MIME is not linear by nature. It is a nested format: multipart containers >>> can >>> hold further multipart containers, and message/rfc822 parts can embed >>> entire >>> messages. A parser that recurses on that structure can be driven to stack >>> exhaustion by a deeply nested message, and this has happened in real >>> products. "Streaming and linear" describes a well-written MIME parser, not >>> MIME itself. >>> >>> The same reasoning applies to JSON. JSON encapsulated in JSON does not >>> require building a DOM. Streaming, event-based parsers have existed for >>> many >>> years and process input incrementally with bounded memory, including for >>> long >>> flat arrays. Whether an implementation builds a tree, recurses, or streams >>> is >>> a design decision by the library author, not a property of the format. >>> >>> The picture you describe is also outdated and does not match how modern >>> libraries are written. Current parsers commonly enforce configurable limits >>> on nesting depth, input size, and allocation, and they fail cleanly when >>> those limits are hit. A crafted envelope causing an immediate process >>> collapse describes a naive or unmaintained implementation, not the state of >>> the art. >>> >>> The only vulnerability in this scenario is the use of a flawed library, and >>> a >>> specification cannot repair a flawed library. An implementer who picks a >>> parser that cannot safely handle untrusted input will have the same problem >>> with MIME, JSON, or any other format. I would ask that we not present this >>> as >>> a structural weakness of the DKIM2 design, because the argument does not >>> hold up. >>> >>> >>> Best, >>> Mauro >>> >> >> >> Timo Gerke >> Hamburg, Germany >> >> "If you think technology can solve your security >> problems then you don't understand the problems >> and you don't understand the technology." >> -- Bruce Schneier >> <OpenPGP_0x9F03DF9F597BF31E.asc> >> _______________________________________________ >> Ietf-dkim mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] Timo Gerke Hamburg, Germany "If you think technology can solve your security problems then you don't understand the problems and you don't understand the technology." -- Bruce Schneier
OpenPGP_0x9F03DF9F597BF31E.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
