[while the half-baked scheme described isn't a draft, and therefore
is not under serious IETF consideration), it does warrant a brief
critique so that others do not make the same silly mistakes that the
author of this scheme has made.]
SMTP servers SHOULD publish an extended line 220 greeting response
indicating the system server basic mail policy.
1. The SMTP protocol is based on reply codes; text is meant for humans
(RFC 2821 sections 4.2, 4.3). The protocol is based solely on the
reply codes, not on text.
2. Text in a dead language (e.g. Latin) is unlikely to be widely
meaningful, nor is text in an obscure dialect of Chinese likely
to be useful to a Swahili-speaking human (or vice versa) who happens
to encounter non-protocol SMTP command text.
3. Policies may have legal ramifications, and some policies may be
illegal is attempted to be applied to Internet traffic from some
places.
4. Best Current Practice (specifically BCP 18) requires provision for
internationalization of text. SMTP has no such provision for text
accompanying response codes. Fortunately, such text is mostly
optional and plays no role in the protocol. Any attempt to
superimpose some role on such text would run afoul of the BCP 18
requirements. Of course a new protocol could be defined differently,
but that's another matter.
5. In particular, any extension to SMTP involving negotiation (e.g.
of language for text) has to take place using the established ESMTP
negotiation mechanism. As that takes place after the greeting and
EHLO stages, it cannot be used for negotiation affecting greetings,
greeting reply codes or text, the EHLO command itself, its reply
codes, or its reply text. A properly-designed new protocol could
address such matters, but again, that's not SMTP.
6. As SMTP has no provision for server authentication, the greeting
(including text) can be trivially forged.
7. As noted in RFC 2821 section 3.1, information provided in greeting
text may have security implications.
8. One might try to introduce additional reply codes for the greeting
message to convey (in a language-independent and protocol-meaningful
way) some nuances about a server administrator's policy. But that
would likely fail to interoperate with widely deployed client
implementations which expect either a 220 or 251 greeting reply.
Of course, a new protocol could address that, but then it wouldn't
be SMTP.
1.2) HELO/EHLO
[...]
The SMTP server SHOULD perform SHOULD a Local Domain Network IP
validation check
Proofreading is always advisable...
[...]
Due to the nature of SMTP, HELO/EHLO validation is relaxed and its
verification is weak. There are legitimate reasons as to why a
client machine domain does not match the IP address.
So there are "legitimate reasons ..." (agreed), but it SHOULD nevertheless
be checked. Why? And since (because of the "legitimate reasons") the
check provides no useful information, what is to be done with the results
of the "validation check"?
However, by SMTP 2821 requirements, the return path (MAIL FROM) MUST
be valid for potential system notification mail flows. A valid return
path is a fundamental and essential technical requirement for proper
mail flow,
A null reverse path is always valid.
Therefore, the SMTP server SHOULD highly consider to perform some
form of return path validation. How this is done is a SMTP system
implementation dependent and considered as a "BLACK BOX"
concept and is subject to on going R&D.
No. It is known that some hare-brained schemes are harmful (e.g. issue
a test message using a server specified as an MX host for the MAIL FROM
domain (if not a null reverse path); hint: consider what happens if both
servers do that). No "R&D" is needed to see that some schemes are
harmful.