Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!TOPAZ.RUTGERS.EDU!ron
From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Multiple 331 password responses in FTP protocol
Message-ID: <8709041634.AA11908@topaz.rutgers.edu>
Date: Fri, 4-Sep-87 12:34:21 EDT
Article-I.D.: topaz.8709041634.AA11908
Posted: Fri Sep  4 12:34:21 1987
Date-Received: Sat, 5-Sep-87 22:46:00 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 19

UNIX uses the simple minded approach.  Only the first digit is
checked.  (This is for infomration).

I think ACCESS/MVS is doing the wrong thing.  The reply strings
are supposed to be informative only, the client is supposed to
be able to make it's decisions based on the numbers alone.  The
only defined acceptable replies in the spec are 3XX meaning
send account, 2XX Success, and 5XX error.  Doing anything else
is just asking for trouble.  The last two digits are there to
provide a finer differentiation of the error, but not to change
the flow of control.

Beyond that conceptual problem, if I understand what is going on here,
you're second password string actually changes the password?  This is
a horrendous security problem and really ought not to be done in FTP.
Better to just return an error (EXPIRED PASSWORD) and leave the user
to correct the situation through other channels.

-Ron