Resumo

  • A RFC 9755 separa o que o servidor anuncia do que o cliente autenticado habilita; nenhum desses fatos valida sozinho identidade, mailstore, índice e interface.
  • A aceitação deve terminar com uma mensagem controlada que o usuário consiga listar, buscar, recuperar, interpretar e usar.

Um teste pode ter êxito no ponto errado. Uma mensagem com cabeçalhos internacionalizados recebe OK no APPEND, mas o destinatário não a encontra pelo remetente, não abre uma mensagem anexada ou não a vê em um cliente oficialmente suportado. O servidor não mentiu. O recibo é que respondeu a uma pergunta menor.

A RFC 9755, Standards Track de março de 2025, substitui a RFC 6855 para IMAP4rev1; o IMAP4rev2 já traz capacidades semelhantes. UTF8=ACCEPT anuncia acesso a caixas com mensagens internacionalizadas e nomes UTF-8. UTF8=ONLY inclui essa capacidade e abandona o modified UTF-7.

Anúncio não é ativação

O cliente precisa autenticar e enviar ENABLE UTF8=ACCEPT. Isso também vale diante de UTF8=ONLY; não existe ENABLE UTF8=ONLY. Pela RFC 5161, ENABLED registra o que ficou ativo. CAPABILITY não muda e não serve como recibo da sessão.

Guarde versão e modo do servidor, depois comando e resposta de cada cliente real. Uma tela de configuração sem vínculo com a conexão observada não prova nenhum deles.

Sintaxe não provisiona identidade

LOGIN não passa a aceitar usuário ou senha UTF-8. É necessário AUTHENTICATE, mas a RFC deixa claro que transportar a sequência legalmente não obriga o sistema de identidades a aceitar a conta. A prova separada verifica cadastro na fonte autorizada, autenticação de produção, mapeamento para a caixa correta e permissão em cada rota de acesso.

APPEND inicia a prova de armazenamento

Depois de ENABLE, o servidor deve aceitar cabeçalhos UTF-8 no APPEND; antes, deve recusar cabeçalhos de 8 bits. Esse par positivo e negativo é valioso, mas não certifica indexação ou leitura.

A revisão remove o antigo item APPEND UTF8 e observa que IMAP4rev1, IMAP4rev2 e JMAP não oferecem indicador confiável por mensagem sobre seu uso. O recibo útil preserva a entrada e seu hash, a resposta, o UID quando disponível e a recuperação posterior do mesmo objeto.

Nomes de caixa exigem vetores próprios. A RFC 9755 exige Net-Unicode e exclui controles específicos. A RFC 5198 explica NFC; a RFC 6532 recomenda NFC para cabeçalhos e desaconselha NFKC quando apaga diferenças de grafia. Igualdade visual, igualdade de bytes e igualdade na busca são promessas diferentes.

A documentação atual do Dovecot mostra um limite concreto: guardar nomes de caixa em UTF-8 é uma configuração separada, e alterá-la pode quebrar nomes não ASCII existentes. É um exemplo de produto, não um censo. Mostra que atualização do protocolo não executa uma migração de armazenamento.

BODYSTRUCTURE admite duas respostas corretas

Software que desconhece message/global pode tratá-lo como anexo desconhecido. No IMAP4rev1 habilitado, a RFC 9755 permite duas formas BODYSTRUCTURE e exige que o cliente aceite ambas; o IMAP4rev2 segue a RFC 9051. A errata 8697 corrige o termo para message/rfc822.

O corpus deve cobrir as duas formas rev1, a forma rev2, cabeçalhos aninhados e recuperação da parte bruta. Um ícone de anexo não prova interpretação correta.

Recuperar não é encontrar

Após ENABLE, SEARCH não leva parâmetro charset; SORT e THREAD devem usar UTF-8. Um cliente antigo pode listar e buscar de maneiras incompatíveis. Registre consulta e UIDs para formas compostas e decompostas, cabeçalhos, nomes de caixa e corpo.

O mesmo mailstore pode ser acessado por IMAP, POP, webmail e clientes diferentes. Recusar, avisar, ocultar ou criar um surrogate padronizado são políticas, não equivalência. Este texto não repete a tese já publicada sobre a custódia do original de um surrogate; exige um resultado declarado e observado em cada rota suportada.

O último recibo pertence ao usuário: ele vê a caixa, acha a mensagem, identifica as partes, abre o conteúdo e responde quando a política permite? As fontes provam a semântica dos padrões e uma fronteira de implementação, não a adoção de fornecedor. Na distinção de Heng Lu entre representação simbólica e realidade executável, a capacidade é representação; a mensagem utilizável é realidade. A cadeia normativa também inclui a internacionalização SMTP, a transformação de downgrade, o respectivo comportamento POP simplificado e a base IMAP4rev2. Esses textos limitam alegações de interoperabilidade; não convertem uma rota bem-sucedida em visibilidade universal.