[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-03-29 02:06:25

Tony Hansen wrote:
As yet, there has been no discussion on this issue.

Any comments?

        Tony Hansen

John C Klensin wrote:
Section 4.1.4, paragraph 6 (starting "An SMTP server MAY verify...")
discusses the use and validation of the domain name value in EHLO or
HELO.   It has been suggested that this discussion be strengthened by a
discussion of the conditions under which rejection for a bad EHLO
argument might be permitted.  That discussion would be explicitly tied
to the material about rejections in Section 7 (Security Considerations).

At least one argument against a change is that it would be hard to write
the needed text without promoting future arguments about situations that
are not covered.   Right now, the model is to describe one specific
reason why a message cannot be rejected based on an EHLO parameter, then
essentially invoke the rule that a server can reject a message for
virtually any reason, just because it isn't obligated to accept and
process mail.

Question: Is a change needed here, or is the text ok as is?

It is not ok in my view. I agree with Tony that the "MUST NOT" is ignored by most modern SMTP with strong "ANTI-ABUSE" considerations.

I would like to give an suggestion of a change in wording, but first
a small note that explains my thinking:

In my view, I think if we can better separate subjectives considerations versus hard-core SMTP technical considerations, this would have a profound effect in promoting discussions with direction and good potential for resolution and consensus. At the end of day, the final result should help current and future developers as well as administrators in getting a better grasp in their future designs and operations, respectively

That said, I don't think the document needs to say a word about ANTI-SPAM simply because at least 80% of all spams are primarily related to SMTP technical violations in one way or another most systems are ignoring or not enforcing - hence a major reason for the spam problem. So by simply providing more insight on technical compliance, this will be good enough for a majority of systems and operations to cover a key temporary concern and key problem we have today without breaking the traditional open spirit of the system. IOW, why I need 2821bis? How will it help me today?

Anyway, here is the suggested change (I am just winging it, and I strongly do not care how its taken, reworded, broken up, not used or whatever, I am just outlining the issue):

   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.

   If verification is implemented and offered to local policy
   definitions, it SHOULD primarily first consider EHLO command
   technical violations and it SHOULD have a strong
   consideration for legacy operations which may fail, for some
   unknown legitimate reason, the technical compliance requirement
   for the EHLO command.

   The EHLO command technical compliance includes one or more of
   the following considerations:

     - SHOULD: domain or IP syntax
     - SHOULD: Connection IP matching domain IP literal
     - MAY: A/PTR IP matching.

   Each implementation will be in a better position to decide how
   strong technical compliance will be or not be applied. For example,
   one operation may be less restrictive with his ESMTP AUTH end
   users, and more  restrictive with anonymous incoming remote mail.
   Subjective  considerations regarding technical compliance
   failures or ANTI-SPAM is out of scope, however, please see
   section 7.8 which  a more extensive discussion regarding
   incoming connections or mail messages rejections.

Anyway, something like that is what I see will be beneficial.