Resumo

  • A RFC 2449 introduziu CAPA para que clientes POP3 descobrissem extensões e comportamentos de maneira estruturada, em vez de depender apenas de tentativas de comando ou de erros em texto livre.
  • A lista era evidência limitada ao estado da sessão, não uma permissão ou recibo de sucesso; podia mudar com autenticação, política por usuário e proteção de integridade.

“O que este servidor consegue fazer?” parece uma pergunta única. No POP3, a resposta dependia do contexto. Comandos opcionais, métodos de autenticação e comportamentos do servidor variavam, mas clientes muitas vezes descobriam isso tentando comandos, interpretando mensagens destinadas a pessoas ou pedindo ajustes manuais de compatibilidade. Publicada em novembro de 1998 como atualização Standards Track da RFC 1939, a RFC 2449 acrescentou CAPA: um inventário legível por máquina que o cliente podia consultar antes de escolher uma extensão.

Esse inventário não virou um perfil imutável do servidor. CAPA está disponível nos estados AUTHORIZATION, antes do login, e TRANSACTION, depois da autenticação. Cada definição de capacidade deve dizer em quais estados é anunciada e em quais estados seus comandos são válidos. Uma capacidade disponível antes da autenticação precisa ser anunciada nos dois estados; ainda assim, os argumentos podem ficar mais específicos depois que o servidor conhece o usuário. O nome, o valor e a ação que ele habilita são fatos relacionados, não equivalentes.

LOGIN-DELAY e EXPIRE mostram por que o primeiro valor pode ser conservador. Se LOGIN-DELAY variar por conta, antes da autenticação o servidor deve anunciar o maior intervalo possível e, depois, deve fornecer ao usuário autenticado um valor mais preciso. EXPIRE representa um período mínimo de retenção garantido, não a data em que uma mensagem específica desaparecerá. Quando a política varia por usuário, o valor pré-autenticação deve ser o menor possível; após o login o servidor deve refiná-lo. Sem conhecer a conta, a resposta ampla protege contra uma promessa favorável demais.

A autenticação também pode alterar o contexto de segurança. A RFC 2449 recomenda repetir CAPA se a autenticação negociar uma camada de integridade, para verificar uma possível degradação ativa. A RFC 5034 depois explicita o limite para camadas de segurança SASL: o cliente descarta as informações do servidor que havia aprendido antes, incluindo a lista antiga. Informação obtida fora do contexto protegido não se transforma automaticamente em evidência dentro dele.

Nem uma lista positiva garante que cada usuário possa executar cada ação. USER anuncia suporte a USER e PASS, mas a RFC 2449 observa que esses comandos podem não estar disponíveis para todos. Um mecanismo SASL listado ainda pode falhar por causa das credenciais ou da política local; um login bem-sucedido pode não conseguir abrir a caixa postal. Se CAPA responde -ERR, o mecanismo de descoberta não existe e o cliente precisa voltar às tentativas de antes. A nova consulta reduz o chute sem apagar a incerteza herdada.

A RFC 2449 também criou códigos de resposta estruturados, para que o software não deduzisse cada falha do texto livre. Detalhes desconhecidos devem ser ignorados, preservando uma base comum durante a evolução das extensões. O documento também alerta que a lista pode revelar mecanismos de autenticação, embora a descoberta automática ajude a escolher um método mais forte. Informação legível traz valor operacional e custo de divulgação.

A contribuição, portanto, não foi prometer que servidores POP3 seriam intercambiáveis nem declarar o fim das tentativas. Foi limitar o que o servidor pode afirmar, em qual estado e sob as regras de cada extensão. A lista orienta a decisão seguinte; só o próximo comando, sua resposta e uma observação posterior da caixa mostram o que aconteceu. O status do RFC e uma entrada no registro da IANA não provam implementação ou adoção universais.

Fontes

RFC 2449; registro da RFC 2449; erratas da RFC 2449; RFC 1939; RFC 1957; RFC 5034; RFC 1734; RFC 4422; registro IANA de extensões POP3; RFC 2384; Heng Lu, primazia do código em execução; Heng Lu, especificação inicial mínima e adoção voluntária.