Resumo

  • USER, PASS e ACCT eram identificadores distintos de controle de acesso. Aceitar a senha não obrigava o servidor a considerar o login completo nem todas as operações autorizadas.
  • 332 era uma resposta intermediária positiva e, após um comando de arquivo, informava que o servidor ainda guardava aquela intenção. 532 encerrava a tentativa e exigia reenviar o comando depois de fornecer a conta.
  • O protocolo não padronizou o significado de account. Ele preservou a autoridade do sistema remoto sobre contexto de projeto, recurso ou acesso, sem transformá-lo em identidade global, cobrança ou prova de uso atual.

O login parou entre a senha e a sessão

O cliente envia USER, recebe o pedido de senha e responde com PASS. Se nenhuma informação adicional for necessária, RFC 959 permite 230 User logged in. Mas um servidor que ainda precise de uma conta para o login devolve 332 Need account for login.

O algarismo 3 classifica uma etapa aceita que aguarda mais informação. Não é uma senha recusada. A próxima mensagem correta é ACCT; repetir PASS só confirma que o cliente perdeu a diferença entre prova de identidade e seleção de contexto.

Esse estado é estranho a telas modernas de duas caixas, mas era natural numa rede que conectava sistemas com modelos de recursos diferentes. Saber quem era o usuário não respondia necessariamente sob qual conta seu trabalho consumiria armazenamento ou receberia permissão.

A terceira informação foi criada para um sistema real

RFC 385 propôs ACCT em agosto de 1972 e citou TENEX: além de usuário e senha, o sistema exigia uma especificação separada de conta. A proposta dizia que o comando não precisava estar preso a USER, podia chegar a qualquer momento e podia mudar entre transferências do mesmo usuário.

Por isso ACCT não deve ser descrito como segunda senha. Tampouco account significa necessariamente conta financeira. A sintaxe era apenas uma cadeia Telnet. Cada servidor conservava o poder de interpretá-la como projeto, alocação, domínio de autorização, centro de custo ou outra estrutura local.

FTP aceitou a heterogeneidade em vez de inventar um objeto universal. O ganho foi tornar explícito que uma decisão local ainda faltava. O custo foi exigir de clientes uma máquina de estados maior que o formulário usuário/senha.

A semântica sobreviveu a uma troca de números

Em 1973, RFC 542 incorporou a conta ao conjunto de acesso. Seu esquema usava 331 Enter account para completar o login e 433 quando uma transferência sem conta precisava ser refeita.

RFC 640 revisou os códigos para que programas descobrissem resultado e próximo estado pelos dígitos, sem analisar o texto livre do servidor. Respostas 3yz passaram a ser intermediárias positivas; 5yz, conclusões negativas da solicitação exata. O segundo dígito 3 agrupava autenticação e accounting.

O novo vocabulário separou 331, “usuário aceito, falta senha”, de 332, “falta conta para login”, e criou 532 para a conta exigida no armazenamento. Ler uma captura de 1973 com a tabela de 1985 atribui à mesma cifra uma pergunta que ela ainda não fazia.

332 guardava a ordem; 532 a devolvia ao cliente

RFC 765, preservado por RFC 959, descreve o caso pós-login. Um cliente envia STOR; a política local exige uma conta para aquele armazenamento.

Se o servidor mantém STOR pendente, responde 332 e espera ACCT. A intenção continua do lado remoto. Se descarta STOR, responde 532. Fornecer a conta resolve o contexto, mas o cliente ainda precisa emitir novamente a operação.

Esse é um contrato de custódia. Ambos os códigos mencionam a mesma informação ausente, porém só um conserva o pedido. Um adaptador que os transforme numa exceção genérica “account required” não sabe se deve enviar apenas ACCT ou ACCT mais o comando original.

Falta de conta não mede espaço livre

O texto de 532 inclui “storing files”, mas não diagnostica disco cheio. RFC 959 reserva 452 para espaço insuficiente no sistema e 552 para alocação excedida no diretório ou conjunto de dados.

Conta ausente, capacidade física e limite de alocação pertencem a controles diferentes. O primeiro pode ser corrigido com contexto; o segundo requer recurso; o terceiro, mudança de quota ou política. Juntá-los num alerta de storage impede a ação correta e pode mascarar tentativas repetidas que nunca tiveram autorização contextual.

A conexão podia sobreviver à troca de identidade

Uma nova ordem USER na mesma conexão apaga usuário, senha e conta já fornecidos e reinicia o login, segundo RFC 959. Os parâmetros de transferência ficam; um arquivo já em movimento termina sob os controles antigos.

Assim, o socket não é uma fronteira suficiente para autoria. O novo usuário não passa a controlar retroativamente a transferência em curso, e a conta antiga não deve ser aplicada às ordens futuras. REIN também limpa o contexto de usuário e conta sem fechar a conexão e restaura os demais parâmetros.

Uma trilha de auditoria precisa ordenar esses eventos. O fato de ACCT ter sido aceito em algum ponto da conexão não prova que continuava vigente depois de USER, REIN ou reconexão.

Implementar ACCT não era exigir ACCT

RFC 1123 incluiu ACCT entre os comandos que cliente e servidor deveriam suportar, ressalvada a exceção do sistema de arquivos ou sistema operacional subjacente. O objetivo era impedir que uma implementação incapaz de expressar o terceiro estado bloqueasse um site que o utilizava.

Um site sem conceito relevante podia reconhecer o comando e responder positivamente com 202, indicando que era supérfluo. Compatibilidade da linguagem não equivale a uniformidade de política.

O registro da IANA para comandos e extensões FTP ainda lista ACCT como comando base de controle de acesso, com RFC 959 como referência. Isso comprova o slot normativo, não quantos servidores o oferecem, o que seus valores significam ou se uma transferência ocorreu.

A terceira resposta protegia uma verdade operacional

FTP não prometeu harmonizar contas entre máquinas. Ele permitiu ao servidor dizer: reconheci o usuário, aceitei a etapa do segredo, mas falta um contexto que só minha política pode interpretar. E, quando o problema aparecia depois, permitiu dizer se a ordem continuava guardada.

O princípio permanece útil fora do FTP. Identificar um sujeito, escolher o domínio de recursos e aceitar uma ação são decisões diferentes. Reduzi-las a “autenticado” simplifica a interface, mas transfere a complexidade para credenciais compartilhadas, scripts específicos e falhas que parecem senha incorreta ou disco cheio hoje.

Fontes e limites

O conjunto é RFC 385, RFC 542, RFC 640, RFC 765, RFC 959, RFC 1123 e IANA. Ele estabelece semântica e história, não sigilo do parâmetro, prevalência atual, cobrança, comportamento de produto ou conclusão de arquivo.