HELO/EHLO and applicability statement

  I'd like to put out the following statement for consideration, as a
definition of the problem space we're trying to address via DNS
lookups on the text in HELO/EHLO.


	<The solution> is applicable only to the text in the argument
	field of the HELO [RFC 821] and EHLO [RFC 2821] commands.
	Further, the solution is applicable only when that argument
	field is a fully qualified domain name.  <The solution> does
	not address or change the current practices and standards of
	HELO/EHLO when the argument field is an address literal, or
	when the argument field is not a fully qualified domain name.


  This statement should narrow the scope of the problem, and define
many objections to be out of scope of the solution.  Spammers may
still use non-FQDN's, or address literals, but the hope is that most
"honest" people will use FQDN's.  This is known as the "no shirt, no
shoes, no service" attitude towards SMTP.

  The hope that people will use FQDN's is contentious, of course.  To
address that issue further, I propose the following statement on the
use of the solution:


	<The solution> does not define an Internet Standard for
	establishing consent for the exchange of messages via SMTP.
	Instead, it defines a standard method for a domain to publish
	statements about MTA's which originate messages, and a
	standard method for recipient MTA's to query those published
	statements.  Consent is established by applying local policy
	to the communications request, using the information available
	(or the lack of it) about those messages.  Local policy, and
	therefore consent, is explicitly outside of the scope of <the
	solution.>


  That is, no one is forced to use the proposal, and no one is
punished for not using it.  MTA's are perfectly free to use non-FQDN's
or address literals in HELO/HELO.  This proposal simply allows people
to publish, or to discover, additional information if they so choose.

  For example, in Section 1, the DRIP proposal says:

	The protocol provides a method for server MTAs to reject SMTP
	connections from IP addresses not authorized to use the domain
	name ...

  I beleive that such statements are inflamatory to a large group of
people.  The implication for many people is that the proposal will
REQUIRE MTA's to reject such SMTP connections, even though that was
not the intent of the proposal.

  In contrast, in Section 1, the SPF proposal says:

	SMTP servers and Mail Delivery Agents may choose to test
	incoming email according to the technical specification
	defined in this proposal and to accept, classify, discard, or
	reject messages on the basis of that test.


  We need to be excruciatingly clear that the proposals do NOT
standardize a method for rejecting messages.  Instead, they propose a
method by which MTA's can gain more information about the message, in
order to make more fully-informed decisions.  The decision to
rejecting or accepting the message should be explicitly outside of the
scope of the proposal.

  I've put some initial comments on this subject on the web at:

	http://striker.ottawa.on.ca/~aland/asrg-rmx/helo.html

  Alan DeKok.