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
solution.
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
a SHOULD.
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
messages.
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.
Regards,
David.