Hector Santos wrote:
What it probably interested here is that its uses a non-standard less
than 100 code for "informational", so something like this is valid under
SendMail.
099-Informational
099-Informational
099-Informational
099-Informational
250 whatever
Or even:
099 Info
099 Info
250 Whatever
Very interesting.
Unused in practice, I believe.
[...]
I'll say it again this way: this is a common "method" concept in C/S
(Client/Server) designs, especially in a TCP/IP environment. The point
here is that C/S (or even P2P) communication timeouts is generally based
on channel idleness.
I don't disagree. I merely make the point that a server SHOULD NOT
rely on this design. I also make the point that modern conditions
on the Internet MAY make a client choose an overall timeout rather
than an idleness timeout.
I believe the RFC should be
reworded to make it clear that all reply codes in a multiline reply
MUST be the same code.
That would be an unnecessary restriction. Clients or servers doen't
require this tightness.
I believe it was intended by the original authors. In fact, I think
they didn't even imagine the possibility of different return codes on
different lines. But I don't know for sure; we'd have to ask.
IMV, this is backwards. This is a server driven control concept.
No, it's *not*. A server *cannot* expect a client to increase its
timeout just because the server wants it to. A client and server must
*agree* on a mechanism for processing-in-progress messages. Just
because your hack happens to work with many SMTP clients today doesn't
mean it's a good design or should be blessed by an RFC.
Regards,
David.