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.
With respect, the group is chartered "to develop a DNS-based
mechanism for storing and distributing information" to support MTA
authorization, and "the solution chosen should be generally usable for MTA
authorization". Unfortunately, HELO needn't be at all correlated with the
sending of mail "on behalf of a specific domain or network" (except perhaps
at the origin MTA). Indeed, HELO isn't an attribute of the mail at all, so
while it's unlikely to break anything much, it's probably going to be of
very little value in achieving the groups charter objective.
A proposal to focus on HELO seems to me to be little more than a spoiler,
and to have rather more to do with politics than engineering.
I'm aware that there's a school of though which holds that we should "first
do no harm". I'm not sure that such a strongly conservative position is
what we need.
Regards,
JK