Resumo

  • A RFC 1440 permitia que um remetente sem conta no host-alvo empurrasse um arquivo não tratado como correspondência para um daemon receptor.
  • Um NULL ACK aceitava apenas um comando; EOF ou fechamento da conexão concluíam o enquadramento, não a decisão do destinatário.
  • O spool compartilhado deslocava capacidade, retenção, autenticação, quarentena e eventual execução para autoridades locais separadas.

A iniciativa mudou de lado

No modelo usual de FTP, o usuário abre o controle, identifica-se quando exigido e pede uma operação no sistema de arquivos. O Sender-Initiated File Transfer, também chamado Unsolicited File Transfer, começou pelo remetente. “Unsolicited” queria dizer que o receptor não iniciara a transação; a RFC advertia que isso não tornava o objeto indesejado.

A referência eram redes NJE, como BITNET, que podiam enviar arquivos fora da experiência do correio eletrônico. O autor comparou o serviço a um pacote, em vez de uma carta. O remetente não precisava manter conta ou cadastro no destino, e o recebedor podia recolher o arquivo mais tarde.

Essa comodidade não eliminava trabalho. Ela o mudava de endereço. O destino precisava oferecer listener, resolver nomes locais, controlar espaço, custodiar objetos pendentes e decidir quando descartá-los. A sessão do remetente acabava antes da responsabilidade do receptor.

Comando e corpo viajavam juntos

O daemon escutava a porta TCP 608. Linhas de comando em ASCII e dados binários passavam pelo mesmo socket. A especificação dizia que o fluxo do trabalho podia ser pensado como a concatenação de um arquivo de controle e um arquivo de dados.

FILE informava remetente, tamanho e um ticket opcional; USER escolhia usuário ou serviço local; TYPE declarava a representação. Os três eram necessários antes de DATA. NAME, DATE e parâmetros de registro podiam completar o controle. EOF fechava o arquivo, ABORT descartava a parte recebida e QUIT encerrava o trabalho.

O receptor podia armazenar controle e corpo separadamente, poupando o listener de interpretar formatos estranhos. O preço era manter a associação: instruções, bytes, estado de finalização e disposição posterior precisavam apontar para o mesmo objeto.

O ACK não atravessava o futuro

A resposta positiva começava com um octeto zero. Esse NULL ACK cobria um único comando. Não aprovava o arquivo inteiro nem autorizava qualquer uso.

O tamanho de FILE servia à pergunta “há espaço?”, porém podia ser aproximado. O servidor podia aceitar FILE e depois rejeitar USER por inexistência. Podia aceitar os metadados e falhar ao escrever o corpo. A admissão inicial era uma decisão provisória com base no que se sabia naquele momento.

Na abertura, o servidor enviava um herald com hostname, nível do protocolo e versão do software. A mensagem permitia sincronizar e reconhecer capacidades. Não autenticava a máquina. O campo auth de FILE era explicitamente não implementado, e a RFC dizia que a autenticação não estava assegurada.

O spool era uma sala de espera

O arquivo chegado era colocado numa área compartilhada, como /usr/spool/uft. Ficava ali até o destinatário aceitá-lo ou recusá-lo, ou até o sistema descartá-lo por idade. Compartilhada não significava acesso irrestrito. Tamanho máximo e tempo de retenção pertenciam à administração local.

Transferência, custódia e aceitação tinham relógios próprios. O TCP podia terminar numa manhã, o objeto permanecer durante dias e a decisão nunca vir. Um painel que marcasse “entregue” na primeira transição atribuiria ao transporte um ato que cabia ao destinatário.

Expiração também não era recusa. O desaparecimento posterior podia resultar de limpeza, quarentena, erro ou decisão. Sem um evento de disposição, não havia base para concluir que o arquivo fora consumido.

A recomendação era processar o corpo o mínimo possível antes da aceitação. Uma representação desconhecida deveria sobreviver como binário. Preservar não significava provar integridade contra ataque, segurança ou utilidade.

Cada rajada devolvia o controle

No modo comum, DATA trazia um burst-size. O receptor lia exatamente aquela quantidade, gravava e voltava a interpretar comandos. Muitas rajadas compunham um arquivo; uma conexão podia transportar vários. Entre rajadas, ACK, ABORT e outras decisões voltavam a ter um limite claro.

No modo rápido, o tamanho era omitido e o servidor lia até o cliente fechar a conexão. Não havia EOF ou QUIT. Durante o fluxo, ABORT não podia interrompê-lo. O encerramento do socket tornava-se a única fronteira final.

Menos idas e voltas custavam pontos de recuperação. Um fechamento intencional e uma queda inesperada apareciam da mesma forma. Quantidade declarada, bytes medidos, hash e causa de encerramento eram necessários para decidir completude; “conexão fechada” não bastava.

Um pseudo-usuário apontava para consequências

USER podia nomear um motor de serviço ou uma fila de entrada de trabalhos apresentada como pseudo-usuário. Nesse caso, o objeto aguardando podia alimentar automação, não uma pessoa.

Reconhecer o nome não autorizava executar. Identidade do remetente, direito de submissão, validação, quota, isolamento, despacho e resultado ainda exigiam decisões próprias. O protocolo não transformava uma entrada válida de namespace em permissão operacional.

A lacuna de segurança era deliberadamente visível: as questões não eram discutidas, e a autenticação futura era deixada a outros desenvolvimentos. Retirar a conta do remetente reduzia atrito, mas não substituía confiança.

A rota MIME trocava os observadores

Nem todo host tinha IP direto, queria mais um daemon ou podia atravessar um firewall que só aceitava correio. A RFC permitia carregar UFT em MIME. Os comandos viravam parâmetros de application/octet-stream; o corpo binário seguia em Base64.

MIME resolvia representação e passagem por correio. Não decidia que o destinatário UFT aceitara o arquivo. Também mudava a prova: em vez de herald, ACKs e rajadas diretas, apareciam estados de armazenamento e encaminhamento do mail. A autenticação, quando houvesse, pertencia ao sistema de correio.

SIFT/UFT continuou Experimental. A RFC 1499 preservou essa classificação. O registro atual da IANA conserva sift-uft na porta 608, fato administrativo que não mede implantação nem uso.

A palavra “recebido” precisava de sujeito

O valor histórico da RFC 1440 está na sequência de sujeitos. O remetente inicia. O listener admite. O host recebe. O spool guarda. O destinatário aceita ou recusa. Uma aplicação pode agir depois. Cada verbo pede evidência própria.

O registro defensável liga peer e herald, comandos e ACKs, tamanho anunciado e real, representação, hash, finalização, localização no spool, vencimento, procura do destinatário, disposição e resultado. Só assim a chegada física não ocupa indevidamente o lugar da aceitação.

Fontes