Jon,
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.
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. "
Again, I did not say or intend anything to contradict this.
JK> Unfortunately, HELO needn't be at all correlated with the
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?
But let's skip that issue and move to the core of your concern.
The current reality is that none of the identity fields in question
"need" to be correlated with much of anything. The goal of efforts
like this working group is to provide mechanisms that create and
enforce some type of correlation.
MTA.MailFrom is a field set by the identity specified in Msg.Sender
and designated where transmission-level return notices should go.
Hence, this MTA-level address is specified by a message-level
identity, an arbitrary number of hops earlier in the sequence.
Further, the proposals for MTA.MailFrom validation all tie the peer
MTA authorization with the originator Sender (or From, but we can
debate that distinction separately.)
This degree of indirection is the reason these schemes break valid and
useful scenarios.
The MTA.Helo construct is an assertion of the domain name associated
with the peer MTA. A mechanism that validates that domain name
provides a basis for an authorization (acceptability) mechanism,
associated with the owner of the domain. Whether that validation, in
turn, ties the domain name to the IP network address of the peer
network is a test of the scheme proposing to validate MTA.Helo. (For
reference, my own proposal does not yet achieve this; it's a goal but
it hasn't achieved it yet.)
JK> Indeed, HELO isn't an attribute of the mail at all, so
JK> while it's unlikely to break anything much, it's probably going to be of
JK> very little value in achieving the groups charter objective.
Rogue MTAs (eg, compromised systems) are a very serious problem,
considerably beyond bad bounce addresses. Validating that a machine
is authorized by its hosting network to act as an MTA would do quite a
bit to improve the basis for trusting that an MTA is well-behaved.
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. A chain is built in terms of its links.
Validating the acceptability of the peer MTA.Helo is the basis for
building that chain.
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>