--On Thursday, 12 April, 2007 14:02 -0400 Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
On Tue, Apr 10, 2007 at 11:24:18AM -0400, Jeff Macdonald wrote:
On Tue, Apr 10, 2007 at 10:40:52AM -0400, John C Klensin
wrote:
(iii) Prohibit different codes and, optionally, suggest
that it is ok for a client to select one of them and
assume that all of the others are the same.
+1
While some may believe the current spec is clear enough, I've
seen individuals outside of this group that have been
confused as to what is valid and I've seen multi-line
responses were different codes have been used. So, the
current spec isn't clear enough IMO. I'll try to dig up some
actual examples.
I have found only 1 live example of this:
550-Unknown user
421 clean.daytoncreative.net: SMTP command timeout - closing
connection
It is unclear to me what is happening here. 421 can happen at
any time, but is it ok as part of a multi-line response? I
think not.
Again, just personal opinion, but, if I'm designing a server, I
never want to issue a 421 code (or any other 4yz code), in a
situation in which I want the sender to take that particular
message and go away and not come back with it -- at least
without making some significant changes. 421 is effectively a
"try again later" request, which I wouldn't want to send out
unless I really want to see that message, with that content and
recipient list, again.
In addition, if the client does look only at the code on the
last line of the multiline response, the "unknown user"
information is going to get lost entirely.
I also have examples of multiple responses to a command. This
is not directly related to multi-line responses, but I'd like
to point it out. I believe the RFC allows this behaviour, but
there seems to be two ways folks handle rejecting content:
C: \r\n.\r\n <-- end of data
S: 5xx
S: 421
Well, this would, as Tony Finch pointed out, be construed by a
client that wasn't aware of the games that were being played as
a 5xx response to DATA and a 421 response to whatever command
was issued next. As such, it is a courtesy before the server
closes the connection -- if the client sends out a command or
otherwise opens a read and gets the 421, it at least knows that
the server tried to warn it before closing. If it doesn't, not
much harm done.
There is specific language in 2821 that authorizes asynchronous
issuing of a 421 if necessary and it incorporates exactly that
logic.
Note that using 421 that way is pushing the boundaries of 2821
fairly hard: unless the server thinks that "bad content"
constitutes an attack against which it must be defended --and
thinks that this defends it -- a server close without a QUIT
violates a strong prohibition in the spec.
and
C: \r\n.\r\n <-- end of data
S: 421-<long explanation>
S: 421
I think it is out of scope, but should the RFC make a
recommendation either way?
Speaking personally, I'd prefer not. What we have now is a
general prohibition on server closes and a fairly general
loophole about self-defense. If we start making
recommendations, we are going to need to make one or the other
(or both) much more specific. I suspect that trying to do that
would lead us through a whole sequence of previously-unexplored
ratholes.
john