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.
So perhaps MUA authors could benefit from explicit guidance to not assign
meaning to such headers found in nested messages.
Since nested messages can and often are saved to external storage,
and then opened as stand-alone messages, one should perhaps also be
suspicious of messages not stored in the user's mailbox.
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, ...).
Messages (that have Authentication-Result headers) may of course also
be found in NTTP posts, HTTP downloads, an so on. It is like difficult
to close down all the side-channels which bypass the scrutiny of MTAs
that remove forged Authentication-Result headers.
The MUA has to carefully track which messages were delivered as
top-level entities into the Inbox, and which arose by other means,
and must maintain a clear separation between the two, stripping
Authentication-Result headers when messages cross the boundary
between the two trust realms.
I am not entirely optimistic that MUAs will solve this problem.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAIL Morgan Stanley confidentiality or privilege,
and use is prohibited.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html