On Nov 24, 2008, at 11:59 AM, SM wrote:
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.
There are at least three trust elements involved when using this
header, such that:
a) the authserver-id identity represents the recipient's inbound
provider.
b) the authserver-id identity strips authentication-results headers
prior to adding theirs.
c) for Sender-ID or SPF, the email infrastructure supporting the
authorized MTA restricts the header field or envelope parameter use to
only the authorizing domain.
There might be a section to help establish a means to identify an
inbound provider's relationships to that of their authserver-id and
Received headers. Ideally, this relationship should not depend upon
extensions to imap or pop3. It seems reasonable to list possible
aliases within the header itself, and to recommend that imap or pop3
servers and headers be within the authserver-id or a listed alias
domain.
To support the trust element need for 'c', the authorized MTA would
need to ensure only accounts controlled by the authorizing domain are
able to include this domain within either the MailFrom or the PRA
header fields. It is common that MTAs authorized by SPF for the
MailFrom envelope parameter to not impose proprietary restrictions on
the use of the PRA. In many cases, such PRA restrictions would not be
practical. However, the authentication-results header provides no
assertions in which trust can be established for the essential element
'c'. A missing item needed to support the essential element 'c' is
whether the SPF record provided explicit indications that Sender-ID or
MailFrom is supported by the domain, since the Sender-ID specification
makes no distinction whether a pass is obtained from an SPF only
record. The lack of this type of assertion calls into question
whether it is reasonable to assume that an authorized MTA restricts
the use of the PRA or MailFrom to only the authorizing domain.
In addition, the authorized IP address of the SMTP client has been
omitted, although it is common that the trustworthiness of SMTP
clients be checked. The SMTP client's IP address represents the only
truly authenticated element for either SPF or Sender-ID. In addition,
there is nothing within the header to indicate whether the SMTP
client's reputation has been determined, for example whether the
reputation server timed out. A general assumption must then be
applied. Any message accepted is then assumed to be from a reputable
SMTP client, however there is no direct assertion made in the
Authentication-Results header in which trust might be based, nor is
there any safe means in which an MUA would be able to determine the
omitted IP address. You know what they say about guessing and
assuming...
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html