-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
il.com>, Emanuel Schorsch <[email protected]> writes
> As suggested in the interim meeting I put together some proposed
> language to clarify the forwarding/intermediary use-cases. First PR
> just updates the language to be more explicit around re-starting
> the chain and what "must not forward the message" means.
You suggest (inter alia):
For an invalid message, "the existing chain MUST NOT be continued
and the message sent to another system".
Previously it said the message "MUST NOT be sent to another
system".
if you send it to a DKIM2 aware system then that system will (most
likely) reject it because that system will see that it is invalid just
as you have. What is more they will probably ding YOUR reputation. What
value are you seeking to achieve here ?
If you say "but that other system is a friend of mine and will
understand" then that's not the "MUST NOT send to strangers" that the
current language seeks to establish as the rule.
The second part of the spec-07 edit is:
A system that starts a new Chain of Custody "becomes the Originator
of the message". This makes it explicit that the From header must
be Authentic for that system.
I think it already is quite explicit.
When the From header field has not been altered since the message
was signed for the very first time, i.e. when the i=1
DKIM2-Signature field was created, then that From and that
DKIM2-Signature are the relevant header fields for the comparison.
There is only ever one chain of custody -- you don't get to keep the
previous DKIM header fields. To put it another way the Originator is the
system that adds m=1 and i=1. No-one cares (see another long running
discussion) about the history of the message before you decided that you
wanted to DKIM2 sign it when (apparently) no-one has signed it before
> The second
> PR defines body-authentic so we have shared language and definition
> around the modifying without munging case. It does not define any
> handling based on the case but this will allow us to have the
> discussion around updating DMARC with a clear definition.
I take the point that having a definition is useful for discussion, but
I don't think a spec is the right place for it if all that is described
is how to establish that the message is in that state. If everything
that rests on the definition is "local policy" then the definition is
"local policy" as well.
Now if you said "you can only change the body if you change the From and
doing otherwise stops the message from being a "Validly Signed DKIM2
Message" then that would be something for the spec (but you probably
have to say that no-one can change the From again to make it work...)
> Note,
> that it does ignore changes to the Subject, which seems okay since
> those are less likely to generate phishing risks.
if you are going toward "these changes are OK and nothing else is
acceptable" then you are heading towards my suggestion of a header field
that is "You-Can-Modify-This-But-Nowt-Else: <parameters>"
- --
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/AwUBatloUWHfC/FfW545EQIQZACcC9R8yKttOXRjn0HcGHlTltzZ410Anixh
1McMCa7+8PxU89pi2dK/RUl4
=Ied+
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
