John R Levine writes: > > Personally, I would expect that, when donotmodify is absent, the > > default behaviour should be equivalent to donotmodify=yes. > > I don't think anyone else would. > > > Is that already the intended interpretation? If not, would it make > > sense to consider this as the default behaviour? > > No. No.
Agree on John in this. To think it like this, the sender has sent the message, whatever happens to that message after it has left his system is not of his concern. If the recient of the email wants to modify the email he will, regardless what the sender "asked/hinted". There is nothing sender can do for that. > The point of DKIM2 is to track the changes to messages on the way > from originator to final delivery. DKIM2 will allow recipient to keep track of those changes. Before DKIM2 usually you would need to have specific trust relationship with the system that changed the message and the final mailbox, as changing the message will break DKIM1 signatures etc, thus you want to make sure those are checked before the email is changed (for example security gateway before the corporate mail box service). ARC can provide proof that those checks were done on middle box, but it does not provide the trust relationship, that has to come from outside. In the DKIM2 it will be same, even if we know that example.com did modify the message as specified in the DKIM2 diff, we have no idea whether that change was authorized or not. Only the end user really knows or can give information to the his mail box provider what kind of changes he/she will authorize to be done on the email. Thats why I think the donotmodify is completely wrong term for this, as it does not indicate anything from the sender side, it tries to give hint to the recipient side what kind of message this email is, but even then it does not do that well. > There are certainly categories of messages where donobodify makes > sense, e.g., password resets, but the people who send those messages > should know that so they can mark them. Why would the password reset be one of such message? I could easily see that security gateways might actually want to specifically flag the password resets as special security sensetive emails, so that recipient will understand that clicking that link that should not be there can be dangerous. If the security gateway removes the link as security risk, that is decision it did to protect the user, and hopefully that operation was authorized by the user. And it should do that even when the phisher has put donotmodify flag on... -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
