Re: [bug-inetutils] ftpd returns 550 to NLST

[Mats Andersson]

onsdag den 13 juli 2011 klockan 11:17 skrev Andrew Stevenson detta:
> 
> I was thinking of section 5.4:
> 
> NLST
>                   125, 150
>                      226, 250
>                      425, 426, 451
>                   450
>                   500, 501, 502, 421, 530
> 
> The text suggests to me the section is supposed to be authoritative but I
> may have got it wrong - I must admit I didn't read the whole document that
> closely.

The text claims to be authoritative in the sentences:

    (rfc959.txt, Section 5.4, fifth paragraph)

    The table below [excerpt is above!] lists alternative success and failure
    replies for each command. These must be strictly adhered to;
    ...
    but the meaning and action implied by the code numbers and by the specific
    command reply sequence cannot be altered.

When introducing this table of interactions, there is a statement that each
contain four groups of replies: "preliminary" (with further subsequent replies
indented), "positive", "negative", and "intermediary".

Thus it would seem that "450" counts as a "positive" reply, which makes
very little sense to me. Neither of the five subsequent replies qualify
for reporting a missing file though.

> > However, the category 4xy is expressing a temporary condition like
> > a busy or locked file. A message expressing a permanently missing
> > file should be found in the message class 5xy. This was the path
> > chosen by the original Netkit code and is presently continued also
> > by GNU Inetutils. The FTP server of OpenBSD continues this design
> > decision, as does linux-ftpd (available in Debian).
> 
> I do agree it seems more logical to allow 550 but 5.4 suggests to me you
> can't. I'm no expert on this matter - I only came across it because I had
> to debug a problem that turned out to be caused by an FTP client that had a
> similar interpretation of the RFC (that 550 isn't an allowed response) - so
> I'm happy to defer to others if they know better.

It would help me to know which client you did use. An interactive client,
or a scripted client which relies an automated parsing?

> I'm also aware that the original BSD ftp code (and possibly all the current
> BSD code) behaves the same. That's a good argument that the client should
> probably be more generous in what it accepts but, if it is determined this
> is incorrect behaviour, it probably isn't enough to justify keeping it in
> the server, unless something widespread is relying on the behaviour.

How does your client cope with ProFTPD and Pureftpd? These reply differently
as compared to GNU Inetutils. How about Vsftpd? Some indication of their
design decisions might help me with ours!

> Anyway I'm happy to defer to the wisdom of the list as to if people
> consider this should be changed or not.

This is a relevant matter, so I am grateful to have been made aware of it
(including the my involvement in 'linux-ftpd' for the Debian project).

Best regards,
  Mats E Andersson