On Mon, Nov 24, 2008 at 11:58:46AM -0800, Michael Thomas wrote:
Yeah, definitely a security considerations if anything. But isn't this
pretty much covered by the overall "don't trust what you don't trust"
part of the security considerations already?
No, because the MUA will in fact trust the header (when it carries the
right "authserv-id". Otherwise it is completely useless to the MUA.
My point is that the assumption that forged headers are stripped by the
trusted MTAs along the delivery path is not robust. Attached messages
are not so scrutnized, and MUAs will often display these (when users
open attachments) or will detach them from the main message entirely.
If the MUA uses the header to apply a different policy to trusted messages
(even as mundane as status signalling in "chrome"), then nested messages
and detached messages are an issue.
I do not wish to be a troll, so unless my point is not clear, I don't
want to repeat myself. Having made the point about as well as I can,
if it is broadly believed to be out of scope, so be it.
IMHO, this issue deserves specific discussion in the Security
Considerations, because, while it is not deep, it is not entirely obvious.
--
Viktor.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html