[GTER] confiabilidade de email

[Marcus Almeida]

Mais essa arquitetura, transformaria o email em um "msn".

O problema do email, é que ele foi inventado em uma epoca em que as pessoas
passavam email e ligavam pra saber se chegou, ou seja era um ambiente
confiavel. muito diferente de hoje em dia.

O problema esta nas pessoas que insitem em utilizar o email, imitando um
correio "sem custos". nasceu o SPAM!

Mais a ideia passada, é um horizonte e ser perseguido, pois do jeito que
estamos, está ficando inviável prover serviços de email com qualidade.

Atenciosamente,
Marcus Roberto.

2009/10/4 "Julião Braga (Pegasus)" <jb at redepegasus.com.br>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ando pensando, também.
>
> Não uso greylist (já usei). Uso as ferramentas tradicionais, combinadas
> e, tenho o mesmo esquema instalado em 5 servidores com Postfix. Os
> resultados são muito bons. Exceto quando há um alguns ataques
> localizados de "spoofing", por exemplo. Nesse caso, algum tempo manual,
> resolve o problema, sem muito trabalho. Tem sido assim há uns 5 anos.
>
> Uma tese de Doutorado do INPE (uma aluna do Bannon) abordou uma técnica
> chamada Procedência de Dados (Provenance, em inglês). A tese aplica a
> técnica em imagens e é bem bolada. Mantendo históricos de alterações
> sobre uma imagem original, armazenados em texto, evita a demanda imensa
> de armazenamento e consegue reproduzir cada alterações, de novo, em
> imagens (a partir da original).
>
> Um bom trabalho, acredito, seria a aplicação de Procedência de Dados nos
> servidores de e-mail, com base em ações de clientes. Por exemplo, se não
> quero receber mensagens do Danton (que não é o caso, claro! - até porque
> ele não responde a meus e-mails ...), reproduzo uma ação via meu cliente
> de e-mail (como aquela de mensagens de garantia de recebimento) e os
> servidores, nunca mais me enviariam mensagens do Danton. Liquidando o
> problema na origem e, não no destino. Se o recurso, entretanto, não
> estivesse ativo na origem, então aquele servidor não seria aceito, sob
> nenhuma hipótese, por nenhum outro servidor de e-mail. Dessa forma, a
> origem, bem itencionada, teria interesse na implementação.
> Provavelmente, não seria necessário mudanças nos servidores/clientes.
> Bastaria uma funcionalidade externa e acoplada por demanda.
>
> Deveria ser inteligente (pouca coisa), cooperativa e distribuida (a tal
> facilidade). Uma variação da proposta do Danton. O conceito de
> Procedência de Dados seria equivalente, mesmo, a Procedência de E-mails.
> Procedência, na acepção da palavra.
>
> Uma bela tese de mestrado, acredito.
>
> []s, Julião
>
> Danton Nunes escreveu:
> > On Sat, 3 Oct 2009, Ricardo Rodrigues wrote:
> >
> >> É preciso trabalhar com muita responsabilidade para que estes
> >> redirecionamentos tragam reais benefícios aos usuários e melhorem sua
> >> experiência Internet. Infelizmente já vi empresas (inclusive no Brasil
> >> ! ) fazendo redirecionamento sem qualquer critério e até mesmo
> >> redirecionando domínios de pesquisa que existem e são muito acessados.
> >
> > pois é, esse é um dos muitos fatores que entram na confiabilidade do
> > e-mail. qual a probabilidade do DNS ser engabelado e com isso o
> > transporte tentar conectar servidor errado?
> >
> > estive matutando sobre o processo todo, acho que a grosso modo podemos
> > dividir o processamento do email em três fases distintas e em série,
> > isto é, a realização de uma depende do sucesso da anterior:
> >
> > 1. submissão: do cliente para a fila de saída (idealmente SMTP na porta
> > tcp/587 mas pode ser cada gambiarra...)
> >
> > 2. transporte: SMTP altamente dependente de DNS tanto na determinação do
> > MX de destino quanto na resolução de SPF, DKIM, etc.
> >
> > 3. entrega: do servidor do destinatário para o cliente do destinatário
> > (POP, IMAP, Webmail, etc.), também sujeito a chuvas e trovoadas,
> > classificação equivocada como spam, etc.
> >
> > a probabilidade de sucesso na transmissão de um email então é o produto
> > das probabilidades de sucesso de cada fase.
> >
> > estou pensando em fazer modelos simplificados de cada fase, e tentar
> > estimar essas probabilidades (por análise de logs, e, 'ad ultima ratio',
> > chutando mesmo). depois comparar essa probabilidade de sucesso com
> > telefone, fax, mensagem via motoboy, sinais de fumaça, etc. pode ser um
> > bom assunto para uma discussão na reunião do GTER.
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFKyBrrC6YpaEL3LVERArOsAJ9/6RH/0isW/QzxXIEwLEjbOQUKxACgriWs
> noAOY+uWyv1IsfqNVEsntBM=
> =mb/B
> -----END PGP SIGNATURE-----
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



--