Hi!
On 9/10/26 22:27, Vittorio wrote:
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.
No. I'm asking for a description of _actual_ problems with the mainline
drafts that would ask for an alternative in the first place.
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.
You mean the draft implementation of the _mainline_ draft I asked for?
(Like not to show to me but to check for yourself if your fears about
the mainline drafts is justified.)
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.
It doesn't. People working on the mainline drafts/their predecessors
proved that.
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.
What _vulnerability_? I don't see a potential exploit if someone is too
strict, "just" an interoperability issue that would be sorted out early
enough.
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.
Not true. Only a naive implementation will (attempt to) build the object
first. It _is_ possible to write a streaming validator for recipe
syntax. Just probably for most it'll not be worth it because JSON
implementations are actually quite fast.
On a 2GB VPS under a flood of malformed messages, that is the
difference - the "whose CPU" question, not a C64.
People would probably rather DDoS your DNS client than manage to DDoS a
JSON parser. Even under 2GB VPS constraints.
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.
To me it looks as if you might be playing pigeon chess around these
issues. Or FUD.
People repeatedly described the situations under which null body recipes
make sense (with pre-established trust) and that otherwise, their use
will probably imply much lower trust than hops that don't opt out of
describing their changes.
Which is acceptable. Because destructive body cleaning doesn't make
sense except if close to sender (a solution for that has been described,
involving the security solution signing on behalf of the sender, perhaps
involving nd) or close to the recipient (and then the recipient knows
that _that_ particular signing domain is trusted to make null body
recipes after verifying the mail beforehand).
"asynchronous reputation assessment" I mentioned that only as one
possible approach if someone is really in fear of synchronous
verification. Actually even with synchronous verification there will be
more and more asynchronous assessment for completely unrelated reasons
that are not the fault of DKIM2, DKIM, DMARC, SPF or whatever. Because
giving oneself some more time to assess a mail allows more information
(e.g. patterns from other mails received since) to enter spam/...
classification.
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.
I don't know what you're referring to. "Seal"? "Correlate the same data"?
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
So what?
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.
I didn't see it "leaning" towards that. The mainline offers that
possibility by ensuring asynchronous bounceability even with shallow
checks. But I haven't seen it "leaning" towards asynchronous work. As
said, we here will probably do most if not all synchronously, and easily.
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.
If I want to rewind _one_ step in "mainline" I also have to consider
only the r= on the latest (not all) Message-Instance. No need to
"preload" all for that.
[...]
Hannah.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr.
Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt,
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
