Resumo

  • O SMTP AUTH levou uma negociação SASL para antes da transação de correio, permitindo que o servidor de submissão desse retransmissão a uma identidade autenticada e autorizada, em vez de confiar apenas no endereço de rede.
  • O êxito era um fato daquela fronteira: identidade de autenticação, identidade de autorização, remetente do envelope, autor visível, conteúdo e rota continuavam sendo afirmações diferentes.

Um endereço de origem não era uma identidade móvel

O SMTP nasceu para transportar correio entre máquinas que cooperavam. Um servidor recebia mensagens para seus domínios e, conforme a política local, encaminhava outras. Quando a capacidade de alcançar um servidor público bastava para retransmitir a qualquer destino, o serviço virava um open relay.

Restringir a retransmissão ao IP da rede de acesso resolvia um problema e criava outro. Um assinante legítimo perdia o direito ao viajar, enquanto uma máquina situada numa faixa autorizada não era necessariamente a pessoa que podia usar determinado remetente. O POP-before-SMTP emprestava uma autenticação recente de outro protocolo, mas unia sessões por endereço e prazo, não pela própria ação de submeter a mensagem.

A extensão de autenticação publicada em 1999 e substituída pela RFC 4954 inseriu a decisão no SMTP. O servidor anunciava AUTH e mecanismos SASL na resposta a EHLO; o cliente escolhia um mecanismo e concluía a troca antes de MAIL FROM. O resultado não era uma assinatura. Era um fato operacional: o servidor aceitara uma autenticação e calculara, segundo sua política, uma identidade de autorização.

Esse fato podia abrir a retransmissão. Não podia dizer quem escreveu o texto.

SASL separou duas perguntas sobre a conta

Na SASL, a identidade de autenticação pertence à credencial verificada. A identidade de autorização é aquela em nome da qual o cliente pede para atuar. Mesmo depois de conferir a credencial, o servidor precisa decidir se a primeira pode assumir a segunda.

Uma fila pode se autenticar como serviço e transportar mensagens de muitos usuários. Uma assistente pode ter delegação para uma caixa, mas não para outra. Uma credencial comprometida pode ser válida e ainda assim pedir um escopo que nunca recebeu. Por isso o nome de login não se transforma automaticamente em MAIL FROM, no cabeçalho From nem no autor humano.

Autenticação responde “quem estabeleceu esta sessão por este mecanismo?”. Autorização responde “o que esse principal pode fazer aqui?”. Envelope e conteúdo apresentam perguntas posteriores. Um registro que reduz tudo a um único campo de usuário destrói a separação que o protocolo tornou observável.

A porta de submissão ganhou política própria

A RFC 6409 distinguiu a submissão, do agente do usuário para um Message Submission Agent, da transferência entre MTAs. Na porta 587, o MSA recebe uma nova mensagem, rejeita ou corrige certos erros locais e então a entrega à rede de transporte.

Por padrão, um MSA deve recusar MAIL com exigência de autenticação quando a sessão não tem SMTP AUTH nem outra autorização independente, como uma sub-rede protegida. A norma não tenta autenticar todo par de MTA como se fosse um usuário. Ela concentra a admissão forte no ponto em que provedor e cliente têm uma relação direta.

O usuário itinerante deixa de depender do IP do provedor: autentica-se no serviço de submissão e recebe somente os direitos associados à conta. Ao mesmo tempo, o MTA de entrada continua aceitando correio para os próprios domínios sem oferecer retransmissão universal. A IANA coordena nomes de extensões e mecanismos; não decide se uma credencial pode representar o financeiro, uma lista ou um domínio.

TLS muda quais mecanismos são aceitáveis

Um mecanismo de autenticação não protege sozinho o segredo. A RFC 4954 impede que mecanismos que revelam senha sejam anunciados sem proteção suficiente e admite que um novo EHLO, depois de STARTTLS, apresente outra lista. Suporte a AUTH não é um único bit: estado TLS, certificado, mecanismo e tolerância do cliente a downgrade determinam o que é seguro.

A RFC 8314 depois tratou o texto claro como obsoleto para submissão e acesso e organizou o uso de STARTTLS na porta 587 e TLS implícito na 465. A criptografia protege a troca da credencial e o conteúdo daquele salto. Ainda não produz uma assinatura de autoria ponta a ponta.

AUTH=<> preserva uma ausência de prova

A RFC 4954 também definiu o parâmetro AUTH= em MAIL FROM para carregar a identidade alegada do submetente original. Se o servidor não consegue determiná-la de modo confiável, usa AUTH=<>. Não deve preencher a lacuna com a própria identidade e converter desconhecimento em certeza.

Somente servidores dentro de uma relação confiável devem repassar essa afirmação. Os tipos ESMTPA e ESMTPSA registrados pela RFC 3848 significam que a recepção naquele salto usou autenticação, ou autenticação e TLS. Não certificam o caminho completo nem o autor.

O desenho funciona porque uma autenticação bem-sucedida continua menor que uma assinatura. Ela pode abrir o portão, selecionar uma política e deixar evidência de um salto. Não pode validar todos os campos, intenções, bytes e retransmissores seguintes.

Fontes