[Top] [All Lists]

Re: New issue (was Re: rfc2821bis-01 Issue 18: Usability of 1yz replies)

2007-04-23 14:29:20

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

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.


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