Subject: 530 Response Code instead of 421 when limits are reached

From: "Philip Kearney III" <[email-masked]>
Date: Thu, 6 Nov 1997 19:59:57 -0500

As an experiment, I put the following in my ftpaccess file:

# Classes of users

class   local   real,guest *.domain 0.0.0.0
class   remote  real,guest *
class   anon    anonymous *

# Limits on classes of users

limit   local   60  Any                 /etc/msgs/toomany.msg
limit   remote  60  SaSu|Any1800-0600   /etc/msgs/toomany.msg
limit   remote  20  Any                 /etc/msgs/toomany.msg
limit   anon    1   Any                 /etc/msgs/toomanyanon.msg

Now, when the second anonymous user tries to log in, the response code I get 
back from the server is:

530 User anonymous access denied.

Now if I look in STD 9, the FTP specification, I see the following sequence of 
commands and reponses for the USER command:

USER
   230
   530
   500, 501, 421
   331, 332

In this case, shouldn't the server be returning a 421 (service not available) 
and not a 530 (access denied) because that user is not being flatly denied 
access in all situations, rather the FTP service is unavailable because there 
are already too many users logged in under that username?

Most other servers I deal with will return a 421 in this situation and I think 
that previous versions of wu-ftpd used to do the same and return a 421 in this 
situation.

This is occurring on a Sparc running SunOS 4.1.4 using Version wu-2.4.2-
academ[BETA-15].

-pk

----------------------------------------------------------------------------
Philip Kearney III                mailto:[email-masked]
Sr. Software Engineer             mailto:[email-masked]
System Administrator              finger [email-masked] for my PGP key
Ascend Communications, Inc.       
Client Software Engineering Group             
----------------------------------------------------------------------------

---

From: Bob Luckin <[email-masked]>
Date: Thu, 6 Nov 97 19:35:01 CST

Philip Kearney said :-
> As an experiment, I put the following in my ftpaccess file:
...
> # Limits on classes of users
...
> 530 User anonymous access denied.
...
> are already too many users logged in under that username?

My interpretation of this situation is that the service is still available -
just not to any more anon users, who are being denied while the limit is
reached.  The other classes of users can still access it, assuming their
limits have not been reached.

So I think that the 530 you are seeing is correct, and a 421 would be
incorrect in this case.

I may of course be shouted down...  :-)

Cheers, Bob
-- 
Bob Luckin  [email-masked]  "On data, coder, adapt - FTP Ada, redo C a tad, no ?"
                         [http://www.dhc.net/~luckin/paliindromes.html]

---

From: "Philip Kearney III" <[email-masked]>
Date: Thu, 6 Nov 1997 21:13:35 -0500

On Thu, Nov 6, 1997 at 8:35:01 PM, Bob Luckin <[email-masked]> wrote:

> My interpretation of this situation is that the service is still 
> available - just not to any more anon users, who are being denied while 
> the limit is reached.  The other classes of users can still access it, 
> assuming their limits have not been reached. 
>  

See but, according to STD 9, a 421 is defined as:

421 Service not available, closing control connection.
    This may be a reply to any command if the service knows it
    must shut down.

And the wu-ftpd service does, I'm almost positive, close the control 
connection in this situation.  If it issues a 530 and then closes the control 
connection, then to me this seems wrong.  If it knows it is going to close the 
control connection, then it should be issuing a 421 not a 530 because this is 
an entirely different situation from when access is denied for a specific 
username and the server sends a 530.  In that case, it allows the user the 
ability to try another username.

In one case you have:

USER foo
331 Password required for foo.
PASS ********
530 Login incorrect.

And the client can try another username and/or password. 

In my original scenario (with one anonymous user already logged in) you get:

USER anonymous

*boom* the control connection is shut down by the server.

This is contrary to the first behavior and makes the 530 response code 
ambiguous.  In one case it shuts down the control connection and in the other 
it doesn't, even though the client receives the same response code.  If one is 
trying to write a graphical FTP client <hint, hint>, there is no way 
programatically to determine which case the client has encountered.  
Therefore, in the latter case, the server should issue a 421 and not a 530 
since it shuts down the control connection.

-pk

---

From: Bob Luckin <[email-masked]>
Date: Fri, 7 Nov 97 11:28:06 CST

>     This may be a reply to any command if the service knows it

Philip Kearney replied :-
> ability to try another username.

OK, now I understand your argument.  You're saying the issuance of a 421
should be predicated by the closure of the control connection.

I'm not familliar with STD 9, which you quote.  However, I have looked at
RFC959, which covers File Transfer Protocol (FTP), and is what wu-ftpd is
supposed to comply with...

Here's what RFC959 says about reply codes beginning with 4 and 5 :-

            4yz   Transient Negative Completion reply

               The command was not accepted and the requested action did
               not take place, but the error condition is temporary and
               the action may be requested again.  The user should
               return to the beginning of the command sequence, if any.
               It is difficult to assign a meaning to "transient",
               particularly when two distinct sites (Server- and
               User-processes) have to agree on the interpretation.
               Each reply in the 4yz category might have a slightly
               different time value, but the intent is that the
               user-process is encouraged to try again.  A rule of thumb
               in determining if a reply fits into the 4yz or the 5yz
               (Permanent Negative) category is that replies are 4yz if
               the commands can be repeated without any change in
               command form or in properties of the User or Server
               (e.g., the command is spelled the same with the same
               arguments used; the user does not change his file access
               or user name; the server does not put up a new
               implementation.)

            5yz   Permanent Negative Completion reply

               The command was not accepted and the requested action did
               not take place.  The User-process is discouraged from
               repeating the exact request (in the same sequence).  Even
               some "permanent" error conditions can be corrected, so
               the human user may want to direct his User-process to
               reinitiate the command sequence by direct action at some
               point in the future (e.g., after the spelling has been
               changed, or the user has altered his directory status.)

Clearly if the control connection is closed, the user cannot repeat the
request to login.  This is a permanent condition, and a response beginning
with a 5 is more appropriate than one beginning with a 4.

Further on, RFC959 defines the second digit to be a 3 if the response is
a reply for the login process and accounting procedure.  And since the
response you got was to an attempt to login, a 3 for the second digit is
clearly appropriate.

Still further on, the RFC specifically defines a 530 as :-

         530 Not logged in.

This is also appropriate for your example.  So I believe that wu-ftpd is
in compliance with RFC959 and is giving you the correct response in the
situation you describe.  If other FTP servers aren't, then perhaps they are
at fault...

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "Coder adapt; FTP Ada, redo C"
                                 [http://www.dhc.net/~luckin/palindromes.html]

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 7 Nov 1997 12:56:56 -0500 (EST)

On Fri, 7 Nov 1997, Bob Luckin wrote:

> I'm not familliar with STD 9, which you quote.  However, I have looked
> at RFC959, which covers File Transfer Protocol (FTP), and is what
> wu-ftpd is supposed to comply with... 

STD9 _is_ (for most purposes) RFC959.  It has completed the IETF standards
track and, therefore, supersedes RFC959.  So wu-ftpd is actually supposed
to comply with STD9.  Since there's almost no difference between the two
documents, it's a very fine distinction at this time. 

I would agree with your argument, 5xx is more appropriate than 4xx.  For
the purposes of the session in progress, the error is non-transcient. 
Having just sent a message indicating the session is hopeless, it seems
only logical to close down the connection.

It seems to me that the design of the server is important when making the
determination.  Rather than saying "this server is right and that one is
wrong", I'd prefer to believe that a server responding with 4xx will
provide a means to re-evaluate the user limits without terminating the
session.  I'd be loath to run such a server, however, since it smacks of a
DoS hole.

---

From: Bob Luckin <[email-masked]>
Date: Fri, 7 Nov 97 14:08:16 CST

> > wu-ftpd is supposed to comply with... 

Gregory Lundberg replied :-
> documents, it's a very fine distinction at this time. 

Fair enough.  Is there an on-line copy which Kent could link to from the
WU-FTPD resource center ?

> session.  I'd be loath to run such a server, however, since it smacks of a

Exactly.  This might apply _if_ the server didn't close the control
connection, but allowed the user to try to log in with a different id; you
could argue in that case that it was a transient situation.  (But since
the user is not retrying the exact same command sequence - they are supplying
a different account name - you could perhaps also argue that this should still
be a 5xx.  :-)  Ah well, since wu-ftpd closes the connection anyway, it's a
moot point.)

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "Dick's attempt FTP met task CID"
                                 [http://www.dhc.net/~luckin/palindromes.html]

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 7 Nov 1997 15:16:37 -0500 (EST)

> WU-FTPD resource center ?

Well lessee .. InterNIC has one:

  http://ds1.internic.net/std/std9.txt

And, of course, there's the horse's mouth:

  http://www.isi.edu/rfc-editor/
  ftp://venera.isi.edu/in-notes/std/std9.txt

I'd suggest, though, that Kent grab a local copy for his pages, and
include one in the documentation rolled into the tarball.

---

From: Kent Landfield <[email-masked]>
Date: Fri, 7 Nov 1997 20:44:05 -0600 (CST)

# > On Fri, 7 Nov 1997, Bob Luckin wrote:
# > 
# > > I'm not familliar with STD 9, which you quote.  However, I have looked
# > > at RFC959, which covers File Transfer Protocol (FTP), and is what
# > > wu-ftpd is supposed to comply with... 
# 
# Gregory Lundberg replied :-
# > STD9 _is_ (for most purposes) RFC959.  It has completed the IETF standards
# > track and, therefore, supersedes RFC959.  So wu-ftpd is actually supposed
# > to comply with STD9.  Since there's almost no difference between the two
# > documents, it's a very fine distinction at this time. 
# 
# Fair enough.  Is there an on-line copy which Kent could link to from the
# WU-FTPD resource center ?

;) Take a look at http://www.landfield.com/rfcs/ ;)

BTW... RFC 959 and STD9 are the same document exactly. 

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: [email-masked]             http://www.landfield.com/
Email: [email-masked]                   http://www.nfr.net/
Please send comp.sources.misc related mail to [email-masked]
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/

---

From: Jim Davis <[email-masked]>
Date: Sat, 8 Nov 1997 11:34:19 -0700 (MST)

I'm surprised no one has mentioned rfc1123 yet, which has a relevant
section (4.1.2.11) about this very issue.