The value in focusing on MTA.Helo is that the field is localized
between the peer MTAs and validating that field provides an
incremental basis for stable, trusted Internet mail infrastructure
operation. The charter for this group is on peer validation.
JK> With respect, the group is chartered "to develop a DNS-based
JK> mechanism for storing and distributing information" to support MTA
JK> authorization,
You seem to be quoting text that is different from the charter. I'll
also note that adding text outside of the quotation marks can rather
substantially change the meaning of an apparent quotation.
The exact text from the charter is:
"This working group will develop a DNS-based mechanism for
storing and distributing information associated with that
authorization."
Happily, I did not say or suggest anything that contradicts this.
Unfortunately, you actually said that the charter for the group was on
"peer validation" whereas in fact the group is chartered to develop
mechanism which may be used for this purpose.
I suspect this is an important distinction.
JK> and "the solution chosen should be generally usable for MTA
JK> authorization".
The actual text in the charter is:
"The solution chosen, however, should be generally useful for
others which might check this authorization data. "
i.e. not limited to peers?
Again, I did not say or intend anything to contradict this.
My apologies, I misunderstood you.
JK> sending of mail "on behalf of a specific domain or network" (except
perhaps
JK> at the origin MTA).
Where does the phrase "on behalf of" occur in the charter?
Apologies for inadvertently letting a bit of the draft (I think) charter
sneak in (insert weak excuse here).
This degree of indirection is the reason these schemes break valid and
useful scenarios.
This is a concern in those schemes that "break" these historical uses. It's
not clear that we mustn't develop a mechanism which allows schemes which
use it to "break" whatever they want.
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.
I don't really want to get involved in a *trust* argument, but this is
patently untrue. This end might be achieved out-of-band.
Please don't misunderstand me, I entirely agree that validating HELO
would give some real benefit at little cost, and I'd agree that this group
should support such an objective. I do not believe that the group should
"focus" on this to the exclusion of anything else. I think it would be very
unwise to exclude any of the suggested "identities". Perhaps you'd confirm
that your suggestion to "focus" on HELO doesn't carry with it a
recommendation that other identities should be out of scope.
Regards,
JK