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

 
Six Approaches to Eliminating Unwanted E-Mail
Contribuído por scorpio em 23-05-06 22:43
do departamento spam
Spam A problemática do SPAM, abordada desta vez por um dos artigos da IBM: "The problem of unsolicited e-mail has been increasing for years, but help has arrived. In this article, David discusses and compares several broad approaches to the automatic elimination of unwanted e-mail while introducing and testing some popular tools that follow these approaches. "

Apple abre loja disponível 24x7 | Substituindo o Xchange  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • automatic elimination
  • Mais acerca Spam
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    2002? (Pontos:2, Interessante)
    por gEoTa em 24-05-06 10:19 GMT (#1)
    (Utilizador Info)
    Para um artigo escrito em 2002 diría que descreve bons métodos para combater o spam, no entanto as conclusões não poderão ser as mais actuais...

    Já usei o Spamassassin em servidores de mail distintos e, apesar de não ter dados concretos, não tenho, claramente, a impressão de ter resultados tão negativos quanto os demonstrados pelo autor do artigo. Mas gostava de saber opiniões factuais sobre o que acham da actualidade das conclusões apresentadas e quais os métodos que usam.
    A raíz do problema... (Pontos:4, Interessante)
    por Specimen em 24-05-06 18:55 GMT (#2)
    (Utilizador Info)

    A minha opinião, é que muitos dos problemas que o e-mail tem e pode ter, incluindo o spam, o envio de ficheiros binários, spoofing, entre outros, tem a ver com a natureza do próprio protocolo que não foi concebido para muitas das utilizações que nós damos hoje em dia.

    Para mim, Faz todo o sentido pensar num novo protocolo de comunicação assíncrona (por oposição ao IM) com capacidade de envio de ficheiros sem conversão para ascii, com melhor identificação e autenticação do emissor (para evitar spoofing, estava a pensar em qualquer coisa do género em que o servidor do receptor só aceitaria a menssagem se o domínios do emissor no endereço correspondesse ao domínio do servidor emissor), impossibilidade à partida de haver os chamados open-relays, entre outras coisas.
    O implentar um protocolo novo de raíz sem necessidades de compatibilidade com o actual protocolo de e-mail tem as suas vantagens, o blacklisting de open-relays nunca funciona 100% e gera falsos positivos, mas um novo protocolo que o não permitisse resolveria o problema de raíz.

    Em suma, em vez de andar a pôr paninhos quentes num protocolo desactualizado, eu gostaria de ver um novo protocolo que aproveitasse a conveniência básica do e-mail mas concebido a pensar nas necessidades de hoje.


    'In the future, the oppression will come in increasingly subtle forms'.

    Re:A raíz do problema... (Pontos:1)
    por qam em 24-05-06 19:40 GMT (#3)
    (Utilizador Info)
    Ou a adoção geral do spf por parte dos ISP's e afins. Não ?
    Re:A raíz do problema... (Pontos:0)
    por tonidosimpostos em 24-05-06 21:08 GMT (#4)
    (Utilizador Info)
    Certo... Parece o IPV6 vs IPV4, OggVorbis vs MP3, Linux vs Windows, Firefox vs IE... Right...

    "One of my main interests is Research & Development. R&D is the basis for Innovation, which couldn't exist without it"
    4GR dix it ! Uauuuuuuuu!
    Re:A raíz do problema... (Pontos:2)
    por Specimen em 24-05-06 22:04 GMT (#5)
    (Utilizador Info)

    Só significa, se me é permitida a arrogância, que tenho razão. ;)


    'In the future, the oppression will come in increasingly subtle forms'.

    Re:A raíz do problema... (Pontos:0)
    por tonidosimpostos em 25-05-06 22:07 GMT (#8)
    (Utilizador Info)
    Tens razao no que concretament ? Os exemplos servem para demonstrar coisas aparentemente superiores, que nao conseguem ganhar massa critica dado que as pessoas estao habituadas e nao mudam. Vais mudar todo o protocolo de mail, quando nem conseguem comecar a mudar a camada mais baixa ? Keep dreaming !

    "One of my main interests is Research & Development. R&D is the basis for Innovation, which couldn't exist without it"
    4GR dix it ! Uauuuuuuuu!
    Re:A raíz do problema... (Pontos:2)
    por Specimen em 25-05-06 22:59 GMT (#9)
    (Utilizador Info)

    Resposta curta: És parvito.

    Resposta não tão curta: Não me dou ao trabalho argumentar contigo porque não costumo andar a falar com portas ou paredes, por outro lado nem sequer tenho o mínimo de consideração pela tua opinião, portanto... És parvito.

    Uso o parvo de uma forma diminuitiva só para não parecer tão agressivo. Pensando melhor, só merecias a resposta curta. ;)


    'In the future, the oppression will come in increasingly subtle forms'.

    Re:A raíz do problema... (Pontos:0)
    por tonidosimpostos em 26-05-06 23:20 GMT (#10)
    (Utilizador Info)
    O unico idiota e parvo aqui ao mesmo tempo és tu, dado que nao consegues argumentar. A tua argumentacao é a negacao da argumentacao.

    Mas nao te preocupes, que eu falo para toda a gente, portas e paredes incluídas. Podes não gostar que a tua opinião seja contrariada, mas olha, é a vida.

    Voltando ao início, demonstra lá como é que raio vais mudar toda uma Internet, quando ainda existem por ai Sendmails do tempo que se calhar tu ainda não sabias o que era a Internet, entre outros exemplos. Claro que eu sei que és mais um burrinho que julga que mudar o mundo é so instalar linux, pq isso é muito fácil de usar. Portanto, começa lá a mudar o protocolo de mail... Ah... convém é que faças uma proposta de novo protocolo, dado que começares a construir a casa por cima, como os liliputianos, não é lá muito boa ideia.

    Esta foi a resposta longa :) Não gostas ? Roda e enfia pelo cu acima :)

    "One of my main interests is Research & Development. R&D is the basis for Innovation, which couldn't exist without it"
    4GR dix it ! Uauuuuuuuu!

    Re:A raíz do problema... (Pontos:2)
    por raxx7 em 27-05-06 9:31 GMT (#11)
    (Utilizador Info)
    (para evitar spoofing, estava a pensar em qualquer coisa do género em que o servidor do receptor só aceitaria a menssagem se o domínios do emissor no endereço correspondesse ao domínio do servidor emissor)

    Isto é exactamente o objectivo de SPF/DomainKeys/etc. Não há necessidade de um novo protocolo para isto.
    Uma ideia mais extrema para um novo protocolo de troca de mensagens seria um em que a maior parte do esforço de enviar a mensagem (bandwith/armazenamento) fosse colocado no dominio de origem (no STMP, é colocado nos relays e o dominio de destino). Mas isto é só uma ideia atirada ao ar, sem propostas concretas para se poder analizar os prós e contras.


    Re:A raíz do problema... (Pontos:2)
    por Specimen em 28-05-06 17:02 GMT (#12)
    (Utilizador Info)

    Essa parte que foi citada era só um exemplo. :)

    A minha questão em relação aos SPFs, Domainkeys e afins é só se às tantas não seria mais fácil chegar à acordo e implementar um novo protocolo de raíz com mais funcionalidades, do que chegar a acordo a qual o método a implementar no sistema de e-mail.


    'In the future, the oppression will come in increasingly subtle forms'.

    Re:A raíz do problema... (Pontos:2)
    por raxx7 em 28-05-06 22:13 GMT (#13)
    (Utilizador Info)
    Conceber e implementar um novo protocolo é fácil. Levar as pessoas a usá-lo é que é mais dificil... :)

    Re:A raíz do problema... (Pontos:2)
    por Specimen em 28-05-06 22:37 GMT (#14)
    (Utilizador Info)

    Sim, claro, a ideia era que tivesse vantagens claras em relação ao protocolo actual e aos seus problemas.


    'In the future, the oppression will come in increasingly subtle forms'.

    Re:A raíz do problema... (Pontos:1)
    por qam em 29-05-06 0:44 GMT (#16)
    (Utilizador Info)
    E então, vamos iniciar um rfc ? Ou continuamos a discutir o assunto aqui, para ser esquecido no próximo artigo. Até seria engraçado "lançar" o novo protocolo de mail ao mesmo tempo que é lançado o protocolo STCP. Entretanto vamos fazendo clusters de spamassassin e coisas do género, continuamos a usar as blacklists e greylists atrasamos um pouco o envio de mail controlamos o nº de emails enviados por cliente.
    E deixamos a autenticação e o SPF na gaveta.
    À quanto tempo se discute este problema e os operadores continuam a trabalhar separadamente para resolver este problema. ( sim sei que o problema não se coloca apenas a nivél nacional ) Será necessário o estado intervir com leis ?
    Penso que sim.
    Enquanto existirem pulhas e otários... (Pontos:1)
    por Politiquisses em 25-05-06 9:45 GMT (#6)
    (Utilizador Info)
    tudo vai continuar como está... com tendência a piorar. Atentem no correio convencional: centenas de anos de experiência e o lixo continua. Há questões incontornáveis:
    1. o que é para mim SPAM pode não ser para ti, logo, que critérios pode um SP usar para a filtragem?
    2. nenhuma empresa se atreve a implementar um filtro demasiado restritivo ou pode estar a perder clientes;
    3. o SPAM funciona, não só porque há o pulha que desrespeita os mais elementares conceitos de ética mas também porque há o otário que além de ler ainda compra o produto com base numa publicidade agressiva. Isto funciona há anos: para o correio convencional, para o correio electrónico, para os irritantes flyers no pára-brisas, para o papelinho colado no poste de iluminação e no contentor, para o autocolante na cabine da portagem, e afins... o limite é a imaginação!

    Cordiais cumprimentos
    (já estava com saudades deste belíssimo fórum!)

    Re:Enquanto existirem pulhas e otários... (Pontos:2)
    por null em 25-05-06 16:17 GMT (#7)
    (Utilizador Info)
    Bem, li ontem que os chicos do phishing estão a começar a vigarizar os que compram campanhas de SPAM. Isto é que é justiça eheheh.
    Re:Enquanto existirem pulhas e otários... (Pontos:1)
    por Sonekas em 29-05-06 0:37 GMT (#15)
    (Utilizador Info)
    desculpa lá... disseste "centenas de anos de experiência" ?

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]