[GTER] AMTP, a replacement for SMTP

[Durval Menezes]

Alo Danton, demais colegas:

On Thu, Sep 04, 2003 at 09:42:22AM -0300, Danton Nunes wrote:
> On Thu, 4 Sep 2003, Luiz Gustavo wrote:
> 
> >  Acho que deviamos estar mais preocupados com os provedores de servico
> >  de cable e DSL do que com novos drafts de protocolo.
> 
> estive lendo o draft do AMTP e vi algumas coisas bem interessantes:
> - trata-se de fato de uma extensão, com algumas poucas restrições do bom e
> velho SMTP, mais propriamente SMTPs, já que a transação toda rola
> necessariamente sob TLS;

*necessariamente*? Isso pode ser um problema hosts que hospedem MTAs com
muito trafego... certamente vai faltar CPU por conta da criptografia.

> - os dois MTAs tem que trocar certificados semelhantes aos de sites https;
> - o comando HELO não é aceito. o EHLO tem que vir com o nome de domínio que
> corresponde ao CN do certificado.

Essas duas caracteristicas basicamente vao obrigar TODO MUNDO a ter um
certificado digital (provedores *e* "usuarios comuns"), a nao ser que se
implemente algo "hibrido" como por exemplo cada provedor aceitar o
tradicional SMTP vindos dos proprios pools de acesso (para nao obrigar
os proprios usuarios a implementarem tambem AMTP, comprarem certificados,
etc).

Na pratica o que vamos ver sera' os spammers utilizando certificados
digitais (sejam legitimos, com o "proprio nome", ou picareta, criados
usando um cartao de credito roubado, ou ainda usando certificados
roubados via worms, etc).

> - a tradução reversa do IP do cliente tem que funcionar e bater com o CN
> declarado no certificado.

Na pratica impossivel para os clientes dos usuarios finais (que
normalmente conectam com IP variavel). So' isso ja' parece deixar claro
que o protocolo se limita a comunicacoes MTA-MTA...

> - o protocolo prevê uma linguagem e um esquema de negociação de políticas do
> site, dizendo que tipo de mensagens são aceitas ou não.

Hummrmrm... complexo isso, heim?

> - o resto é o bom e velho SMTP.
> 
> É importante notar que o AMTP não impede que alguém mande mensagens com
> cabeçalhos falsos ou que viole a política declarada, por exemplo, mandando uma
> mensagem rotulada como administração de rede mas que na verdade é spam.

Sem duvida...

> O que
> o AMTP faz é identificar a origem de forma inequívoca (até o ponto em que se
> pode confiar em certificados digitais), de modo que você sempre sabe com quem
> reclamar.

Teoricamente... vide acima quanto a certificados fajutos.

> No fundo, cada MTA tem que mostrar os dados que estariam no whois,
> só que (supostamente) os dados do certificado são mais difíceis de forjar que
> os do whois. (será?)

Bem, depende de como se define "forjar". Produzir um certificado
inteiramente falso significa quebrar a criptografia usada para a 
assinatura do certificado pelo respectivo CA, ou entao furtar a
chave privada do proprio CA, o que e' (ou pelo menos deveria ser)
bastante dificil.

Ja' furtar o certificado na maquina do proprio usuario (o que nao vai
adiantar se o reverso tiver que bater com o CN=), ou ainda invadi-la
e usa-la como relay de email, me parece relativamente facil...

> Como usuários finais dificilmente vão conseguir obter certificados, etc., o
> uso do AMTP os força a usar relays controlados de seus provedores.

Concordo, vide acima, excetuando os casos em que os usuarios sao
empresas.

> A
> codificação e negociação das políticas de cada site me pareceu uma idéia
> interessante.

Ha' que ver se a maioria dos administradores hoje tem uma ideia clara o
suficiente do seu trafego para especificar isso, senao pelo menos no 
inicio (e assumindo que o protocolo "pegue"), todo mundo vai acabar
deixando "no default".

> É viável? não sei. Por estas bandas nem a tradução reversa em geral funciona,
> quem dirá certificar cada MX da vida...

Acho que a coisa acaba sendo gradual... por exemplo, mexendo no peso do
Bayesian (ou dispensando de challenge-response) os emails que vierem via
AMTP...

> A idéia da codificação das políticas é
> independente da autenticação e poderia (deveria, a meu ver) ser proposta como
> uma extensão independente do SMTP.

Humrmrm... vide acima.

> É certamente um bom negócio para as
> Verisign da vida ;-)

Para nao falar nos fabricantes de servidores com CPUs mais parrudas, e
tambem de aceleradores criptograficos... vide acima.

Sinceramente, achei que a necessidade de todo o trafego ser criptografado
traz pouco beneficio para muito custo....

Um Grande Abraco,
-- 
   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)

> Danton
> 
> 
> --
> GTER list    http://eng.registro.br/mailman/listinfo/gter