According to RFC959: FILE TRANSFER PROTOCOL (FTP)
(section 4.1.1):
Servers may allow a new USER command to be entered at any point in order to change the access control and/or accounting information. This has the effect of flushing any user, password, and account information already supplied and beginning the login sequence again. All transfer parameters are unchanged and any file transfer in progress is completed under the old access control parameters.
We can certainly re-send “USER”to authenticate user at any time. However our IT team recently established a new ftp server deployed on Linux, and not allowed client re-send “USER” command before current session be disconnected. In our IT team’s words, that change provides robust environment to user.
I’m wondering whether this change worthy and valid? Please give me a authoritative explain if possible.
Is it worthy and valid? Well, your IT team is free to do whatever it wants to satisfy its needs.
But, the whole point of standards (including the RFCs) is that you follow them so that there will
be no nasty surprises for software that relies on that behaviour.
However, in this case, the magic word is “may”. In standards parlance, “may” means exactly that. Servers may allow something. They are not required to do so.
If it was a requirement, they would have used stronger words – “shall” is a favourite of many standards bodies.
From RFC2119, point 5:
So I think in this particular case, they are not actually violating the RFC.
Having said that, I’m not sure of the reasoning behind the assertion that it’s more robust for the user (presumably at the client end). As the RFC states, it applies only to new transfers initiated after the change. All those currently in progress are unchanged.
Your best bet would be to ask your own people why this is the case.