On Mon, Jun 29, 2026, at 09:29, Hannah Stern wrote:
>>> - Is it allowed to have more than one nd in a row? (I.e. i=4 has
>>> nd=<domain of i=5>, i=5 has nd=<domain of i=6>)?
>>
>> Yes, no reason why not to. Again, so long as all these domains have
>> contractural agreements.
>>
> As verifier I don't know about contractual agreements of earlier hops though.
You don't need to. Hop i+1 needs to know about its own contractural agreement
with hop i. If it chooses to accept a messages with nd= then either it has a
contractural agreement or it's taking the risk of replay to it and the
associated reputation hit that IT will take for turning one original message
into millions of new messages.
All you need to know as a verifier is whether you're looking at the top hop.
If you are and it's a nd= hop, then you'd better have a configuration option
telling you to trust it; otherwise it's bogus. If it's not the top hop, then
you just follow it for the linkage check.
>>> - How is the mf/rt chain checked in the presence of nd? Just skip the nd
>>> hop? I.e. if i=4 has mf/rt, i=5 has nd, i=6 has mf=rt, do I check i=6
>>> against i=4 using the usual rules?
>>
>> No, you never skip over a hop. You check:
>
>> i=4 rt=foo@X
>> i=5 d=X; nd=Y
>> i=6 d=Y; mf=bar@Y
> (Reformatted, your formatting gave me white on white in my message
> composition editor.)
>
>> Those are the invariants which must pass.
> They look much stricter than the usual checks.
>
> If i=5 where a "normal" intermediate signature,
>
> - i=6 the mf domain would be allowed to be a subdomain of the d domain
>
> - The i=4 rt domain would be only very loosely related to the i=5 d domain
> (indirectly via the i=5 mf domain) Basically i=5 mf could be any subdomain of
> i=5 d, and i=4 rt domain could be any "super"domain (suffix) of that. That
> is, i=4 rt can be either the same as i=5 d, or one a subdomain of the other
> (this way or the other way)!
>
> And once, we'd adjust for that, I'm not sure what we gain from nd over just
> having some synthesized/fictitious mf/rt on i=5 instead of nd.
>
> I.e. i=5 d=X mf=fictitious@X rt=fictitious@Y
>
Yes, that was indeed the discussion. The point of nd= rather than fictitious
part was to make it clear that the same party (or: related parties that can be
treated as the same) was creating both signatures.
>> [...]
> By the way, I see this change:
>
> All relevant DKIM2-Signature header fields (and Message-Instance
> -header fields if the message body is supplied) MUST verify. The
> -DSN itself MUST have appropriate Message-Instance and DKIM2-Signature
> -fields, noting that the MAIL FROM to be used will be null ("<>").
> +header fields if the message body is supplied) MUST verify.
>
> Shouldn't the Message-Instance of the original mail be verifiable too, even
> if no body is provided, at least for headers?
>
I'll defer to Richard on that. It seems reasonable to me.
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]
