On Mon, Nov 24, 2008 at 09:24:15AM -0800, Dave CROCKER 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.
Oops, perhaps I did not make my point sufficiently unambiguous:
Authentication-Result: example.net; spf=pass
From: <A(_at_)example(_dot_)com>
To: <B(_at_)example(_dot_)net>
Message-Id: <C(_at_)example(_dot_)com>
Subject: mumble
Content-Type: multipart/mixed; boundary=b
--b
Content-Type: text/plain
See attached message
--b
Content-Type: message/rfc822
===>>>> Authentication-Result: example.net; spf=pass
From: DA(_at_)example(_dot_)com>
To: <E(_at_)example(_dot_)net>
Message-Id: <F(_at_)example(_dot_)com>
Subject: mumble2
This is the attached message
--b--
What is the meaning of the NESTED "Authentication-Result" header? It
can't be trusted, and should not be trusted when the nested message
is "extracted" from the containing message...
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...
No, I think this is a "Security Considerations" issue, not a
best-practices issue. I also think that if we discover that such a header
cannot be made reasonably forgery proof (too many ways to bypass forgery
filters) we should consider whether the header should be standardized...
I'd very much *like* to have a usable standard in this space, but it
needs to be reasonably robust, and if (perhaps) that is not possible,
I'll settle for "no standard" rather than a weak standard.
What the MUA does with a message and with meta-information about the
message is far outside the scope of this specification.
The standard is created for MUAs to consume, we need to consider real
world MUA use cases, to understand whether the standard holds up to real
world threats.
I am not entirely optimistic that MUAs will solve this problem.
Well, ok, one might therefore justify a doctoral thesis...
What is the point of this specification? Is it primarily for the benefit
of MUAs, or primarily for downstream MTAs and junk-mail filters?
If it is for MUAs, why are considerations of issues MUAs will face in
using the specification out of scope? If MUA issues are not tractable,
refocusing on mid-stream infrastructure may be more appropriate.
Once the standard is published, MUA developers may begin to implement
it without due consideration of all the issues.
It may, for example, be more appropriate for the header to be consumed
only by the mailstore (or MDA) and messages in the inbox flagged as
trusted by a separate store-specific mechanism. This would address the
"old message" issue, detaching of attached messages, ...
Sure, none of these trust/security issues change the format, but the
format lives in the context of implied use-cases, which should I think
be reasonably well understood.
--
Viktor.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html