[GTER] confiabilidade de email

[Danton Nunes]

On Sat, 3 Oct 2009, Daniel Bastos wrote:

> > [o] pior caso é a falha silenciosa. de fato, nem sei se consideramos
> > como falha um erro notificado, já que o protocolo foi cumprido à
> > risca, ou seja, de um jeito ou de outro a coisa funcionou. é a falha
> > não notificada que pode trazer prejuízos sérios.
> 
> (*) Sobre o protocolo
> 
> SMTP não permite a falha silenciosa. Logo, a probabilidade de uma
> mensagem não estar na íntegra em qualquer sistema é zero, se computada
> em função do protocolo apenas. Implementações SMTP, todavia, pecam por
> seus erros. Então uma função apenas com respeito ao protocolo em si
> não é interessante.

isso no melhor dos mundos, no melhor dos universos possíveis, mas não é 
bem assim. basta que o mail from no envelope esteja bugado ou apesar de 
correto incapaz de receber email somado a um postmaster relapso, teremos 
falha silenciosa. mas concordo que não é culpa do SMTP ;-)

> (*) Perdas de dados
> 
> É preciso descobrir as má implementações e conhecer as condições em
> que elas geram uma perda. Daí podemos computar quão frequente essas
> condições são e quão provável tais condições são. Isso responde a
> probabilidade quanto a perda de dados em função do software SMTP.

sim, más implementações ou violações conscientes das regras do jogo são a 
principal causa de falhas silenciosas. um caso é o de filtros anti-spam. o 
filtro faz de conta que recebe a mensagem, a descarta ou joga numa 
quarentena e nem retorna um bounce (até por que 'mail from' de spam 
costuma ser mais falso que nota de sete) nem avisa o destinatário. no 
entanto reconheço que esta é uma falha na fase de entrega, depois que o 
transporte foi bem sucedido.

há sim uma probabilidade maior que zero de encontrar transporte mal 
implementado, acho um pouco 'otimista' demais dizer que a confiabilidade 
do transporte seja 100%.

> Eu espero, entretanto, que o mais provável seja que as perdas resultem
> de falhas de disco de dados ou falhas dos controladores de disco (como
> o sistema operacional), já que considero o software SMTP em si como
> mais próximo de perfeição do que um kernel, por exemplo, e certamente
> ambos são potencialmente mais próximos de perfeição do qualquer
> hardware --- por mais perfeito que seja um computador, de um ponto de
> vista eletrônico, se ele vive próximo a uma fogueira, de nada adianta
> sua perfeição eletrônica.

mas mesmo esse tipo de falha provoca mensagens tipo 400 ou 500 conforme o 
caso. ok, a confiabilidade de qualquer coisa está restrita à dos processos 
que a suportam.

> Para o mero atraso, basta definir o que é um atraso e avaliar os
> cabeçalhos ``Received'' em mensagens, assumindo que os SMTP-softwares
> estão aptos a computar datas a qualquer custo.

bacana. o resultado disso pode ser um histograma, com uma distribuição 
talvez com cara de Poisson, dando expectativas reais de atraso, tipo 90% 
das mensagens chegarão em menos de 2 minutos, 95% em menos de 10 minutos, 
98% em menos de uma hora e por aí vai.

há uma componente importante aqui que é o tamanho da mensagem (cabeçalhos 
+ corpo, embora em mensagens pesadas quase só o corpo conta). mensagens 
paquidérmicas tem menos chance de passar e, passando, são candidatas 
naturais a sofrerem mais atrasos. conheço algumas implementações de MTAs 
em que a fila não é 'first come first serve', mas tem uma política de 
atrasar propositalmente mensagens grandes para serem despachadas em 
período de baixo tráfego. É uma variável a mais para complicar.

> Para atraso, pode-se pensar em vascular arquivos de listas discussões
> ao redor do mundo, olhando os cabeçalhos das mensagens, anotando sobre
> atrasos entre cada dois computadores SMTP.

é uma boa idéia, porque não falta material para estudo nos arquivos das 
listas.

> Para a perda de dados, acho que seria necessário fazer no estilo Cliff
> Stoll --- veja abaixo ---, mas aí é preciso escolher rotas sensatas ao
> problema, e um novo problema aparece.
> 
>    ``I sent e-mail to myself from five different remote accounts. Most
>   letters arrived within two hours ... I discovered that five messages
>   never made it. Three of them bounced, due to network problems or
>   crashed computers along the way. The other two? Swallowed by the
>   electronic abyss.'' Cliff Stoll, Silicon Snake Oil

método muito interessante. é um poeta! além disso fabrica (épuras 
tridimensionais de) garrafas de Klein. quem estudou alguma topologia sabe 
do que se trata. e é autor do excelente 'the cuckoo's egg', um clássico da 
história da Internet. veja http://www.kleinbottle.com/