ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-23 02:43:19

--On Monday, 23 April, 2007 01:09 +0200 "Peter J. Holzer"
<hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:

On 2007-04-22 16:46:06 -0400, Hector Santos wrote:
Just look at how it has been interpretation at:

   http://www.tcpipguide.com/free/t_SMTPRepliesandReplyCodes-
   2.htm

You can't just throw that out into the waste basket.

Why not? There are tons of bad books out there which belong
into the waste basket. To be fair, a simple mixup of sender
and recipient in a case which can only happen if the server
uses an extension not defined in any RFC is probably easy to
miss (I had to read the sentence several times to see what was
wrong with it and I was specifically looking for an error).

I've written the author in the hope that he will clarify where
this came from but, having now read the several pages
surrounding that one and his FTP description, it is pretty clear
to me what happened.  With FTP, those 1yz codes definitely and
unambiguously mean that another, final/definitive, value is
coming and one doesn't need to do anything else --such as issue
a command-- to get it.   He assumes that the logic of the first
digit of the codes is identical in FTP and SMTP and says so.  

The problem is that they are not.   Even though most recent
implementations haven't recognized it, much less taken advantage
of it, FTP is asynchronous.   SMTP is not but, instead, is
modeled on one command - one response.  I am just guessing, but
I think it was exactly that difference that caused Jon Postel to
write the text that is causing all of this trouble.  For FTP, a
1yz response means "client should expect another response",
which is what that author says for both cases.  For SMTP, it
can't have that meaning because it would break the "one command
- one response" model.  So he wrote that a 1yz code would
require that the client issue a command --presumably to continue
or abort-- before the server could continue and send back
another response.  

Note that none of this has anything to do with multiline
responses of any flavor: in the FTP model, one issues a
non-continuation response with a 1yz code to convey those states
and, in SMTP, the 821 text doesn't say anything about
continuations, codes that can be ignored, etc.

If multiline replies with heterogeneous codes were permitted,
and permitted as a back-door keepalive mechanism, than one could
as easily have
   C:  RCPT TO:<bogus(_at_)example(_dot_)com>
   S:  250- looks ok, but stand by...
   S:  250- looks ok, but stand by...
   S:  250- looks ok, but stand by...
   S:  550  Sorry, we tried but will no deliver to that address

as anything involving insertion of a 1yz code and giving it
special treatment.
 
...
What are you basically implying that we have a problem with
clients not  supporting the 25 year specification

No, we are concerned that clients which are supporting the 25
year old specification will be rendered non-compliant if your
interpretation is formalized.

Peter, while I agree, let's be a little careful.  Assume that
one reasonable person can read the text as saying both "yes, you
can invent 1yz codes and, despite the words about needing to
issue another command, treat them simply as a continuation
indicator" and "only the last code counts" and base an
implementation on it.  Assume that another reasonable person can
read the same text and conclude that there is no authorization
to use 1yz codes that way and no way to get from "In many cases"
to "in a continuation sequence, no reply line but the last one
counts" and, in addition, concludes that the codes must all be
the same, and base an implementation on that.  

Then we have a problem. The non-solution is to leave the text
exactly as it is, i.e., preserve the ambiguity that some would
claim has been there for a few months short of 25 years.
Either of the solutions -- to clearly support Hector's
interpretation or to clearly support yours -- results in some
implementations being declared invalid.  I don't see how to
avoid that.  

I also don't see that there is any difference between a SHOULD
NOT and a MUST NOT applied to sending out either mixed-code
multiline responses or to 1yz codes.  In either case, the
SMTP-sender needs to be prepared to cope and, if the multiline
response contains mixed codes, it will, probabilistically, screw
up.   Does it make any difference whether the problem is caused
by violation of a SHOULD NOT or a MUST NOT?  I think it does iff
the client is going to inspect all of the codes and, if they are
mixed, make a decision as to whether that is such a horrible
situation that it should immediately send a RSET or QUIT and
stop talking to that particular nasty, non-conforming,
ill-mannered, server _and_ it would do that if we said MUST NOT,
but would figure out how to cope and continue if we said SHOULD
NOT.  My experience with real systems in the field (as distinct
from what might happen in laboratories or with demonstration
systems) is that they don't get to behave that way: "nah, nah,
I'm not going to communicate with you until you clean up your
act" doesn't go over well with users who are trying to get mail
through unless the bad behavior is really so serious that there
is no reasonable way around it.

That turns my strongest argument for using "MUST NOT" into one
of not being able to identify the case that would justify the
exception that "SHOULD NOT" implies.  If, as Tony's recent note
points out, we can identify a significant number of real-world
situations in which some systems pick "first" and others pick
"last", then we invite client confusion if there are _any_
exceptions to a "no mixed codes" rule.  That says to me that
this must be a "MUST NOT" unless either 

        (i) we are prepared to identify the case(s) that would
        justify that confusion or
        
        (ii) we are prepared to put in text that tells a client
        that it _might_ receive mixed codes in spite of the
        SHOULD NOT prohibition and how it is expected to deal
        with that case.

While the second might not be a bad idea in practice, it would
require changing _everyone's_ code that picks either "first" or
"last" rather than inspecting all codes today.  And I haven't
seen any instances of the first if the measure is "having
confusion and  therefore having clients behave unpredictably is
ok".

      john