-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
il.com>, Wei Chuang <[email protected]> writes
> What could be done instead is that senders like the IRS with high
> security requirements could mark their messages with the DKIM2 flag
> "donotmodify" which says "this signer requests that the message not
> be modified from the form in which it is sent". One issue here is
> that the DKIM2 draft does not fully specify what is meant by not
> being modified. Is the prohibition only the body or does the
> headers also? If the latter, which header fields are protected?
> Would that be Subject, From, To, Cc, and other RFC5322 originator
> and destination fields? Receivers that see modified messages
> marked with the flag indicating "donotmodify" ought to lookup the
> DMARC policy of the signing domain, and apply the enforcement
> policy published there.
I agree that the spec should indicate what donotmodify means. I have
added some text to the document to say that it means that the body is
not modified in any way and that the only changes to header fields
permitted is addition (ie no replacement or removal).
That does mean that fields with security properties (such as Reply-To)
might be added to a message that does not have such a field; however the
security property can only be known to the receiver and such a receiver
can take the view that adding headers that they care about is
unacceptable.
I don't think it is practical to make a list of fields with security
properties to the spec ... but Todd's document might like to discuss
likely candidates (viz what a receiver might wish to check for)
> I also agree that there needs to be more clarify around null
> recipes and their scoping. One thing that is said around
> "donotmodify" is that "A system that, by local policy, ignores this
> request MUST NOT allow the message to be forwarded on to any MTA
> outside its control." There should be similar language for systems
> that use null policies.
by null policies I think you mean p=none. I don't think the DKIM2 spec
is the correct place for such a discussion.
> I propose that the specification or BCP should say that MTAs that
> need to forward such null recipe, "donotmodify" or "donotexplode"
> messages onwards for whatever reasons, should delete all prior
> DKIM2 headers and re-sign the DKIM2 signature as themselves. This
> probably means that the above language needs to be tweaked for
> this.
That is not good advice for "donotexplode" !
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBagnRtWHfC/FfW545EQJQyQCg1bkIYgw6fF2RDztKQZPNTlI4qGcAniAq
NMnAeGXz1BXWTgPEX80AWFmt
=JGOm
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
