At 07:43 24-11-2008, 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.
Section 4.1 of the draft talks about header position and interpretation. As it's treated as a trace header field, it should not be trusted if it's a message/rfc822 part. It's similar to the concept we apply to Received headers where we only trust the header injected by our MTA.
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.
Once the message hits the mailstore, we cannot predict what will happen there. If we want to put in some guidance, it would be in a draft about POP3 and IMAP where a discussion about mailstore may be more relevant.
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, ...).
That would be interaction with the mailstore. You are looking at this header as attaching a trust assertion to the message instead of a way for the MUA to receive the results from an upstream MTA that perform the tests.
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.
That's only an issue of you start assigning trust on message/rfc822 parts instead of the channel through which the information is being received.
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.
That sounds more like a consideration for an IMAP draft. At 10:02 24-11-2008, Victor Duchovni wrote:
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...
if you want the header to be reasonably forgery proof, you can sign it with DKIM (Section 8.1).
What is the point of this specification? Is it primarily for the benefit of MUAs, or primarily for downstream MTAs and junk-mail filters?
It's for both MUAs and downstream filters. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html