Resumo

  • No SMTP de 1982, um servidor que recebia correio podia assumir a retransmissão e se tornar o emissor na próxima etapa.
  • O RFC 2505, de 1999, exigiu que o MTA pudesse recusar a retransmissão não autorizada: a saudação HELO e o endereço MAIL FROM eram fáceis de falsificar.

O porteiro da garagem escuta “sou amigo do dono” e entrega a chave de um caminhão cheio de cartas. O visitante escolhe o destino; a conta e as reclamações chegam ao proprietário. A rede de e-mail realmente precisava de motoristas entre sistemas diferentes. O desastre administrativo foi deixar qualquer estranho contratar o serviço em nome de quem pagava por ele.

O trabalho de retransmitir aparecia como parte legítima do SMTP descrito no RFC 821, em agosto de 1982. Um servidor receptor podia aceitar ou rejeitar uma mensagem que ainda seguiria para outro servidor. Se aceitasse, virava o emissor da etapa seguinte. O documento distinguia o endereço final da caixa postal do caminho percorrido entre máquinas. Essa diferença permitia que a carta atravessasse redes e sistemas heterogêneos.

Duas décadas de expansão tornaram a cortesia cara. O RFC 2505, publicado em fevereiro de 1999 como Best Current Practice 30, chamou o uso de um retransmissor sem permissão de apropriação de recursos e risco à reputação de seu operador. O software de transporte precisava ter a capacidade de controlar e recusar esse uso. A recomendação não retirava a função de levar cartas; exigia que alguém no volante soubesse para quem estava trabalhando.

O RFC examinou quatro elementos de uma conversa SMTP. O nome em HELO vem da boca do visitante e pode ser inventado. O endereço em MAIL FROM sofre o mesmo problema. RCPT TO indica o destinatário pretendido. O servidor também vê o endereço de rede da máquina que se conecta. Se o primeiro par autorizasse o transporte, bastaria ao passageiro fabricar um crachá e escolher o preço da corrida: zero.

A regra sugerida partiu das obrigações do próprio servidor. Aceite mensagens para domínios que ele atende ou encaminha por acordo. Aceite a retransmissão para um chamador autorizado pelo endereço de origem ou, quando o operador confia no DNS, pelo nome do host. Recuse os demais pedidos. O ponto central é o sujeito da autorização. O visitante pode declarar nomes; o operador decide quais destinos e clientes fazem parte do serviço que sustenta.

Nem o destino era sempre fácil de ler. O RFC 2505 mencionou rotas da forma @a,@b:, artifícios com % e caminhos UUCP com !. Uma verificação superficial poderia aprovar um endereço aparentemente local que ainda mandaria a carta para outro sistema. Havia também gateways legítimos com grafias estranhas. Antes de apertar a política, era preciso inventariar os algoritmos de encaminhamento em uso. Uma cancela que não entende o endereço real protege o atalho errado.

O RFC 2635, de junho de 1999, batizado DON'T SPEW, levou o mesmo assunto para dentro dos provedores. Recomendou não deixar servidores abertos à retransmissão de estranhos, escrever uma política de uso, verificar abuso antes de punir contas e manter endereços abuse e postmaster com gente para lê-los. O MTA fechava uma porta durante a sessão. A empresa precisava receber reclamações, distinguir culpados e assumir as consequências de uma decisão errada.

O RFC 5321, de outubro de 2008, registrou a tensão que continuou depois da cancela. O correio eletrônico carregava a expectativa antiga de entregar uma mensagem ou informar a falha. O volume de correio indesejado tornava certas rejeições e descartes parte da operação; sumiços silenciosos ameaçavam a confiança na entrega. O controle de acesso à retransmissão responde a uma pergunta. O destino de uma mensagem já aceita responde a outra.

O servidor continuou sendo mensageiro. Só deixou de considerar o “bom dia” de HELO uma procuração assinada. A mudança parece óbvia agora: quem cede capacidade e reputação decide quem pega carona. Em 1999, a Internet teve de escrever essa obviedade no manual do motorista.