I am not disagreeing with any points being made here, including some of
yours. Foremost, I am 100% for SMTP technical protocol consistency and
In this case, we have an unique opportunity to embrace and legitimize
what you call a "hack" to not only clarify what is already inherently a
25 year old wide practice (last reply code) but to also use it to
establish the necessary framework for inevitable pending new technology
that will, without a doubt, confront this very issue.
So we can either embrace it or close what you call a "hack."
All I am saying is closing it, locking it down, will hurt new
development, not help it. The philosophy differences between the
dynamic vs post smtp processing people is a non-starter. So need to
bring that up.
David F. Skoll wrote:
Hector Santos wrote:
But when you are confronted with a problem, you need to sometimes to
think out of the box, to explore, and then, see, as in this case, if you
can make it work with the current system. That would be ideal.
Your solution to the SMTP timeout problem was certainly creative and
interesting, but nevertheless, it is a hack. By "hack", I mean something
clever that seems to work well in practice, but is inelegant and unworthy
of being raised to the status of an Internet standard.
Hence, IMV, I believe using 150- for SMTP to resolve a the potential
TIMEOUT issue with backward compatibility is a valuable and viable
Actually, the problem is being approached incorrectly. If a client is
timing out frequently, it either means (1) the client's timeout is too
short, or (2) the server is too slow or is ignoring the RFC's
statement that it "MUST seek to minimize the time required to respond
to the final <CRLF>.<CRLF>" Note that there's a MUST in there, not
So I don't believe hacking in a fix to alleviate the symptoms is the
right approach; the proper approach is to fix the problem. If online
scanning is taking too long, then IMO the server SHOULD accept the mail
with a 2xx code and do offline scanning. It's then a matter of policy
whether the server should generate an NDN or simply discard unacceptable
I suspect the primary motivation for a keepalive is to prevent MUAs
like Outlook from timing out when doing message submission. If
timeouts are a problem in this situation, then the correct solution is
to rearchitect the network so MUAs submit to a dedicated (and fast)
submission machine, with any content-scanning happening offline or on
a separate content-scanning relay. In this constrained environment
(especially if you're using SMTP AUTH), it makes sense to generate
bounce messages without fearing backscatter.