Hello Hannah,
I understand the time constraints. But this makes the exchange circular:
you ask for a specific constructive alternative and a working
implementation (which can be found on GitHub), while refusing to consult
the draft that contains both. DarkChain is precisely that implementation
– written in C, in production on Sendmail – and the data I cite come
from its actual operation, not from theoretical speculation. It is also
the "draft implementation" you yourself encouraged me to try.
For me, MIME _is_ in the game. Many MTAs handle MIME in some ways.
E.g.
for 8BITMIME related transforms - or in mail analysis for spam
scoring etc. And I can tell
you, MIME is a beast, even when looking only on what's needed for
those transforms
MIME and RFC5322 are complex, but they are content the MTA has to handle
anyway. That is not an argument for adding JSON on top for header
changes, where a tag=value declaration does the same job.
I'd personally not hesitate to re-implement the needed JSON subset
parsing/generation
manually, with much less qualms than things like RFC5322 address
header parsing (harder
than you might think and also showing behavior differences between
implementations),
In a security protocol that is the concern, not the reassurance. If each
implementer writes their own subset, you get exactly the “parser
differentials” you'd want to avoid - divergent parsing of the same
input, which here is the vulnerability.
So let's stay realistic with "the internet is for everyone" and not
assume "everyone"
includes computing constraints from low- to mid-end consumer
hardware from more than a
decade ago (or the expectation that someone who arbitrarily limits
themselves to a small Z80
microcontroller would run an MTA specifically on that)?
The point was never vintage hardware - it was resource exhaustion under
volume. A flat tag=value parser drops malformed input with near-zero
allocation; a structured format has to build the object just to discover
the payload is garbage. On a 2GB VPS under a flood of malformed
messages, that is the difference - the "whose CPU" question, not a C64.
You talked about logging. Not about the original representation in
the mail. Or did
I misunderstand you?
I was of course also referring to the headers themselves -
self-descriptive headers are, for system administration, a form of
detailed logging that shows how the routing evolved.
(e.g. for assessing whose reputation you need to take into account)
I understood DKIM2 to be about moving past trust, that is what made it
interesting to me. Yet for two days now the discussion has kept
returning to trust: the null recipe (unavoidable, as I have been saying
for months) and now the asynchronous reputation assessment you mention.
For a model whose premise was evidence over trust, that is telling.
On header correlation, which you raise in your reply to Richard:
gathering is a protocol requirement, so a JSON solution has to correlate
the same data for the seal. But it correlates more, and worse: every hop
produces its own JSON recipe, so a verifier must load and reconcile all
of them in memory before it can check anything and there is no way to
work from only the relevant headers. This is presumably why the mainline
leans on light synchronous checks with heavier verification deferred to
an asynchronous back-end. A tag=value like DKIM2-Mod, by contrast, lets
me roll back one step to i-1 on the fly, checking that the predecessor
did not misdeclare its header changes, without preloading a tree of
recipes or pushing work downstream.
The envelope signature correlates the rt values by i= in both cases, and
the specification does not put rt in JSON (base64 tag=value, Section
8.6); that part is common ground.
I take your "not keen to revisit this" - fair enough. I'd only note that
"it would work" and "the base64 is an annoyance," in your own words, are
on the record as the case for the alternative. Whether it's revisited is
the WG's call.
Regards,
Vittorio
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
