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