Resumo

  • O IMAP define \Seen como “a mensagem foi lida”, mas o evento observável é um estado mutável da caixa: BODY[...] pode defini-lo implicitamente, BODY.PEEK[...] recupera conteúdo sem fazê-lo e clientes autorizados podem adicionar ou remover o marcador.
  • Uma afirmação sobre leitura humana precisa unir principal, cliente, geração da caixa postal, UID, comando, marcadores antes e depois, resposta do servidor e evento de interface. O bit isolado não prova atenção, compreensão, consentimento nem resposta.

Um verbo humano dentro de uma máquina de estados

Mark Crispin criou o IMAP para manter as mensagens no servidor e permitir acesso por clientes e lugares diferentes. O memorial de Stanford registra que ele inventou o protocolo enquanto trabalhou ali como programador de sistemas, de 1977 a 1988. Seu perfil no IETF reúne 25 RFCs, entre elas a RFC 3501, referência duradoura do IMAP4rev1. O Unicode Consortium, para o qual também contribuiu por anos, lembra-o como especialista em correio eletrônico e pai do IMAP.

A RFC 3501 descreve \Seen de modo direto: a mensagem foi lida. A RFC 9051 preserva a semântica no IMAP4rev2. O termo dá aos clientes um estado interoperável; não transforma o servidor em observador de olhos, atenção ou entendimento. As especificações distinguem a pessoa, “user”, do software, “client”.

O servidor recebe comandos, entrega dados e mantém atributos. A afirmação confiável é estreita: naquele instante, a caixa contém o marcador padronizado de leitura. Para falar sobre uma pessoa, é preciso reconstruir a origem do bit.

FETCH escreve; PEEK evita a escrita implícita

Quando um cliente pede uma parte do corpo com BODY[...], as RFCs 3501 e 9051 determinam que \Seen seja definido implicitamente. Se houver mudança, o servidor informa os novos flags. A recuperação também produz uma escrita de metadado.

BODY.PEEK[...] recupera a mesma seção sem definir \Seen por efeito implícito. Assim, o corpo pode ser obtido com ou sem mudança; um STORE pode marcar como visto sem buscar o corpo; outra operação pode apagar o marcador depois da busca.

Essas opções sustentam prévias, filas para ler depois e sincronização. Também demonstram que o bit não é um sensor humano. Indexação, filtro, cache ou geração de prévia podem buscar conteúdo — cenários possíveis, não acusações a um produto. No sentido inverso, um cliente pode exibir dados obtidos com PEEK e manter a caixa como não lida. A prova do servidor termina no comando e no efeito.

A mensagem pode entrar já vista

APPEND aceita flags iniciais, e as RFCs mostram exemplos de mensagens adicionadas com \Seen. Nesse caso, o bit descreve o estado de entrada, não prova que uma pessoa leu a nova cópia depois de armazenada.

STORE pode adicionar ou remover o marcador. “Marcar todas como lidas” não precisa exibir os corpos; “marcar como não lida” pode apagar o bit após uma leitura cuidadosa. Em caixa delegada ou aberta por vários clientes, outro ator autorizado pode ter produzido o estado observado mais tarde.

Portanto, “não lida” não significa “jamais lida por alguém”. Significa apenas que \Seen está ausente agora. Uma busca, uma reversão manual, uma corrida de sincronização ou um flag inicial podem ter desaparecido da fotografia atual.

A autorização altera o rastro

A RFC 4314 reserva o direito s para mudar \Seen. Um FETCH que normalmente o definiria não pode fazê-lo quando o usuário atual não possui esse direito. STORE verifica a mesma autorização.

Duas identidades podem recuperar o mesmo corpo e deixar rastros persistentes diferentes. Uma sessão grava o bit; outra é impedida pela política. A ausência pode provar uma fronteira de acesso, não a ausência de exibição.

Implementações também podem ter modelos de flags compartilhados ou não compartilhados. A pergunta completa é: estado de quem, em qual modelo de caixa e escrito sob qual direito? Caixa pessoal, atendimento compartilhado e delegação executiva não geram a mesma evidência só porque mostram o mesmo nome.

Ordem de alteração não revela causa humana

A RFC 7162 acrescenta CONDSTORE e QRESYNC. Mod-sequences permitem detectar estado mais novo, atualizar caches e condicionar STORE com UNCHANGEDSINCE. Uma gravação antiga pode falhar em vez de sobrescrever silenciosamente uma mudança concorrente.

Mas MODSEQ é recibo de ordem, não depoimento. Sozinho, não distingue FETCH implícito, STORE, outro cliente ou agente externo; tampouco mostra tela ou atenção. A RFC 8621 leva o conceito ao JMAP com $seen, palavra-chave que um usuário autorizado pode adicionar ou remover. Sincronização consistente prova o estado replicado, não amplia o que ele observou.

Montar a leitura com recibos separados

Um registro defensável preserva principal autenticado, delegação, instância do cliente e sessão. Liga a geração da caixa por UIDVALIDITY ao UID da mensagem. Depois nomeia a causa — BODY FETCH, PEEK, STORE, APPEND, sincronização ou agente externo — e guarda seção pedida, flags anteriores e resultantes, resposta, horário e MODSEQ disponível.

Exibição na interface é outro evento; confirmação humana é mais um. O registro pode dizer: “corpo buscado; Seen definido implicitamente; exibição desconhecida; sem confirmação”. É menos simples que “lido”, porém não inventa uma testemunha.

Crispin tornou o estado da caixa interoperável. Cabe às instituições impedir que esse estado fale por uma pessoa que o protocolo nunca observou.

Fontes