Victor, Victor Duchovni wrote:
I wanted to raise another issue. Should there be any discussion of the semantics of "Authentication-Result" for message/rfc822 attachments (nested messages). Clearly such headers cannot be assumed to be filtered at the MTA layer and should be presumed untrusted.
I think you are trying to carry the semantics of the authentication that this covers too far. For example, I believe this mechanism is not intended for personal or fine-grained authentication, as done by OpenPGP or S/Mime. One can imagine extending it, but Whether the body -- in its entirety -- is authenticated explicitly depends upon the semantics of the particular authentication technique. The specification provides for some parameters that might be used to this end, but the details in this way is not in this initial specification, nor should it be, in my opinion. The specification's primary goal is to pass a single, overall results value. Everything after that is far more subtle than needed for its initial use.
So perhaps MUA authors could benefit from explicit guidance to not assign meaning to such headers found in nested messages.
This specification is not prescriptive with respect to what should be done with the parametric information that is passed. I suspect you are looking more for some sort of broader 'best practices' document about the ways authentication information passed to an MUA should be used. It will probably be best to wait until there are some real-world practices, before deciding which are best...
And finally, the bad news does not stop there, users can and do move mail items between the desktop the mail-store, so in the final analysis, the header cannot be trusted unless the MUA discards it from attached messages when separating a nested message from its containing top-level message (save to disk, save to mail folder, display as a separate message, ...).
What the MUA does with a message and with meta-information about the message is far outside the scope of this specification. More generally, you are discussing the issue of trust and the document already has the limited discussion of that that is needed, for this specification. It's not that your concerns aren't legitimate, its that they go beyond the scope of this document. One could imagine a nice masters thesis about trust issues for a message as it is moved around, across architectural models and even across services.
I am not entirely optimistic that MUAs will solve this problem.
Well, ok, one might therefore justify a doctoral thesis... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html