Resumo

O domínio que aparece não é sempre o domínio testado

O endereço visível no cabeçalho de uma mensagem, o remetente informado durante a sessão SMTP e o nome enviado no comando EHLO podem apontar para identidades diferentes. Um encaminhamento comum basta para ampliar a distância entre elas. Se o domínio publica no DNS uma lista de máquinas autorizadas a enviar correio, o destinatário precisa decidir primeiro a qual identidade essa autorização se aplica.

Foi a primeira pergunta posta pela carta do grupo MARID, no IETF. Ela enumerou From e Sender nos cabeçalhos, MAIL FROM no SMTP e EHLO. O Sender ID buscava, com o algoritmo PRA, um endereço considerado responsável nos cabeçalhos. O SPF verificava a identidade da conversa SMTP. A semelhança das políticas no DNS escondia uma diferença decisiva no sujeito da checagem.

Uma licença gratuita com balcão obrigatório

A carta aberta da Apache não discutia apenas uma hipótese jurídica. SpamAssassin filtrava mensagens indesejadas; JAMES era um servidor de correio. A fundação disse que ambos ficariam sem Sender ID sob o acordo de patente então oferecido pela Microsoft, que ela considerava incompatível com a Apache License 2.0.

Segundo a Apache, as permissões de patente não passavam de forma adequada aos redistribuidores seguintes. Quem desejasse mudar a marca ou redistribuir uma implementação também teria de procurar a Microsoft. Essa exigência deslocava uma decisão comum do desenvolvimento aberto para o titular da patente. Código passa de mantenedor a empacotador, de empacotador a usuário e, muitas vezes, volta modificado. Um acordo que exige uma nova ida ao balcão em parte desse percurso pesa mesmo quando o recibo diz “sem royalties”.

A Apache podia dizer não para seus próprios projetos. Outros desenvolvedores podiam fazer escolhas diferentes. O registro mostra o limite de uma especificação pública: divulgar como fazer a verificação não resolve, por si só, os termos sob os quais o programa que a faz pode circular.

Duas experiências, uma advertência de entrega

Em abril de 2006, o IETF publicou os documentos de Sender ID e SPF em paralelo, todos como Experimental. A nota do IESG disse que faltava consenso técnico geral e que as tentativas de conciliação haviam falhado. Deixou ainda um aviso incomum: o Sender ID podia interpretar registros DNS criados para SPF segundo outra regra e fazer mensagens legítimas deixarem de ser entregues. Encaminhadores automáticos e cabeçalhos Resent-* apareciam como outro ponto de incompatibilidade.

O número de uma RFC preservou as duas propostas, mas não unificou a interpretação do registro. A divergência tinha consequência material para quem dependia da entrega: um servidor receptor podia transformar uma política publicada de boa-fé em motivo para descartar o correio.

Na avaliação de 2012, o IETF constatou que o SPF já era amplamente implantado. PRA e SUBMITTER, componentes do Sender ID, não formavam uma comunidade expressiva de uso. Havia programas disponíveis para os dois caminhos; a ausência de implementação não determinara a escolha. O documento mediu implantação, sem proclamar uma vitória teórica de um algoritmo. O SPF seguiu para a trilha de padronização em 2014. Em 2020, o Sender ID recebeu o status Historic.

A recusa da Apache, em 2004, fechou uma via concreta de distribuição. O balanço do IETF, anos depois, descreveu a preferência operacional mais ampla. Entre uma coisa e outra, ficou a falha que a nota de 2006 já tinha localizado: uma autorização em DNS só ajuda se os participantes concordarem sobre quem, exatamente, ela autoriza.