--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
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.
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
first
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
client.
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
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
See above.
- 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.
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.
thanks
john