Doug, I think I figured out where you took a left turn and came to the
wrong conclusions about the Authentication-Results header.
The Authentication-Results header indicates the results of *us* proving
the authenticity of something in the message. In other words, *we've*
authenticated the DKIM and DK signatures, and we're communicating *our*
authentication results to our MUAs.
We are *not* communicating whether that original token was an
authentication or authorization of anything. We are only communicating
what we've proven. We're providing the results of *our* authentication
process.
Tony Hansen
tony(_at_)att(_dot_)com
Main Entry: au·then·ti·cate
Function: transitive verb
Date: 1652
: to prove or serve to prove the authenticity of <authenticate a document>
Douglas Otis wrote:
On Oct 24, 2008, at 1:59 PM, Tony Hansen wrote:
I know that for us, if the name of the header were to change at this
late time, we would *NOT* be able to change our implementation to
match for probably another 6-12 months.
So personally, here's a -1 for making such a change at this time.
Describing these SPF/Sender-ID results as "authentication" will mean
domains publishing SPF records are now in jeopardy of dangerously
misleading recipients whenever a shared outbound server is employed
somewhere. The risk will become painfully apparent whenever a bad
actor's only "authentication" credential is having sent email through
one of the authorized SMTP clients. There are _many_ cases where
independent domains share a common outbound server. While path
registration may help reduce a range of spoofed DSNs, it is NEVER safe
to refer to this mechanism as an AUTHENTICATION method. This is not the
first time that this concern has been raised. A correction now should
be preferred over a change at a much later date. It is shameful to be
sloppy about something that will prove _extremely_ misleading.
AUTHENTICATION-RESULTS: my-trusted-isp.com; sender-id=pass
header(_dot_)from=jon-doe(_at_)e-commerce-are-us(_dot_)com
Someone reading this header added by their trusted ISP will logically
come to a horribly wrong conclusion. They are likely to believe that
the email-address "jon-doe(_at_)e-commerce-are-us(_dot_)com" had been
authenticated. Despite the outrageously misleading header label, the
information contained within the header only indicates that the SMTP
client had been authorized. An authorized SMTP client must not be
misrepresented as providing an assurance of the authenticity of the
email-address! Why make it so damn easy for con-artists?
It would be ludicrous to suggest that all domains should not use shared
outbound servers, or that all outbound severs should authenticate the
use of every email-address within a PRA location.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html