[GTER] confiabilidade de email

[Andre Ramoni]

Eu concordo com o que o Danton tem falado.

Acho que devemos tomar medidas para que os problemas não acontecam, em  
vez de tomar medidas para tentar conviver com eles.
A criação de mecanismos para lidar com situações que não deveriam  
existir costumam ser falhas e aumentam a complexidade.

Confirmação de leitura é uma coisa que não existe por definição.
Já confirmação de entrega existe... DSN, delivery status notification.

Porém, vez de gerar mais um email para cada email entregue de um  
determinado from (imagine um virus enviando email com tal from e o  
carinha recebendo milhoes de confirmacoes), porque nao se satisfazer  
com os mecanismos atuais de nao-entrega ?

Eu por exemplo (em servidores que eu desenho) costumo configurar para  
caso o email fique 2 horas na fila de saida sem conseguir ser  
entregue, avisar ao remetente que o ainda AINDA nao foi, mas que ele  
nao precisa reenviar porque o servidor ainda esta tentando.
Apos 8 horas de fila gero um bounce caso nao tenha conseguido entregar.

Tem gente que acha 8 horas pouco, e configura como dias..., mas pelo  
que percebi dos clientes eles preferem saber o quanto antes um email  
nao foi entregue do que so descobrir depois de 2 dias que nao foi.

No meu caso, usando postfix, ele me atende perfeitamente quanto ao que  
eu acho ideal no comportamento de um servidor de email.



On Oct 17, 2009, at 10:07 PM, Danton Nunes wrote:

> On Sat, 17 Oct 2009, Danilo Paffi Monteiro wrote:
>
>> O Discard em uma regra de e-mail é um recurso fantástico, tivemos  
>> um bounce attack que o discard foi fundamental.
>
> sem dúvida. mas temos que reconhecer que é uma violação à RFC-2822 e  
> que diminui a confiabilidade do sistema como um todo.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter