Tony Hansen wrote:
As yet, there has been no discussion on this issue.
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
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
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.