[Top] [All Lists]

Re: SMTP Mail Hosting and TMS Recommendations [was: Hector's BCP summary outline for SMTP]

2005-06-20 10:10:21

[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

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.

   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

<Prev in Thread] Current Thread [Next in Thread>