gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
IETF MARID WG rejeita Sender ID
Contribuído por scorpio em 14-09-04 14:13
do departamento guerra-contra-o-SPAM
Internet flock escreve "

De acordo com esta notícia (artigo no Slashdot), o IETF MTA Authorization Records in DNS (MARID) Working Group rejeitou a proposta do Sender ID Framework da Microsoft especialmente devido ás patentes que são incompatíveis com algumas licenças de software. Mais detalhes sobre algumas das incompatibilidades podem ser encontrados neste documento da Apache Software Foundation já antes mencionado aqui no gildot.

A notícia fala também de possíveis problemas inerentes da sobre-utilização do TXT record no DNS que se prevê que venha a ser removido no futuro e da possível adição de um SPF record específico para o Sender Policy Framework.

Aparte disto tudo, gostaria que lessem a minha proposta. Não tem nada de novo, mas na minha opinião não é tão invasiva, tem as mesmas potencialidades que o Sender ID, não está sujeita a patentes, usa header fields já suportadas por alguns MTAs, não vai contra nenhum standard (pelo menos que eu tenha reparado) e é mais simples de implementar.

"

How cool would that be... | Solaris 10 OpenSource  >

 

gildot Login
Login:

Password:

Referências
  • gildot
  • notícia
  • artigo
  • Slashdot
  • IETF
  • MTA Authorization Records in DNS (MARID) Working Group
  • Sender ID Framework
  • Microsoft
  • documento
  • Apache Software Foundation
  • Sender Policy Framework
  • proposta
  • Mais acerca Internet
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Se eu li bem a tua proposta... (Pontos:2)
    por raxx7 em 14-09-04 17:44 GMT (#1)
    (Utilizador Info)
    ... se enviar um mail com From: foo@bar.com através de um relay smtp.myisp.com, que não está na lista de MX de bar.com, o mail leva com um _temporary authorizathion failure_. Certo?

    Re:Se eu li bem a tua proposta... (Pontos:1)
    por flock em 14-09-04 20:55 GMT (#3)
    (Utilizador Info) http://www.corah.org/

    Não sei se percebi a pergunta, mas respondendo da forma que percebi, há mais de uma resolução dependendo do destino.

    1. Se a mensagem se dirigir a, por exemplo, boo@myisp.com e o smtp.myisp.com estiver listado nas MX records de myisp.com, a delivery ocorre com sucesso.
    2. Se a mensagem se dirigir a qualquer outro recipient externo, o MTA à qual ela se destina vai retornar 5xx (permanent authorization error) visto que o IP do smtp.myisp.com não tem autorização para enviar mensagens do bar.com. A ideia é mesmo dificultar ao maximo este tipo de relay.

    O temporary error só se aplica nos casos em que passado uma determinada quantidade de tempo ainda não foi possível verificar a autenticidade da mensagem.




    "Portugal só segue os Americanos naquilo que é mau." -- O meu pai
    Re:Se eu li bem a tua proposta... (Pontos:1)
    por flock em 14-09-04 21:33 GMT (#4)
    (Utilizador Info) http://www.corah.org/
    Após reler a tua questão, acho que compreendi a que te referes exactamente.

    Referes-te ao facto de ser possível especificar se existem outros MTAs com permissão para relay no SPF?

    Se sim, tens razão aí, porque é algo em que ainda não tinha pensado, tenho de ponderar sobre isso. Obrigado pela dica.


    "Portugal só segue os Americanos naquilo que é mau." -- O meu pai
    Re:Se eu li bem a tua proposta... (Pontos:1)
    por flock em 14-09-04 22:02 GMT (#7)
    (Utilizador Info) http://www.corah.org/
    From: foo@bar.com
    To: blah@boo.com
    Delivered-To: client@myisp.com
    Subject: Hello world!

    I am successfully reporting my relay through smtp.myisp.com.

    ====

    O exemplo em cima requer uma outra alteração no MTA (ainda não pensei bem sobre como deverá ser implementada, se é que não é já possível faze-lo no Postfix) para introduzir o Delivered-To, mas faz o que pedes. O smtp.myisp.com faz relay da mensagem conforme esperado porque o último Delivered-To o torna responsável pela mensagem. O MTA destinatário ao ver o último Delivered-To com um host que resolve para o smtp.myisp.com, aceita a mensagem.


    "Portugal só segue os Americanos naquilo que é mau." -- O meu pai
    Re:Se eu li bem a tua proposta... (Pontos:1)
    por pires em 15-09-04 10:13 GMT (#8)
    (Utilizador Info) http://www.evoluzion.org
    e q tal adicionarem um MX com menos prioridade para servidores RELAY?

    After all, we're all alike!
    Re:Se eu li bem a tua proposta... (Pontos:2)
    por Strange em 15-09-04 10:46 GMT (#9)
    (Utilizador Info) http://strange.nsk.no-ip.org/
    obriga na mesma a esses servidores terem a possibilidade de receber email.

    prefiro uma definicao clara do papel de cada sistema.

    hugs
    Strange

    Re:Se eu li bem a tua proposta... (Pontos:2)
    por raxx7 em 15-09-04 13:00 GMT (#10)
    (Utilizador Info)
    Estava a referir-me ao caso 2 do teu post anterior. A solução é inaceitável, porque é uma forma comum de utilizar o E-Mail: ter um e-mail foo@bar.com mas enviar os mails através do relay do isp e não através do relay do bar.com. A tua solução quebra esta prática.
    O SPF tem o mesmo problema, mas com uma diferença fundamental: utiliza um RR separado para isso, pelo que é válido inferir da existência desse RR que o dominio implementou o sistema e tomou as medidas apropriadas para lidar com ele, tal como avisar os clientes que têm de enviar os mails através de um determinado relay em vez de utilizar o relay do ISP.
    A mesma inferência não se pode fazer da existência do RR MX, que tem outro objectivo.
    Ou seja, o SPF é algo que cada dominio pode implementar quando quiser. A tua proposta requer que todos os dominios eleminem aquela prática de uma assentada, sob pena de os seus clientes não conseguirem enviar mails para dominios onde a tua proposta tenha sido implementada.

    Re: (Pontos:2)
    por gotcha em 14-09-04 17:54 GMT (#2)
    (Utilizador Info) http://alunos.uevora.pt/~l13591
    Obrigado por partilhares connosco a tua proposta mas não seria mais apropriado submete-la a comentários em sítios mais indicados? e.g. IETF?
    Em caso de o fazeres proponho duas coisas:
    1) Re-escrita de alguns parágrafos e remoção de "piadas".
    2) Um pequeno parágrafo explicativo de quem és tu e porque pensas estar no direito de fazer tal proposta.

    Não vou fazer qualquer comentário adicional à proposta, uma vez que não estou devidamente informado sobre o assunto, mas o que tu próprio afirmas na conclusão penso ser um bom resumo:

    "Do you really believe that this is going to stop spam? Personally I do not, they can just use worms to send spam from regular user accounts or buy domains for themselves, because domains are cheap these days, [..], so even domain blacklisting won't stop spammers. The spam has became a market itself, there are already people out there infecting home computers with trojans to sell them later to spammers, [..] If a solution has to be approved, then approve a patent-free and more standard friendly one."

    --
    Nuno Morgadinho
    Re: (Pontos:1)
    por Valjean em 14-09-04 21:52 GMT (#6)
    (Utilizador Info) http://republico.estv.ipv.pt/~lbruno/
    A proposta do bacano, se a leio correctamente, torna os RR MX indicadores de saida e entrada de email; deixas de poder fazer a distincao entre as maquinas que apenas recebem e apenas enviam email.

    Dado que faz mais sentido separar estas duas funcoes quando tens muitos users (p. ex, nao classificas os outgoing emails com o SA), e' preferivel deixar como esta' hoje, em que os servers inbound sao identificados pelo MX, e os outbound serao identificados por outros metodos.

    Creio que este assunto especifico foi debatido na mailing list do MARID.

    Quando à utilizacao de headers para determinar quem foi a pessoa responsavel por transmitir o email para estes efeitos: foi dito recentemente na dita mailing list que nao iriam trabalhar em sistemas semelhantes, devido a pensarem que a patente da Microsoft ira' cobrir tais metodos.

    Alem disso, a proposta CORAH usa o Delivered-To: que nao e' adicionado por todos os MTA (porque nao e' standard). Alem disso, para que o Delivered-To? O primeiro que encontrarmos pode muito bem ser o nosso, se usarmos qmail. Mais valia deixar cair esse header.

    Nao recomento submeter aquela proposta a lado nenhum :-) Pelo menos, nao antes de revista.

    --
    Luís Bruno

    Re: (Pontos:1)
    por flock em 15-09-04 22:44 GMT (#11)
    (Utilizador Info) http://www.corah.org/
    "Alem disso, a proposta CORAH usa o Delivered-To: que nao e' adicionado por todos os MTA (porque nao e' standard). Alem disso, para que o Delivered-To? O primeiro que encontrarmos pode muito bem ser o nosso, se usarmos qmail. Mais valia deixar cair esse header."

    Outro ponto interessante, não sei como não reparei nisto (provavelmente foram as horas que devo ao sono), mas é uma inconsistência brutal da minha parte.

    O mais incrível é que li este post ontem e pareceu-me errado mas decidi não responder. Hoje olhei novamente e tudo fez sentido. Oh god! Thanks for noticing! :-)


    "Portugal só segue os Americanos naquilo que é mau." -- O meu pai
    Re: (Pontos:1)
    por Valjean em 17-09-04 22:11 GMT (#12)
    (Utilizador Info) http://republico.estv.ipv.pt/~lbruno/
    Manda um email se quiseres discutir detalhes; pode dar sempre jeito alguem externo a dar uma vista de olhos na diagonal.

    Cheers, -- Valjean

    --
    Luís Bruno

    . (Pontos:1)
    por Valjean em 14-09-04 21:40 GMT (#5)
    (Utilizador Info) http://republico.estv.ipv.pt/~lbruno/
    Alguem aqui devia ler os arquivos em ... http://www.imc.org/ietf-mxcomp/

    Ainda nao rejeitaram; ate' agora rejeitaram trabalhar em outras propostas que pudessem estar cobertas pela mesma patente da Microsoft. Existem outros mecanismos para alem do PRA da Microsoft.

    O trabalho continua nesse algoritmo, ao contrario do noticiado.

    --
    Luís Bruno

     

     

    [ Topo | FAQ | Editores | Contacto ]