Resumo

  • O RFC 1429 descreveu o LISTSERV DISTRIBUTE levando uma cópia por enlaces muito carregados, conforme a topologia disponível, e dividindo a entrega perto dos destinatários. Eric Thomas registrou dois a seis milhões de mensagens diárias na época.
  • O remetente precisava escolher um ponto de entrada próximo, conferir se o arquivo Master nodes tinha no máximo dois meses e consultar o administrador antes de ultrapassar dez mil destinatários por dia.

Uma universidade com T1 para IP podia continuar presa a uma linha de 9,6 quilobits para BITNET. Essa frase do RFC 1429, de fevereiro de 1993, fura a propaganda fácil da distribuição em massa. O endereço de um servidor não revela qual conexão receberá a carga. A economia de cópias só começa depois que a mensagem chega ao lugar certo.

O serviço DISTRIBUTE oferecia uma saída para listas grandes. O operador entregava ao LISTSERV o texto e uma relação de destinatários; a rede usava sua visão da topologia para atravessar enlaces congestionados com uma cópia e replicar mais perto dos grupos de destino. Thomas disse que o sistema então transportava entre dois e seis milhões de mensagens por dia. Para receptores BITNET razoavelmente conectados, citou cinco a quinze minutos como prazo típico; para destinos Internet que podiam ser entregues perto da organização, cinco a vinte minutos. Eram populações distintas na experiência que o autor apresentou naquele momento.

O primeiro conselho prático era escolher bem a porta. O texto ironiza uma lista originada na Califórnia e dirigida sobretudo aos Estados Unidos que fosse entregue a um servidor na Suécia. A geografia da entrada importava; a qualidade da conexão BITNET do anfitrião importava ainda mais. O RFC também pedia testar a versão e a capacidade de lidar com linhas longas, pois certos formatos de correio não as preservavam adequadamente.

Depois vinha a tabela que fazia o atalho funcionar. O arquivo Master nodes do servidor não deveria ter mais de dois meses. Thomas apontou instalações que deixavam as tabelas envelhecer por falta de pessoal. A rede podia aceitar o comando e, ao mesmo tempo, usar uma descrição ultrapassada de seus próprios caminhos. O desempenho dependia sobretudo da qualidade e precisão das informações topológicas, com a carga do sistema pesando em casos extremos.

Havia também um dono da capacidade. Para mais de dez mil destinatários diários, o autor orientava pedir permissão ao administrador LISTSERV do site e explicar volume e frequência. Algumas universidades poderiam proibir grandes distribuições em horário de pico; outras tinham mais de uma máquina e queriam encaminhar o trabalho à adequada. O protocolo compartilhava transporte, mas não dispensava acordo com quem mantinha a instalação.

O pedido chegava convenientemente por SMTP. No envelope, MAIL FROM devia apontar a uma pessoa capaz de reagir se a mensagem não alcançasse o servidor. Dentro do pedido, o From da mensagem RFC822 recebia os problemas posteriores de entrega. Usar ali o endereço de submissão da própria lista poderia fazer as falhas voltarem à lista e formar um ciclo.

O formato distinguia ensaio e produção. Um cartão JOB precedia DISTRIBUTE MAIL, a lista de destinos identificados por BSMTP e a mensagem. DEBUG=YES mostrava as rotas sem entregar; TRACE=YES informava enquanto entregava. No exemplo do RFC, três destinatários eram encaminhados via UGA e dois saíam por um agente local. Em produção, ECHO=NO suprimia o relatório de uso de recursos. A observabilidade tinha custo de CPU e tráfego, por isso o modo de teste não era a rotina.

O atalho era real, mas não morava na palavra DISTRIBUTE. Morava na escolha da entrada, na largura da conexão, na atualização da tabela e na decisão do administrador. Uma linha de 9,6 quilobits na porta de uma rede rápida podia cobrar a conta de todo o projeto.