On Nov 2, 2008, at 1:42 PM, Dave CROCKER wrote:
Murray S. Kucherawy wrote:
Michael Adkins wrote:
I think I asked my other AOL contact about this once and he said he
could see them switching to using the proposed header field, but
there's no hurry to do so.
(...meaning you came up with the same idea)
For reference, I think this datum on AOL is completely supportive of
the current effort, by virtue of providing proof of concept. Hence
the current work "merely" standardizes existing practice.
I've heard rumors, over the years, that the IETF believes in doing
that...
Standardizing on border-check header results is of importance only for
path registration schemes. These headers reduce the security obtained
by signature based schemes since these border-check headers depend
heavily upon uncertain handling given the new headers when entering an
administrative boundary. In addition, bad actors are rather notorious
at obtaining access to MTAs internal to an administrative domain. A
further reduction in security has been created by the choice of the
header-label and the method states. The label and states are well
designed to MISLEAD users into believing that an email-address had
been AUTHENTICATED when it has not!
Pretending to offer authentication is far worse than just using
existing trace headers. There is no way to know whether restrictions
were placed upon the use of the specific MailFrom, PRA, or From
headers by intervening and perhaps authorized MTAs. A path
registration scheme based upon SMTP client authorizations never
provides a means to verify the origin of a message. This can never
happen unless drastic changes are made with respect to what is legally
permitted within these various header fields along with the
commiserate mechanisms to enforce these new regulations. Do you see
that as ever happening?
In its current form as defined, this header is evil. It will lead to
more recipients being duped by confidence artists that will be able to
exploit an incredibly weak authorization scheme.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html