On Wed, Dec 17, 2008 at 06:24:16PM -0800, Douglas Otis wrote:
Not listing this information borders on negligence.
Or perhaps repeating this information ad nauseam borders on fanaticism.
The Authentication *Results* header communicates the *Results* of
various mechanisms that determine the domain which is responsible for
sending a particular message. While we can quibble over whether these
are Authentication or Authorization results (and I might even agree with
you that the latter fits better), this is largely irrelevant, either way
the mechanism attempts to determine the responsible domain and adds the
results to a header, and downstream filters can use this information to
make decisions.
When one trusts the responsible domain (if one is provided by via the
A-R header) in some fashion (say to not send you spam), one grants the
responsible domain greater access (say bypass CPU intensive and FP-prone
filters). Within this limited security model it does not matter that a
strict notion of "authenticity" cannot be inferred from the A-R header.
If you must have message authenticity, use (with care) S/MIME or PGP.
If you want to allow receiving systems to separate determination of
the responsible domain from acting on the reputation of that domain,
standardize a header that records this domain.
Must we change the header name to
This-Is-Not-Authentication-Just-A-Determination-Of-The-Responsible-Domain:
in order to discourage misuse?
It would I think be more productive to move beyond the header name
(or fixation on authentication vs. authorization in SPF/SID, as the
same observations also apply to Domain Keys and DKIM) and suggest any
necessary improvements to the draft that clarify the security model.
There are however snakes in that pit. The question of whether email
"authentication" (i.e. DKIM, SPF, ...) will/won't/must/mustn't solve
"phishing" remains unresolved with strong views on each side. If the
draft takes sides in this "debate" (cream-pie throwing contest?), it
may never see the light of day.
I am reconciled to the fact that some will abuse the header to colour
the MUA chrome to suggest that the user is looking at a genuine message:
good enough to enter your bank-account password into a web-form referenced
in a link from the message. I hold that this would be a misguided use
of the A-R header, but I don't think I can win this argument yet. We
just need to wait a decade or more and see how A-R is used with the
benefit of hindsight.
--
Viktor.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html