[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-03-29 05:46:23

--On Thursday, 29 March, 2007 04:52 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

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

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"

Tony's suggestion to move from MUST NOT to SHOULD NOT would
certainly be consistent with changes we could make at this point
(this isn't endorsement, just an observation).

I would like to give an suggestion of a change in wording, but
a small note that explains my thinking:
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

Some comments, here and below, to clarify what is being
suggested (I have no real opinion about possible changes yet)...

We all understand that anything resembling a syntax error in the
EHLO argument (i.e., not meeting the syntax requirements for a
domain name) is an error that lies completely outside the
existing restriction on rejection, don't we?

Does that need to be more explicit?

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

Again, for clarification, you mean "one of the IP addresses
of...", don't you?

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

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

      - SHOULD: domain or IP syntax

See above.

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

    Each implementation will be in a better position to decide
    strong technical compliance will be or not be applied. For
    one operation may be less restrictive with his ESMTP AUTH
    users, and more  restrictive with anonymous incoming
remote mail.

Do you see cases in the wild in which a client goes to the
trouble to do ESMTP AUTH and get it right and still can't manage
a correct domain name?  I can imagine conditions under which
that might happen, but would hope they would be using Submit and
letting it clean up the EHLO domain name (as you have indirectly
pointed out in another context.

    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.