Resumo

  • STARTTLS protegia uma conexão SMTP, enquanto a mensagem continuava em filas e atravessava novas conexões. O RFC 8689 transformou a preferência do remetente numa obrigação guardada com a mensagem e repetida em cada retransmissor compatível.
  • Se nenhum MX oferece TLS autenticado e anuncia REQUIRETLS depois da negociação, o MTA não pode transmitir em claro: deve produzir uma notificação de não entrega, também protegida. A extensão não cifra de ponta a ponta e continua confiando nos servidores intermediários.

Uma notificação de falha não é vazia. Ela costuma carregar os cabeçalhos da mensagem que não chegou. Endereço do remetente, destinatários, assunto e detalhes de rota podem voltar junto com o diagnóstico. Se o envio original proibiu texto aberto, uma notificação desprotegida abre uma saída lateral para a mesma informação.

Por isso, a história de REQUIRETLS pode ser contada de trás para frente. Primeiro, o protocolo teve de reconhecer que até o fracasso possui um caminho de transporte. Depois, precisou fazer a decisão de segurança sobreviver às filas, às novas tentativas e aos vários servidores que formam o percurso normal do correio eletrônico.

O resultado não foi uma nova cifra. Foi uma regra por mensagem: quando a condição não pode ser preservada, falhar é mais correto do que mudar silenciosamente o acordo.

STARTTLS acabava quando a conexão acabava

Em 1999, o RFC 2487 introduziu STARTTLS no SMTP. O correio público dependia de interoperabilidade ampla, e tornar TLS obrigatório em todos os MX de uma vez teria bloqueado muitos destinos. A entrega continuou sendo a prioridade padrão; a proteção podia ser oportunista.

O RFC 3207 substituiu aquela especificação em 2002. O servidor anuncia STARTTLS, o cliente envia o comando e a resposta 220 abre a negociação TLS. Depois dela, os dois lados descartam tudo que aprenderam em texto aberto e o cliente envia EHLO novamente. A segunda lista de capacidades nasce dentro do canal protegido.

Essa reinicialização impede que uma declaração alterável governe a sessão segura. Mas ela só governa aquela sessão. SMTP recebe, armazena e repassa: o servidor pode aceitar a mensagem, fechar a conexão, mantê-la horas numa fila e abrir outra conexão como cliente. A decisão de ontem não acompanha automaticamente o arquivo de hoje.

Políticas do domínio de destino preencheram parte da lacuna. O RFC 7672 definiu DANE para SMTP com TLSA autenticado por DNSSEC. O RFC 8461 definiu MTA-STS, política entregue por HTTPS e armazenada em cache para exigir TLS, identidade de certificado e padrões de MX. Elas exprimem a vontade do destinatário. Ainda faltava ao originador distinguir uma mensagem sensível das demais.

Uma palavra no envelope virou estado persistente

O RFC 8689, de 2019, registrou REQUIRETLS como capacidade EHLO e como parâmetro sem valor no comando existente:

MAIL FROM:<sender@example> REQUIRETLS

Não surgiu um verbo novo. A escolha do envelope é importante porque ele governa a transferência presente. O parâmetro só pode ser usado quando a sessão já emprega TLS, o nome do MX foi validado por DNSSEC ou MTA-STS, o certificado foi autenticado por cadeia confiável ou DANE e o servidor anunciou REQUIRETLS no EHLO posterior ao STARTTLS.

Uma promessa vista apenas antes da criptografia não basta. O segundo anúncio confirma que o servidor que realmente terminou a negociação aceita a responsabilidade adicional.

Ao receber a mensagem, o MTA deve marcá-la para tratamento REQUIRETLS. O padrão não determina tabela, bit ou arquivo; determina o comportamento. Quando esse MTA se tornar cliente no próximo salto, terá de reconstruir as provas e emitir o mesmo parâmetro.

Se um alias local dividir a mensagem entre vários endereços, todas as cópias recebem a marca. A exigência não fica presa à conexão nem se perde porque o roteamento interno multiplicou destinatários.

“Usou TLS” escondia perguntas diferentes

O próximo retransmissor é escolhido pelas regras do RFC 5321. Se o MX não veio numa resposta DNSSEC válida, MTA-STS precisa limitar o nome aceitável. O cliente estabelece TLS, valida o certificado e, já protegido, confere a publicidade REQUIRETLS.

Cada etapa prova algo próprio. A cifra protege os bytes em trânsito. Certificado ou DANE relaciona a chave a uma identidade. DNSSEC ou MTA-STS impede que qualquer host com certificado legítimo se apresente como o destino. A publicidade final mostra que o próximo guardião sabe preservar a marca.

Uma conexão criptografada para o MX errado não satisfaz a regra. Um certificado correto num servidor que esquece REQUIRETLS também não. Telemetria que comprime tudo em “TLS: sim” perde o mecanismo de autorização.

O retransmissor percorria os MX, mas não até o texto aberto

Se o primeiro MX falha, o cliente encerra a tentativa e passa ao seguinte. Ele ainda pode entregar mensagens sem a marca ao mesmo servidor. REQUIRETLS não transforma um domínio inteiro numa categoria fixa; duas mensagens na mesma fila podem receber resultados distintos.

Quando nenhum MX atende, a mensagem marcada não é transmitida ao domínio. O RFC sugere 5.7.30 quando falta suporte REQUIRETLS e 5.7.10 quando a sessão TLS exigida não pode ser criada. O MTA então gera uma notificação para o caminho de retorno.

Essa consequência muda a direção do recuo. No TLS oportunista, uma falha de segurança pode abrir uma rota menos segura para manter a disponibilidade. Com REQUIRETLS, a mesma falha retira a autorização de enviar. A não entrega passa a ser a execução correta da preferência, não apenas um defeito.

Há custo operacional. Certificado expirado, política indisponível ou MX secundário antigo podem deter uma carta tecnicamente entregável. A extensão não resolve magicamente o conflito entre alcance e confidencialidade. Ela permite que o remetente escolha e exige que o retransmissor não esconda o preço.

A notificação de falha precisava carregar a mesma obrigação

Qualquer notificação de falha causada por mensagem REQUIRETLS deve usar REQUIRETLS, mesmo quando o erro original não tem relação com TLS. O motivo é o conteúdo diagnóstico. Para limitar exposição, a notificação se comporta como se a opção DSN RET=HDRS estivesse presente; RET=FULL é ignorado e o corpo completo não deve voltar por uma rota incerta.

O SMTP usa caminho de retorno vazio nas notificações para evitar ciclos de erros. Esse detalhe cria uma exceção. O caminho de volta pode não oferecer REQUIRETLS, e a notificação vazia não pode gerar outra notificação. O RFC avisa que o diagnóstico protegido talvez se perca e recomenda que a ausência de publicidade no próximo salto não faça esse diagnóstico ser simplesmente descartado pela mesma regra comum.

Assim, silêncio não comprova sucesso. A mensagem original pode ter sido corretamente retida e a explicação pode ter falhado no retorno. Operadores precisam separar falha da carta e falha do seu recibo negativo.

A exceção TLS-Required: No tentava avisar sobre uma falha

O mesmo padrão criou o cabeçalho TLS-Required: No. Ele serve para pedir que o retransmissor não deixe a política DANE ou MTA-STS do destinatário bloquear a entrega. Um uso é avisar o administrador de que o certificado está quebrado, sem deixar o próprio defeito impedir o alerta.

Isso não ordena texto aberto. O cliente ainda deve tentar STARTTLS quando disponível. O No altera o que fazer após a falha de negociação ou validação. E o servidor destinatário mantém o poder de recusar conexões não protegidas; o remetente não pode obrigá-lo a aceitar.

Se o parâmetro REQUIRETLS do envelope também aparecer, ele vence e o cabeçalho é ignorado no tratamento. Mais de um cabeçalho do tipo é proibido. Conteúdo potencialmente manipulável não pode enfraquecer uma obrigação assumida no envelope protegido.

Repassar uma carta não era o mesmo que originar outra

Um retransmissor comum salva a marca e a repete. Lista de discussão, encaminhador, regra Sieve ou resposta automática pode produzir outra mensagem. Cabeçalhos e destinatários mudam; a antiga transação já acabou. O RFC pede que mediadores apliquem a escolha recebida à nova mensagem na medida do possível.

A ressalva é material. Uma lista pode expandir para domínios com capacidades diferentes; manter REQUIRETLS pode impedir entrega a parte dos assinantes. Um filtro executado no lado do usuário talvez nunca veja metadados do envelope. Nesse ponto, a cadeia deixa de ser puramente mecânica e surge uma nova decisão editorial ou administrativa.

O protocolo não declara automaticamente quem ainda retransmite e quem virou novo originador. Ele torna visível o local onde a responsabilidade precisa ser reassumida.

A proteção terminava na confiança dada ao MTA

REQUIRETLS é transporte salto a salto, não criptografia de conteúdo de ponta a ponta. Cada MTA encerra TLS, lê a mensagem e inicia outra conexão. Um retransmissor malicioso pode fingir suporte e retirar a marca. O RFC coloca esse ator fora do modelo porque ele já recebeu o texto aberto.

A extensão ajuda contra escuta passiva, retirada de STARTTLS, substituição de MX e downgrade acidental entre servidores conformes. Não autentica o autor humano, não cifra a fila em repouso, não oculta conteúdo dos intermediários e não prova o restante do percurso.

O registro SMTP da IANA comprova o token REQUIRETLS e sua referência normativa. Não mede adoção, tráfego nem comportamento de produto.

A contribuição histórica é uma memória de decisão. Conexões acabam; mensagens ficam. REQUIRETLS permitiu que “não envie sem estas provas” permanecesse no objeto, reaparecesse no próximo envelope e convertesse a impossibilidade em falha explícita. O correio escolheu não chegar de uma maneira que o remetente não havia autorizado.