Jon,
JK> Unfortunately, you actually said that the charter for the group was on
JK> "peer validation" whereas in fact the group is chartered to develop
JK> mechanism which may be used for this purpose.
"Primary use case" means that if it can't achieve that use, we have
not satisfied the charter. That's very different from saying "may".
"The solution chosen, however, should be generally useful for
others which might check this authorization data. "
JK> i.e. not limited to peers?
Not limited to USE by peers. Right.
This degree of indirection is the reason these schemes break valid and
useful scenarios.
JK> This is a concern in those schemes that "break" these historical uses. It's
JK> not clear that we mustn't develop a mechanism which allows schemes which
JK> use it to "break" whatever they want.
Breaking legitimate functionality of a system that has been in use for
30 years and is currently relied on by 1 billion people obligates
those doing the breaking to be very clear and careful about defining
and defending the breakage. That is not happening about this topic.
More generally, SMTP is a point-to-point protocol. Any attempt to
assign a level of trustworthiness to an MTA requires a chain-of-trust
model back to the originator.
JK> I don't really want to get involved in a *trust* argument, but this is
JK> patently untrue. This end might be achieved out-of-band.
This entire effort is about development of a trust mechanism, so it
will be rather crippling to avoid discussing the topic. "This end
might be achieved out-of-band."
Also, I do not understand what you mean by
JK> Please don't misunderstand me, I entirely agree that validating HELO
JK> would give some real benefit at little cost, and I'd agree that this group
JK> should support such an objective.
Well, that's a pretty solid common agreement, then.
JK> I do not believe that the group should
JK> "focus" on this to the exclusion of anything else.
This goes into the issue I raised about the dangers of not focusing.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>