Resumo

  • A seção 6.5 de draft-ietf-emailcore-as-30 pede que receptores SMTP sejam capazes de aceitar mensagens com e sem confidencialidade de transporte, mas afirma que a ação de cada parte numa situação específica é matéria de política local. O documento continua um Internet-Draft em «AD Followup», não um RFC.
  • A revisão 29 dizia que receptores não deveriam exigir confidencialidade dos emissores. Participantes da revisão pública de setembro discutem se o novo requisito de capacidade acrescenta algo útil ou pode ser confundido com uma ordem para operar em claro. Não há desfecho final do IESG demonstrado por essas mensagens.

O campo «aceita correio sem TLS?» parece admitir resposta binária. Na prática, pode significar três perguntas: o software entende o protocolo nessa condição, a configuração do servidor abre essa rota e a política do operador autoriza determinada conexão. Em uma instalação privada, a segunda ou a terceira resposta pode ser negativa mesmo que a primeira seja positiva. A revisão da aplicabilidade do correio básico trouxe essa diferença para uma frase normativa.

Na versão 30, a seção 6.5 primeiro determina que emissores SMTP usem confidencialidade quando ela estiver disponível e for aceita pelo receptor. Em seguida, diz que receptores devem ser capazes de aceitar correio com ou sem confidencialidade. A própria seção ressalva que as escolhas numa circunstância particular cabem à política local. Na versão 29, a redação voltada ao receptor era outra: não exigir confidencialidade de quem envia. O registro de mudanças do rascunho atribui a reformulação da seção 6 ao exame do IESG.

Uma proibição dirigida ao comportamento de recepção foi trocada por uma exigência sobre capacidade de implementação, acompanhada da ressalva operacional. Isso não cria um novo protocolo de cifragem nem torna o texto definitivo.

O procedimento ainda está aberto. A página da IETF identifica a edição 30 como Internet-Draft ativo, em «AD Followup». Votos DISCUSS continuam visíveis; alguns se referem à edição anterior e não versam todos sobre o mesmo trecho. Em 18 de setembro, John Klensin disse a Roman Danyliw que parte de sua explicação tinha caráter pessoal e não havia passado pelo grupo de trabalho.

Em 28 de setembro, Eric Rescorla argumentou que um requisito sem efeito adicional deveria sair da norma; Rob Sayre respondeu insistindo na diferença entre o que uma implementação suporta e o que o administrador decide exigir, inclusive com a expectativa de mais exigências de TLS. São posições atribuídas, não um consenso formal ou levantamento de configurações em produção.

Há uma regra publicada que não pode ser omitida. O RFC 3207 trata de STARTTLS e diz que um servidor SMTP referenciado publicamente não deve exigir seu uso para entrega local; um servidor sem referência pública pode exigir a negociação. O alcance é definido. A regra não autoriza concluir que qualquer serviço precise admitir toda ligação desprotegida, e tampouco equivale à proposta mais geral sobre a capacidade de um receptor no EMAILCORE. Misturar as duas coisas esconderia justamente a diferença de camadas que está sendo examinada.

O RFC 8689 ocupa uma quarta camada. REQUIRETLS permite impor, para uma mensagem específica e por relés compatíveis, uma exigência de confidencialidade que pode levar à falha da entrega em vez de cair para texto em claro. BTW já noticiou essa decisão a partir da mensagem. Ela não responde se o programa receptor genérico deve conservar um caminho capaz de processar correio sem proteção. Uma condição carregada pela mensagem, uma limitação do MX público, uma capacidade do produto e uma regra local para a sessão são objetos distintos de governança.

Documentos de aplicabilidade importam porque orientam testes de conformidade, respostas de fornecedores e políticas de compra. Um fabricante pode manter uma função desativada por padrão; um operador pode exigir TLS sem fingir que a função deixou de existir. Se «deve ser capaz» for lido como «deve permitir sempre», uma escolha de segurança muda de mãos sem decisão explícita. Se a função for removida completamente do produto, um caso excepcional de interoperabilidade talvez dependa de atualização e não de configuração. As fontes não quantificam esses efeitos nem relatam falha real de entrega provocada por esta edição.

O ponto em aberto é qual garantia deve ser comum a implementações e qual continua opcional ao operador.

Fontes