Re: HELO/EHLO and applicability statement

I've been busy for the last couple of days and I'm attempting to catch
up now.

Alan DeKok wrote:
> 
>   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.

This sounds good to me.

>   The hope that people will use FQDN's is contentious, of course.  To

Most of the legitimate SMTP connections I see have had FQDNs in the EHLO
command.

> 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.

This is all true.

>   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.

How about the following alternative wording for the Abstract and
Introduction?

@@

Abstract

   The Designated Relays Inquiry Protocol, DRIP, is a method for domain
   name owners to specify the IP addresses that are authorized to relay
   mail as a domain name. The protocol provides a method for server MTAs
-   to reject SMTP connections from IP addresses not authorized to use a
+   to determine if the IP address of a client MTA is authorized to use a
   domain name.

@@

1. Introduction

   The Designated Relays Inquiry Protocol, DRIP, is a method for domain
   name owners to specify the IP addresses that are authorized to relay
   mail as a domain name in the SMTP HELO and EHLO commands. The
-   protocol provides a method for server MTAs to reject SMTP connections
-   from IP addresses not authorized to use the domain name given in the
-   SMTP HELO and EHLO commands.
+   protocol provides a method for server MTAs to determine if the IP
+   address of a client MTA is authorized to use the domain name given in
+   the SMTP HELO and EHLO commands

@@

The examples may also need to be tweaked.

>   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'm still thinking about the above and and may comment later.


Raymond S Brand