David F. Skoll wrote:
For a completely unrecognized code, the client SHOULD ignore the code.
NO! This is untenable. A client CANNOT ignore the code, because SMTP
*demands* that a client send a command after the server has sent a
reply.
David, that is not quiet true. i.e. multi-line responses.
But then again, it all depends on the new 2821bis endorsement for a
proper valid reply-code line from where a reply code is extracted.
In short, the client SHOULD not be sending a command after reading a
continuation line.
The issue here was:
150-eh? Got Milk?
250 DONE
If your code is aborting on 150 and issueing a COMMAND on 150, then you
are clearly more than broken. But I guess we are endorsing the
behavior, or are are outlawing multi-line responses?
If a server sends:
666 Mail diverted to the nether regions of the universe
The client *cannot* simply ignore it, or you deadlock.
Are you stating how your client will behave or guessing other clients
will deadlock as well?
How about if it was more realistically?
120-Hold on. How about a cuban Cigar?
550 I don't SMOKE!
Now perhaps in an ideal world the client could respond:
UHOH Dunno what the heck you mean
What ideal world would that be?
but that's alas not part of the standard. Therefore, the ONLY sane response
is a QUIT or a RSET.
Again, a perfectly valid argument, but nonetheless a quess/opinion.
If you have read any further in my message, I recognize there are enough
broken code out there that don't follow reply code specification anyway
(but will with the few strokes of the pen), an abort proposal is
probably ok.
Keep in mind, that you are PROMOTING change, and with CHANGE, it opens
the door to doing things right. So in the same vain you disagee with
mixed continuation reply code and preached an extension, the same
ideology applies here for aborting on unrecognized reply codes.
So if you are ready to make your delegate design changes to your
programming staff to promote an ABORT on unrecognized reply codes, you
might want to first be open to the idea of what is already existing in
the specs to utilize these new 2821bis endorsed reply code control concepts.
I'm dead serious. What if your client software did encounter a
transaction where the server did attempt to KEEP you alive with?
C: DATA
S: 352 start your engine
[client begins upload]
S: 150-Hmmm, you got some heavy stuff dude?
S: 150-Need to do a check. please grab a seat...
S: 250 Ok Charlie, its all good!
C: QUIT
Are you honestly going to not support this in your commercial product
line? As managers, we would be very sensitive to such issues.
Do not assume just become it is WRITTEN (no mixed codes in 2821bis) so
it will be DONE. We already proved how erroneous that is with broken
software not following proper reply code reading.
I am not re-awakening the mix code issue. No, thats been decided. But
rather how you are proposing the client should react to such a scenario.
Also keep in mind that implementators have different ways in performing
their retries and in addition, in the advent of security, some servers
may actually see dropping clients as suspicious.
--
HLS