John R. Levine wrote:
---------- Forwarded message ----------
Assuming we agree that the verifier does not, in fact,
create an edited message, none of them should be contentious:
I don't agree a verifier create edited messages but it should be
recognized it may reasonable to suggest it does based on the idea it
can add a DKIM related trace header (Authentication-Result). But to
me, that would be just another trace header like all others.
3.4.5, first INFORMATIVE IMPLEMENTATION NOTE, last sentence:
delete "or remove text that appears after the specified content
length" since verifiers do not produce an edited message.
If the concern is Verifier Edited text, then this will promote it. So
+1 on that regard. But I think the security design point is
important and might be restated in another way.
First, I don't think the verifier SHOULD ignore the tag without
additional insight. For example, it MAY ignore it for non-mailing
list streams since list streams is really the one of the main
motivations for l=.
Second, an MUA or Message Display Renderer could be better candidates
to hiding (not display) the text after l= length. MUAs already do
hiding of some form or another. A suggestion to focus on this angle
might be better than just removing this security insight.
3.5, l= tag, INFORMATIVE IMPLEMENTATION WARNING, remove "or
remove text that appears after the specified content length"
since verifiers don't produce an edited message.
Same as above.
6.1.3, next to last paragraph, remove "by truncating the message at the
indicated body length" since verifiers do not create an edited message.
Same as above.
6.3, remove next to last pp, "The verifier MAY treat unsigned
header fields with extreme skepticism, including marking them as
untrusted or even deleting them before display to the end user."
+1. I think maybe "deleting" would be the offending term as mail
receivers are not in the (expected) practice of tampering with mail
which deleting would imply is possible. "Hiding" is the more
appropriate term.
That's both because the verifier doesn't create an edited message,
and because verifiers don't treat any field with any degree of
scepticism. They take what they get.
+1, we keep forgetting that ultimately MUAs (online or offline) will
need to designed/updated to handle what verifiers produce and imported
to the mail storage. But there also the possibility to better support
legacy offline MUAs, the MTA can (and many systems do) take "editing"
action.
But I agree I don't think its the DKIM verifiers job to "edit
messages." It might be but it shouldn't the main scope for DKIM verifiers.
6.3, last sentence: "should be rendered" -> "should be treated"
+1
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html