Resumo
DELEsó marca a mensagem durante TRANSACTION, sob bloqueio exclusivo;RSETdesfaz todas as marcas antes da saída normal.- Apenas
QUITenviado pelo cliente em TRANSACTION entra em UPDATE. Uma queda anormal não pode apagar nada, embora UPDATE possa terminar com remoção parcial.
Uma linha interrompida não podia autorizar perda
Um computador discado baixa mensagens e pede a retirada dos originais. Antes de gravar a última no disco, a ligação cai. Se cada DELE destruísse imediatamente, a mesma falha que impediu a custódia local eliminaria a cópia remota.
O POP3 adiou o efeito. Depois de DELE, o número deixa de funcionar para os demais comandos daquela sessão, mas os dados continuam no maildrop. RSET remove as marcas. Só QUIT, no estado de trabalho, abre UPDATE e permite a tentativa física.
O servidor sabe que transmitiu octetos, não que o outro lado os armazenou. O fim normal é um sinal compartilhado, ainda que limitado. O silêncio do TCP e o timeout não recebem poder destrutivo.
O intervalo surgiu antes do nome POP3
O RFC 918, de 1984, separava RETR de RDEL; após receber os dados, o cliente enviava RCVD, e só então o servidor tentava excluir. RSET abortava e liberava corretamente a caixa.
No POP2, o RFC 937 fazia ACKD confirmar a recepção e marcar a mensagem. A mudança real esperava a liberação da caixa no fim da sessão ou na seleção de outra.
Os comandos mudaram, mas a distinção permaneceu: “o servidor enviou” e “o cliente possui uma cópia durável” são eventos diferentes numa rede intermitente.
Três estados organizaram a autoridade
O RFC 1081, primeiro POP3 em 1988, definiu AUTHORIZATION, TRANSACTION e UPDATE. Após autenticação, o servidor obtinha bloqueio exclusivo. O cliente listava, recuperava e marcava em TRANSACTION. QUIT levava a UPDATE, onde o servidor removia, soltava o bloqueio e fechava TCP.
AUTHORIZATION decide acesso; TRANSACTION mantém uma visão estável e reversível; UPDATE exerce o efeito irreversível. QUIT antes da autenticação apenas encerra, pois não existe transação autenticada a atualizar.
RSET, comando mínimo obrigatório, retira todas as marcas. Falta de espaço, erro de processamento ou mudança de preferência podem justificar a volta. O RFC 1725 esclareceu que o bloqueio impede modificações ou remoções antes de UPDATE, quando necessário.
O encerramento anormal preservava tudo
RFC 1725 também tornou explícito o caso quebrado: qualquer término que não seja QUIT do cliente não entra em UPDATE e não remove mensagens. O autologout por inatividade segue a mesma regra.
O RFC 1939, STD 53 de 1996, mantém a obrigação e explica que o cliente talvez não tenha recebido ou guardado o correio com sucesso. Não é prova do disco remoto; é uma escolha conservadora. Duplicata é reconciliável. A perda da única cópia pode não ser.
A porta de commit não era atomicidade
Em UPDATE, o servidor tenta remover tudo o que foi marcado. Se faltar recurso ou ocorrer outro erro, pode remover algumas, todas ou nenhuma mensagem. Nunca pode tocar uma não marcada. Depois libera o bloqueio e fecha a conexão, independentemente do resultado.
Assim, QUIT é uma porta de autorização, não um commit atômico. Antes dela, marcas são reversíveis e quedas preservam tudo. Depois, o resultado pode ser parcial; se a resposta final se perder, o cliente nem sabe qual subconjunto mudou.
Por isso +OK a DELE quer dizer “marca aceita”, não “cópia remota desapareceu”. A especificação preferiu admitir limites reais a prometer tudo-ou-nada para armazenamentos diversos.
A política posterior ainda passou por UPDATE
O RFC 2449 criou EXPIRE. EXPIRE NEVER anuncia que a política não apaga; EXPIRE 0 permite tratar mensagens recuperadas como implicitamente marcadas quando a sessão entra em UPDATE. A extensão muda a seleção, não transforma leitura ou queda em destruição imediata.
A despedida protegia custódia, não etiqueta
O cliente decide quando termina sua sequência; o servidor conhece o resultado do armazenamento; a rede só pode interromper. A incerteza fica do lado reparável: repetição e conferência, não desaparecimento silencioso.
Marcar, poder voltar, cruzar explicitamente, tentar remover e admitir parcialidade: a exclusão começava a ser real na despedida, mas o POP3 não fingia que a realidade sempre mudava de uma vez.
Fontes e limites
A origem está em RFC 918 e RFC 937; o POP3 surge em RFC 1081 e continua em RFC 1225 e RFC 1460. RFC 1725 esclarece a queda, RFC 1939 fixa a regra e a falha parcial, e RFC 2449 define EXPIRE. Eles não provam adoção atual, implementação de produto nem exclusão atômica ou exatamente uma vez.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
