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
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.
NOTE WELL: This list operates according to