Hi, John!
[No need to CC me, I'm on the list]
On 8/12/26 19:09, John Levine wrote:
It appears that Hannah Stern<[email protected]> said:
The draft says:
If a verifier receives a message with a donotexplode request and
a later hop has indicated that it has exploded the message then
the message SHOULD be rejected.
So according to how I'd plainly read it, the verifier would only check
if any subsequent hop has the "exploded" flag.
However, what if a hop explodes the message without setting the flag?
I think donotexpode is advice to cooperative signers since as you note,
there's no way for subsequent signers to check. I'd think that if a
mailing list implements DKIM2, it would reject or at least hold for a
moderator anything with donotexplode.
Yeah. So a verifier should, as the spec, just check the exploded flag in
subsequent hops, catching half compliant hops (complying with declaring
exploded, but not compliant with the requirement to not explode
donotexplode mails).
With the general approach in other areas of DKIM2 (make things
verifyable through the chain), I'm a bit suprised that here we might
specify something that's harder to impossible for a verifier to check
(only with a database about multiple copies one receives, best with
inter-site cooperation like sites exchanging data about how often a site
received which DKIM2-Signature line (e.g. hashed)).
For "donotmodify" it's specified that header fields may be added still.
If the recipes were optimal, that would mean that there are only "c"
entries. However, if a site reorders existing fields, it would need to
use "d" at least somewhat (due to the monotonicity requirement on copy
rules), and of course if a site is extra simplistic it might use "d"
even when "c" would work. So in the end we'd possibly need to create a
set of fields in the new version, and for each header field in the old
version, check if it's in the new set? Or how would you implement that?
That does seem ugly, doesn't it? On the other hand, I'd think that it
wouldn't be hard to keep the new headers or maybe a set of hashes, and
check them after the changes are undone.
Yeah. For now I implemented a check if, for each field key in the older
header (reconstructed through recipes), the field values are an
_ordered_ subset of the corresponding values in the newer header
(allowing for differences that don't affect canonicalization). But
possibly that's not correct and I'd need to check for _unordered_
subset/sub-bag (not allowing the count of occurrences of the _same_
field value to decrease).
Perhaps the approach of comparing bags of (hashes of) canonicalized
field values could be better.
IMO the draft is a little under-specified here, still.
R's,
John
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]
