On Dec 2, 2008, at 1:25 PM, Dave CROCKER wrote:
The job of this spec is to carry information on behalf of validation
modules. It is not the job of this spec to change or enforce
policies for or about those modules.
Unfortunately, this header employs phrases and terms that will have
significant meaning to layman. In addition, this header fails to:
a) relay the authorized IP address of the SMTP client while reporting
path registrations; essential for vetting the source.
b) how path registration records relate to the associated header field
or parameter.
c) the reputational vetting of the authorized or authenticated
identifier.
In the case of path registration, the job of this header appears best
suited to sell the lie that path registration's authorization
represents authentication. This is a dangerous lie. While the sky is
not falling, people will be injured.
Scott Kitterman argued that additional information may confuse
recipients, which assumes occasions where recipients examine otherwise
seldom displayed headers. In response to the concern that these
phrases and terms misrepresent nature of the checks made, Charles
Lindsey insisted this information determines the authentic origin of
the message. Murray argued this header makes no value assertion about
the results conveyed from border MTAs, although the header neglects to
include critical information for vetting the source, while using
extremely misleading phrases and terms.
Large email providers have an incentive to have their services trusted
(even more than they should be when blame can be deflected). The
cases where path registration may result in an inappropriate level of
trust remains dependent upon the amount of exploitation that takes
advantage of the difference between authorization and authentication.
Ensuring a network path only contains identifiers emitted from
accounts controlled by the authorizing domain is not practical in many
cases. When the difference between authorized and authenticated
becomes exploited, there may not be a practical response to problem.
After all, this header is added by a third-party likely unaware of the
problem, and perhaps feels their sloppy assumptions are protected when
they follow the language of an irresponsible RFC. Since the resulting
problem will be due to authorization and not authentication, it
remains easy for large providers to deflect responsibility, especially
if this draft remains unchanged. They will simply insist that all
commerce should operate over networks that restrict MailFrom and PRA
identifiers to accounts controlled by the authorizing domains.
Even assuming one could put into place mechanisms able to meet the
assumption of authorization representing authentication, will this
practical in the face of more diversified and translated IP address
space, and a profusion of compromised systems? It is not hard to
understand why large providers do not wish to touch the issue of
compromised systems, but these compromised systems represent a clear
and present danger. Not including the IP address of the authorized
SMTP client fails to acknowledge this reality. This oversight will
prove to be extremely detrimental.
It is entirely reasonable to provide additional reporting values, to
allow modules to report what they deem appropriate. Something
squishy like 'neutral' is a good example. Providing that option, as
a canonical choice, is fine.
It would be better to label this header "border-check", and have it
include numeric codes and values for the relayed results. This would
be a safer means to avoid the issues that you and I have raised.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html