Resumo

  • O número de uma mensagem era atribuído quando o servidor abria o maildrop atual. LAST guardava apenas o maior número acessado, uma fronteira incapaz de reconhecer cada mensagem retida depois que a lista mudava.
  • A RFC 1725 retirou LAST e acrescentou UIDL como comando opcional. A RFC 1939 exigiu que o UID persistisse entre sessões dentro de um maildrop, enquanto o cliente mantinha sua própria memória de itens já processados, sem confundir identidade com retenção.

Baixar e apagar exige pouca lembrança. O cliente recebe a mensagem, marca a posição com DELE e termina com QUIT; ao entrar em UPDATE, o servidor remove o que foi marcado. Na próxima conexão, a lista restante é trabalho novo.

“Deixar mensagens no servidor” rompe essa equivalência. A mensagem já entregue ao computador continua no maildrop. Quando o cliente volta, precisa reconhecê-la sem supor que ocupa o mesmo número. Se apenas baixar tudo de novo, cria duplicatas; se confiar numa lembrança errada, pode ignorar uma mensagem ou apagar a única cópia segura.

O POP3 não resolveu isso criando pastas, flags sincronizadas ou um estado de leitura para cada dispositivo. Deu ao servidor uma obrigação menor: associar cada item a um token que sobrevivesse à desconexão. Coube ao cliente registrar o que fez com esse token.

O número era um endereço para a sessão, não um nome duradouro

A RFC 1460 descreveu o POP3 para estações menores, nem sempre conectadas, que dependiam de um servidor para manter o correio em um maildrop. Depois de abrir e analisar esse conjunto, o servidor numerava a primeira mensagem como 1, a segunda como 2 e assim por diante.

Esses números eram bons operandos para LIST, RETR e DELE. Eram curtos e descreviam exatamente a posição corrente. Mas uma remoção anterior deslocava todos os números seguintes. A mensagem que era 2 na segunda-feira podia ser 1 na terça-feira, sem ter mudado de conteúdo.

A mesma RFC oferecia LAST. O servidor devolvia o maior número acessado em transações anteriores. O cliente podia tratar números maiores como ainda não acessados; recuperar ou marcar para exclusão um número maior avançava a fronteira, e RSET a devolvia a zero.

Uma fronteira única comprime o passado, mas só representa uma sequência sem buracos. Ela não distingue “1 e 3 já foram salvas, 2 não”. Não separa a memória de dois computadores. Um reset apaga a progressão. A remoção de mensagens inferiores muda o significado das posições superiores.

A RFC 1725 registrou duas mudanças lado a lado: LAST foi removido e UIDL foi acrescentado como opção. O texto não declarou que uma foi a causa exclusiva da outra, mas o modelo mudou. Em vez de um único ponto máximo mantido pelo servidor, cada item recebeu um token a partir do qual cada cliente podia formar seu próprio conjunto de vistos.

UIDL ligou o número de agora ao registro de antes

Com um argumento, UIDL devolve o número atual e o unique-id daquela mensagem. Sem argumento, lista esse par para cada mensagem que ainda não está marcada como excluída.

As duas colunas têm validades diferentes. O número diz qual item usar em RETR ou DELE nesta transação. O UID permite comparar a linha atual com o registro que o cliente guardou de outra sessão.

A RFC 1939 define o UID como uma cadeia arbitrária escolhida pelo servidor, com um a setenta caracteres imprimíveis. Ela identifica uma mensagem dentro de um maildrop e persiste entre sessões. Deve continuar igual mesmo se a sessão anterior terminou sem entrar em UPDATE.

Essa última regra é essencial em uma conexão imperfeita. O cliente pode ter recebido e armazenado a mensagem antes de cair. Sem QUIT e UPDATE, o servidor não pode executar a exclusão marcada, portanto o item reaparece. Se o UID também mudar, o cliente perde a única pista de que já processou aquela mensagem.

O servidor não deve reutilizar o UID no mesmo maildrop enquanto o item que o usa existir. Reutilizar faria uma entrada nova herdar o passado de outra no banco local do cliente.

O servidor atribuía continuidade; o cliente definia “já visto”

UIDL não registra que uma mensagem foi lida, exibida, arquivada ou gravada com sucesso. O servidor fornece o token. O cliente decide qual evento conta como concluído para seu usuário e conserva o resultado em armazenamento local.

Essa divisão manteve o servidor simples. Cada dispositivo podia ter seu próprio conjunto de UIDs conhecidos. Uma conexão intermitente comparava uma lista pequena antes de escolher quais corpos recuperar. O POP3 não precisava se tornar um gerenciador remoto completo de caixa postal.

Mas a simplicidade central transferiu risco. Se o cliente perde sua base de UIDs, volta a baixar mensagens retidas. Se uma migração preserva os corpos e regenera os identificadores, todos os itens parecem novos. Se o cliente marca o UID como concluído antes de confirmar a gravação local, uma exclusão posterior pode transformar um erro de contabilidade em perda definitiva.

Por isso, uid_listed, retrieval_completed, stored_locally, delete_marked, update_committed e session_aborted são estados diferentes. Uma resposta UIDL bem-sucedida não prova nenhum dos resultados posteriores.

“Unique” tinha escopo e admitia multiplicidade

O UID não é um identificador global. A mesma cadeia em outra conta, servidor ou maildrop não tem relação definida. Ela não é o cabeçalho Message-ID, não autentica remetente ou destinatário e não comprova entrega, integridade ou conteúdo.

A RFC 1939 recomenda em geral IDs arbitrários armazenados, mas permite calculá-los como hash da mensagem. Em consequência, exige que clientes lidem com duas cópias idênticas no mesmo maildrop que tenham o mesmo UID.

Um banco local que usa “um UID, uma linha” pode juntar silenciosamente duas cópias reais. O cliente precisa preservar também a multiplicidade observada e os números atuais. O token responde a uma pergunta de reconhecimento ao longo do tempo; nem sempre responde quantas cópias indistinguíveis estão armazenadas agora.

O limite evita uma escalada comum de linguagem. Único não significa universal, persistente não significa eterno e identidade não significa autenticidade. UIDL era forte o bastante para reconhecer itens no mesmo maildrop entre visitas, e deliberadamente não era mais do que isso.

Persistência do UID e retenção da mensagem eram relógios distintos

Manter o mesmo UID enquanto o item existe não obriga o servidor a mantê-lo para sempre. A RFC 1939 alertou que deixar mensagens lidas no servidor pode acumular centenas ou milhares de itens. Um operador pode impor cotas e políticas de retenção, inclusive removendo correio fora do fluxo POP3.

Se um UID antigo desaparece, o cliente não pode concluir apenas com isso que a mensagem foi apagada com segurança depois de armazenada. Outro cliente pode tê-la removido, a política local pode ter expirado o item ou a listagem pode ter falhado.

A RFC 2449 introduziu CAPA porque recursos opcionais antes precisavam ser descobertos por tentativa. A linha UIDL anuncia suporte ao comando. Ela não mede a qualidade dos tokens nem garante retenção.

O mesmo documento definiu EXPIRE, que pode anunciar um mínimo de dias, zero ou NEVER. Mesmo assim, não informa o instante exato de expiração de uma mensagem específica. O servidor pode iniciar a contagem na chegada, na primeira listagem, na recuperação ou em outro marco.

Capacidade, reconhecimento e retenção são evidências separadas. CAPA diz que o comando existe; UIDL relaciona o item atual ao passado; EXPIRE descreve uma política de vida. Nenhuma substitui as outras.

A memória que tornou “deixar no servidor” operacional

UIDL não eliminou a fragilidade de conexões nem sincronizou caixas completas. Fez algo mais estreito: deu ao cliente uma forma de reconhecer mensagens retidas sem transformar o número corrente em um nome permanente.

Seu valor histórico está na alocação precisa de responsabilidade. O servidor preserva um token de escopo local. O cliente preserva o significado de “eu já tratei isto”. O operador controla quanto tempo a mensagem continua servida. Quando esses três papéis são confundidos, surgem duplicatas, omissões e exclusões destrutivas.

O número vive pela sessão. O UID vive o bastante para atravessar a reconexão. O registro de uso vive no cliente. Essa separação permitiu que um protocolo concebido para baixar e apagar suportasse, com limites visíveis, a prática de deixar correio no servidor.

Fontes