• Revista PROGRAMAR: Já está disponível a edição #56 da revista programar. Faz já o download aqui!

skin

Proteger e-mail de crawler bot's

52 mensagens neste tópico

eu estou a falar a sério ...

se não consegues enquadrar o problema, mesmo que dizendo que um servidor de emails não pode afirmar nada sobre as acções de terceiros, então mais não posso fazer.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Redinpais: O objetivo é mostrar o email na pagina de forma a que qualquer um possa olhar para lá e saber qual é o email, mas não o mostrar no código fonte para que "alguem" o possa copiar automaticamente para uma lista.

Uma moda que pegou no linkedin é "Sou um tipo especialista numa área qualquer e criei uma folha de excel, que analisa, gera gráficos, tira cafés e vai buscar umas minis ao frigorifico. Quem quiser que ponha aqui por baixo nos comentários, o seu email"

Depois há uns 30-40k de otários que caem no conto do vigário e metem lá o email bem visível. Basta um select/copy/paste para teres uma lista com milhares de emails para fazer spam.

É isso que devemos evitar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
4 horas atrás, ruicosta.web disse:

Redinpais: O objetivo é mostrar o email na pagina de forma a que qualquer um possa olhar para lá e saber qual é o email, mas não o mostrar no código fonte para que "alguem" o possa copiar automaticamente para uma lista.

Uma moda que pegou no linkedin é "Sou um tipo especialista numa área qualquer e criei uma folha de excel, que analisa, gera gráficos, tira cafés e vai buscar umas minis ao frigorifico. Quem quiser que ponha aqui por baixo nos comentários, o seu email"

Depois há uns 30-40k de otários que caem no conto do vigário e metem lá o email bem visível. Basta um select/copy/paste para teres uma lista com milhares de emails para fazer spam.

É isso que devemos evitar.

Idealmente, não devias ter de te preocupar com a disponibilização do teu email na internet.  O teu serviço de email devia tratar de filtrar o Spam.

Apesar de ainda não vivermos nesse mundo ideal, já há serviços bastante eficazes na detecção de Spam, sem introduzir problemas de usabilidade.  Pessoalmente não tenho qualquer problema em disponibilizar alguns dos meus emails publicamente, pois sei que o sistema de Spam dos mesmos é suficientemente bom para não me ter que preocupar.  Até porque a menos que não uses o email, o mesmo vai mais sedo ou mais tarde entrar numa lista de emails para Spam, por muito cuidado que tenhas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em 21/09/2016 às 14:58, ruicosta.web disse:

É isso que devemos evitar.

Não tinha recebido a notificação da vossa resposta e não vim cá ver... Sorry!

Percebi a intenção mas queria alertar que é possível evitar essa preocupação.
Eu criei um conceito que por analogia faz o seguinte:

Um spammer tem intenção de enviar 1 milhão de mensagens para 1 milhão de endereços válidos. No entanto como sabemos ele esconde-se por detrás de um endereço falso.
No sistema que eu criei, o spammer é obrigado a reter todas essas mensagens no servidor dele até que o destinatário demonstre o interesse em a receber.
Quando um suposto destinatário desejar a mensagem, o pedido vai parar a um remetente diferente ou desconhecido. Neste pressuposto o destinatário não vai receber a mensagem (livrando-se de eventuais ameaças e publicidade indesejada) e o remetente (spammer) não vai conseguir libertar as mensagens que nos modelos atuais já estariam no lado do receptor.
Deste modo, a divulgação publica de um endereço de email não vai fazer diferença nenhuma a quem esteja a usar o modelo de proteção que eu criei.

Para mais informações podem rever as feetures em http://p2t.email 

O único grande problema é que apenas tenho este conceito em patente mas não em prova de conceito, pelo que eu ofereço 90% da sua exploração a quem o desejar.

Cumprimentos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em 21/09/2016 às 19:27, Rui Carlos disse:

Apesar de ainda não vivermos nesse mundo ideal, já há serviços bastante eficazes na detecção de Spam, sem introduzir problemas de usabilidade. 

O que não se compreende como é que ao fim de quase 40 anos ainda exista 65% de spam na rede quando os ditos filtros prometem capacidades de proteção na ordem dos 99,9%, a evolução tecnológica evolui diária e quase exponencialmente e ainda por cima com grandes players no mercado.

Alguma vai mal. Porque é que apenas se continua a apostar em modelos de filtragem?

Cumprimentos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
2 horas atrás, redinpais disse:

Um spammer tem intenção de enviar 1 milhão de mensagens para 1 milhão de endereços válidos. No entanto como sabemos ele esconde-se por detrás de um endereço falso.

Não percebi o que pretendias dizer por endereço falso, mas o Spam não vem necessariamente de um endereço de email ou endereço de IP falso.

2 horas atrás, redinpais disse:

No sistema que eu criei, o spammer é obrigado a reter todas essas mensagens no servidor dele até que o destinatário demonstre o interesse em a receber.

Quando um suposto destinatário desejar a mensagem, o pedido vai parar a um remetente diferente ou desconhecido. Neste pressuposto o destinatário não vai receber a mensagem (livrando-se de eventuais ameaças e publicidade indesejada) e o remetente (spammer) não vai conseguir libertar as mensagens que nos modelos atuais já estariam no lado do receptor.

Esse protocolo ia causar overheads na comunicação de emails, e baseia-se na ideia de que é usado um endereço falso, o que não é sempre o caso.

Há serviços de email que já implementam sistemas semelhantes, em que rejeitam o email nas primeiras tentativas de entrega, e obrigam o servidor a manter o email na sua fila de saída e a reenviar mais tarde.  O problema deste tipo de soluções é que aumenta os custos de envio, quer para Spam, quer para emails legítimos!  A tua solução poderia aumentar ainda mais.  E se custos elevados reduzem o Spam, também fazem com que certos serviços possam ter que deixar de oferecer notificações por email que o utilizador até gostaria de ter.

Também existem já sistemas que respondem aos envios a pedir uma acção do remetente para desbloquear o email enviado, o que causa ainda mais problemas a emails legítimos enviados de forma automática.

De referir ainda que o problema no caso dos emails falsos se resolve facilmente com mecanismos já existentes, como o SPF e DKIM.  Penso que a generalidade dos receptores de email não fazem uma validação estrita destes mecanismos, pois tal iria mais uma vez eliminar emails legítimos.

O problema do Spam está precisamente neste balanço entre evitar que Spam chegue aos utilizadores, mas ao mesmo que permita aos utilizadores receberem os emails legítimos mantendo os custos o mais baixos possíveis.  Como referir acima, este balanço implica até "ignorar" standards já implementados (SPF, DKIM) que poderiam diminuir o Spam.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
13 horas atrás, Rui Carlos disse:

Não percebi o que pretendias dizer por endereço falso, mas o Spam não vem necessariamente de um endereço de email ou endereço de IP falso.

Sim, vem. Um endereço falso é aquele em que se pretende perseguir judicialmente por uma má prática ou simplesmente para pedir a interrupção do abuso de envio e não se obtém resposta por não chegar ao destino. E muitas vezes esses endereços (já aconteceu comigo algumas vezes) pertencem a outros válidos por terem sido usados ilicitamente.

Aquele que vem de endereços válidos e contactáveis são num numero aceitável por qualquer destinatário e passiveis de resolver na hora qualquer litígio. 

13 horas atrás, Rui Carlos disse:

Esse protocolo ia causar overheads na comunicação de emails, e...

Muito pelo contrário. Os milhões e milhões de emails que estariam na rede nos modelos atuais, pelo modelo P2T ficariam no remetente sem chegarem a circular na rede. Calcula-se até que existirá um expresso alivio na largura de banda.

13 horas atrás, Rui Carlos disse:

Há serviços de email que já implementam sistemas semelhantes, em que rejeitam o email nas primeiras tentativas de entrega, e obrigam o servidor a manter o email na sua fila de saída e a reenviar mais tarde.  O problema deste tipo de soluções é que aumenta os custos de envio, quer para Spam, quer para emails legítimos!  A tua solução poderia aumentar ainda mais.  E se custos elevados reduzem o Spam, também fazem com que certos serviços possam ter que deixar de oferecer notificações por email que o utilizador até gostaria de ter.

Sim, estou ciente e completamente de acordo, mas esse problema não iria acontecer. Está previsto neste modelo P2T que o comportamento seja exatamente igual ao esperado pelos modelos atuais. Ou seja. No modelo P2T recebes no teu cliente de email/webmail a linha correspondente da mensagem para ser aberta. Quando desejas abrir a mensagem nos modelos atuais, esta mensagem já está do teu lado livrando o remetente da responsabilidade mas no modelo P2T ao desejares a mensagem ela será aberta porque nesse momento foi libertada do remetente. A dita fila de saída reduz-se de mais tarde para imediato. Neste sentido, as ditas notificações que por vezes recebemos irão chegar sem atrasos.

13 horas atrás, Rui Carlos disse:

De referir ainda que o problema no caso dos emails falsos se resolve facilmente com mecanismos já existentes, como o SPF e DKIM.  Penso que a generalidade dos receptores de email não fazem uma validação estrita destes mecanismos, pois tal iria mais uma vez eliminar emails legítimos.

É sabido que vários estudos apontam para que existam menos de 10% de servidores que estejam devidamente configurados com esses mecanismos e lamentavelmente até em grandes players. Esses mecanismos apenas se destinam a autenticar o envio de uma organização para protegerem o seu domínio de actividades suspeitas e abusivas mas para se protegerem do que recebem têm de continuar a apostar num investimento em recursos humanos extra, financeiros e tempo por um problema causado por outros. E como é sabido, os spammers não respeitam estas regras e enquanto não os tornarem incompatíveis, nunca se conseguirá pelos processos de filtragem, que é o único processo existente de protecção.

O que se pretende com o meu sistema (que está patenteado) é fazer o mesmo que analogamente aconteceu com o Whasapp.

O Watsapp está para o serviço de SMS, assim como o P2T estará para o email. Pretende-se criar um servidor de email em que a sua essência está no controlo interno na forma como as mensagens são geridas e não depois de já ter sido enviado para a rede.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Tenho estado a acompanhar as descrições mas ainda não consegui perceber a utilidade/diferença no modelo. Pelo que percebo, é sempre enviada uma mensagem ao destinatário com a indicação de que tem um e-mail para ler, não o e-mail todo mas uma informação enviada ao cliente a dizer que há um e-mail. De seguida, se o destinatário quiser abrir o e-mail dá essa instrução e a aplicação cliente vai ao servidor buscar o e-mail completo.

Se o destinatário não quer ver o e-mail então não inicia a obtenção da mensagem completa. A fila de e-mail está no servidor de envio, as aplicações cliente apenas recebem uma notificação a dizer que há um e-mail para o destinatário. Se isto é assim, essa mensagem/notificação não é, ela mesma, um "e-mail"? Qual é a diferença ou como é que é feita a notificação dos destinatários?

Se o cliente pede para fazer download da mensagem, como é que evito que todos os meus clientes tentem obter as mensagens ao mesmo tempo e rebentem com o meu servidor, já que o pico de acesso será enorme se considerarmos que a minha aplicação envia vários e-mails legítimos, de notificações que os meus utilizadores não querem perder? Se for eu a suportar os custos deste serviço terei de desligar as notificações porque o custo mensal para suporte de picos é grande.

 

6 horas atrás, redinpais disse:

Sim, vem. Um endereço falso é aquele em que se pretende perseguir judicialmente por uma má prática ou simplesmente para pedir a interrupção do abuso de envio e não se obtém resposta por não chegar ao destino. E muitas vezes esses endereços (já aconteceu comigo algumas vezes) pertencem a outros válidos por terem sido usados ilicitamente.

Acho que depende da nossa definição de SPAM, para mim é correio não solicitado, venha ele de um endereço que eu possa contactar ou não. E inúmeras são as vezes em que recebo SPAM de um endereço válido, peço para ser removido e volto a aparecer na lista uns meses depois. Ou passo a existir numa lista de uma empresa que nunca conheci mas que apanhou o meu e-mail.... esses são endereços válidos, mas que enviam SPAM. O mecanismo que sugeres resolve isso de que forma?

Vou ter de reler o tópico todo com mais atenção mas não estou a ver de que forma as implicações técnicas do teu sistema compensam quer a nível de custo quer a nível de usabilidade. Talvez resolva o problema que muitos dos meus clientes têm das minhas notificações serem marcadas como SPAM mesmo quando pediram para as receber.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
31 minutos atrás, redinpais disse:

Sim, vem. Um endereço falso é aquele em que se pretende perseguir judicialmente por uma má prática ou simplesmente para pedir a interrupção do abuso de envio e não se obtém resposta por não chegar ao destino. E muitas vezes esses endereços (já aconteceu comigo algumas vezes) pertencem a outros válidos por terem sido usados ilicitamente.

Aquele que vem de endereços válidos e contactáveis são num numero aceitável por qualquer destinatário e passiveis de resolver na hora qualquer litígio. 

Diria que em todos os email que uso (4 serviços diferentes), não me lembro de ter problemas com aquilo que tu chamas de emails falsos.  O maior problema são mesmo os emails válidos, de pessoas que gerem mailing lists supostamente legitimas, e que vão conseguindo manter uma reputação razoável do email (e mesmo esses só são problema em contas de serviços de menor dimensão).  Num dos serviços que uso, tenho também algum spam de contas de domínios reputados que aparentam ter sido comprometidas, e de emails de serviços que permitem a qualquer pessoa criar conta.  Em qualquer dos casos, estamos a falar de contas válidas e contactáveis.

Ou seja, do ponto de vista do utilizador, diria que estás preocupado com o problema que a maioria dos utilizadores não têm.  Até poderia concordar que "endereços válidos e contactáveis são num numero aceitável" (não é 100% verdade em alguma áreas de actividade, mas OK), mas também são estes os únicos que são visíveis à maioria dos utilizadores hoje em dia.

31 minutos atrás, redinpais disse:

Muito pelo contrário. Os milhões e milhões de emails que estariam na rede nos modelos atuais, pelo modelo P2T ficariam no remetente sem chegarem a circular na rede. Calcula-se até que existirá um expresso alivio na largura de banda.

Sim, estou ciente e completamente de acordo, mas esse problema não iria acontecer. Está previsto neste modelo P2T que o comportamento seja exatamente igual ao esperado pelos modelos atuais. Ou seja. No modelo P2T recebes no teu cliente de email/webmail a linha correspondente da mensagem para ser aberta. Quando desejas abrir a mensagem nos modelos atuais, esta mensagem já está do teu lado livrando o remetente da responsabilidade mas no modelo P2T ao desejares a mensagem ela será aberta porque nesse momento foi libertada do remetente. A dita fila de saída reduz-se de mais tarde para imediato. Neste sentido, as ditas notificações que por vezes recebemos irão chegar sem atrasos.

Há vantagens e desvantagens em enviar logo a mensagem.  Para o utilizador final, o melhor é que a mensagem seja logo enviada, pois evita atrasos (quando clico na mensagem no meu cliente POP/IMAP, ele já está na minha máquina, e não há problema se não tiver net, se estiver com uma conexão lenta, ou se o servidor do remetente estiver em baixo).  Caso contrário, o meu cliente teria que pedir a mensagem ao meu email provider, que depois ainda teria que a pedir ao remetente.

Como o @Knitter referiu, para serviços de envio de email podia complicar a gestão de picos de carga, que agora pode ser feita limitando o ritmo a que emails são enviados.  Para além disso, manter a fila de envio iria certamente encarecer o custo do envio de emails, o que era um problema para os emails legítimos.

Para os serviços de email que são usados sobretudo para receber email, seria melhor se o email ficasse no remetente mais tempo, mas também estavam sujeitos aos picos de carga provocados pelos utilizadores (actualmente os receptores podem rejeitar mensagens -- que deverão ser reenviadas mais tarde -- para lidar com picos).

31 minutos atrás, redinpais disse:

É sabido que vários estudos apontam para que existam menos de 10% de servidores que estejam devidamente configurados com esses mecanismos e lamentavelmente até em grandes players. Esses mecanismos apenas se destinam a autenticar o envio de uma organização para protegerem o seu domínio de actividades suspeitas e abusivas mas para se protegerem do que recebem têm de continuar a apostar num investimento em recursos humanos extra, financeiros e tempo por um problema causado por outros. E como é sabido, os spammers não respeitam estas regras e enquanto não os tornarem incompatíveis, nunca se conseguirá pelos processos de filtragem, que é o único processo existente de protecção.

Ainda só 10% dos servidores configuraram devidamente normas que estão em desenvolvimento há mais de 10 anos, mas estás à espera que toda a gente comece a usar o teu protocolo (que ainda para mais dizes estar patenteado) de um dia para o outro, é?

Estes mecanismos protegem quem recebe o spam de emails falsos na medida em que obrigam o spammer a ter um domínio válido, com o DNS controlado pelo ele.

1

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em 15/03/2017 às 16:27, Knitter disse:

Pelo que percebo, é sempre enviada uma mensagem ao destinatário com a indicação de que tem um e-mail para ler, não o e-mail todo mas uma informação enviada ao cliente a dizer que há um e-mail. De seguida, se o destinatário quiser abrir o e-mail dá essa instrução e a aplicação cliente vai ao servidor buscar o e-mail completo.

Ora viva...
Dito dessa maneira, dá a entender que terá de ser enviado algo a indicar que existe uma mensagem para ser recebida. Sim e não... O envio de uma notificação para que o destinatário saiba que existe uma mensagem para ser aberta, será feita de forma automática pelo servidor do lado do remetente (visto pela app cliente). Uma mensagem enviada ficará retida e no seu lugar será feita pelo sistema uma cópia da mesma mensagem sem conteúdos e seguirá exactamente pelo protocolo de email que sempre usou. Não se deseja alterações de protocolos. E o servidor não vai buscar a mensagem retida. O que acontece é que depois de clicar para abrir a mensagem, este servidor de destino executa uma flag que irá libertar a mensagem retida para finalmente ser aberta.

O numero de cliks para ter o comportamento que hoje já se tem, mantém-se. Chega a mensagem (notificação) clica para receber e esta abre.

Em 15/03/2017 às 16:27, Knitter disse:

Se o destinatário não quer ver o e-mail então não inicia a obtenção da mensagem completa. A fila de e-mail está no servidor de envio, as aplicações cliente apenas recebem uma notificação a dizer que há um e-mail para o destinatário. Se isto é assim, essa mensagem/notificação não é, ela mesma, um "e-mail"? Qual é a diferença ou como é que é feita a notificação dos destinatários?

Se o destinatário não quer ver o email, apaga essa linha da fila que está no servidor de RECEÇÃO (visto pela app cliente, tal  como acontece hoje). A diferença é que os conteúdos ficam do lado do remetente dando a este a obrigatoriedade de  ter de lidar com aquilo que o destinatário não quis. Será justo afirmar que da mesma forma que quem paga uma chamada telefónica que efetuou, por analogia, terá de ser o remetente a ter o mesmo encargo de responsabilidade.

Em 15/03/2017 às 16:27, Knitter disse:

Se for eu a suportar os custos deste serviço terei de desligar as notificações porque o custo mensal para suporte de picos é grande.

As notificações não "custam" nada do lado do destinatário. Nem tempo, nem trabalho, nem mudança de hábitos.

Certamente que a responsabilidade onerosa é maior do lado do remetente, mas é isso mesmo que se pretende. A capacidade de proteção é demasiado grande para que um destinatário tenha de lidar com lixo (ou não) provocado por terceiros. O objetivo aqui é levar a uma troca de responsabilidades. É justo que assim seja.

Pense assim desta forma. Se você como remetente, actualmente terá de investir em "artifícios" para levar a que o destinatário seja convidado a receber publicidade, esse "artifício" também é pago por si. Normalmente uma empresa que envia publicidade por si, custa-lhe dinheiro. Pelo método P2T, o remetente não terá de o fazer porque está implícito no modo como  servidor o faz. O custo através de um sistema P2T apenas está no incomodo de ter de ser o remetente a limpar caixas de envio que antes seria o destinatário a fazê-lo.

Em 15/03/2017 às 16:27, Knitter disse:

Acho que depende da nossa definição de SPAM, para mim é correio não solicitado, venha ele de um endereço que eu possa contactar ou não.

Completamente de acordo. Quantas vezes, recebemos mensagens que por hábito são recebidas por mero "gozo" e posteriormente teremos de ser inconvenientes para o nosso "amigo" e dizer-lhe que para já não queremos mais. No modelo P2T temos essa liberdade sem "ferir" quem quer que seja. Hoje você não quer receber, mas outro dia qualquer se a desejar, então clica na linha do seu cliente e nessa altura vai receber.

Em 15/03/2017 às 16:27, Knitter disse:

E inúmeras são as vezes em que recebo SPAM de um endereço válido, peço para ser removido e volto a aparecer na lista uns meses depois.

Ok, fixe. Não me importo que isso venha a acontecer com o modelo P2T. É o remetente que vai ter de lidar com as mensagens. Ele tem de ter p.ex. 1 milhão de mensagens a aguardar a recepção e 1 milhão de utilizadores recebe apenas uma notificação. Quem fica a perder?

 

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em 15/03/2017 às 18:28, Rui Carlos disse:

Ou seja, do ponto de vista do utilizador, diria que estás preocupado com o problema que a maioria dos utilizadores não têm.

Está calculado que o valor que todos pagamos para ter um serviço de proteção de spam é pago pelos utilizadores (http://p2t.email/redin/o-verdadeiro-custo-do-spam/). Não seria preciso se os sistemas não teimassem com métodos de filtragem que em nada tem resolvido.
E essa percepção que tens apenas está a ser entendida do lado de um utilizador particular. Não sou eu que o digo, são as estatísticas e os relatórios que saem com frequência.

Em 15/03/2017 às 18:28, Rui Carlos disse:

Há vantagens e desvantagens em enviar logo a mensagem.  Para o utilizador final, o melhor é que a mensagem seja logo enviada, pois evita atrasos (quando clico na mensagem no meu cliente POP/IMAP, ele já está na minha máquina, e não há problema se não tiver net, se estiver com uma conexão lenta, ou se o servidor do remetente estiver em baixo).  Caso contrário, o meu cliente teria que pedir a mensagem ao meu email provider, que depois ainda teria que a pedir ao remetente.

Não existirá o tal atraso de que falas. O acesso à mensagem é instantânea. Se não tiveres net, as mensagens não se perdem. No modelos atuais, se também não tiveres net, não recebes a mensagem porque até que a possas abrir ela não está contigo, mas sim no servidor (do teu lado). (A não ser que já a tenhas aberto antes da falha).
Com o modelo P2T é igual.
Quando clicas a aceitar e ela se abrir, noutra altura em que fiques sem net vais manter a visualização da mensagem. É tal como acontece num smartphone. Ao abrires uma mensagem P2T, ela irá manter-se no teu smartphone mesmo que percas a rede. Quando a rede voltar, continuas a interagir com ela, tal como acontece com o tradicional. 

 

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
4 horas atrás, redinpais disse:

Ora viva...
Dito dessa maneira, dá a entender que terá de ser enviado algo a indicar que existe uma mensagem para ser recebida. Sim e não... O envio de uma notificação para que o destinatário saiba que existe uma mensagem para ser aberta, será feita de forma automática pelo servidor do lado do remetente (visto pela app cliente). Uma mensagem enviada ficará retida e no seu lugar será feita pelo sistema uma cópia da mesma mensagem sem conteúdos e seguirá exactamente pelo protocolo de email que sempre usou. Não se deseja alterações de protocolos. E o servidor não vai buscar a mensagem retida. O que acontece é que depois de clicar para abrir a mensagem, este servidor de destino executa uma flag que irá libertar a mensagem retida para finalmente ser aberta

Então, pelo que entendo, funciona como se antes de enviar o e-mail completo enviasse um e-mail só com o assunto da mensagem. Neste caso:

  1. o servidor de envio envia um e-mail ao servidor onde estão as caixas do destinatário;
  2. o utilizador, usando um cliente de e-mail, acede ao seu servidor de correio, marca uma das mensagens como sendo uma mensagem a receber;
  3. o servidor com as caixas de correio do destinatário encaminha essa informação para o servidor de envio;
  4. o servidor de envio devolve o e-mail completo ao servidor do destinatário;
  5. o cliente de e-mail apresenta o e-mail completo ao utilizador.
4 horas atrás, redinpais disse:

As notificações não "custam" nada do lado do destinatário. Nem tempo, nem trabalho, nem mudança de hábitos.

Sim, já entendi que o objetivo do sistema é aumentar os encargos para quem envia e-mail, a minha questão não se prende com o correio ilegítimo mas sim com o correio legítimo e com os encargos para quem o envia. Num dos meus sistemas existem e-mails de notificação importantes para os meus clientes, é um serviço sem custos para eles mas tem custos para mim, porque é que eu hei-de escolher uma tecnologia diferente com custos mais elevados? Ou passo o custo para o cliente, porque não tenho capacidade para manter um servidor com os recursos que se esperam, ou removo o serviço. A minha dúvida prende-se com que vantagens existem para quem envia os e-mails e que passará a pagar mais por isso?

É claro que percebo que, se o ónus da infraestrutura está do lado de quem envia, existirá menos vantagens em abusar do serviço, mas ao mesmo tempo vejo as notificações de e-mail iguais ao e-mail, sendo que se pretendesse fazer SPAM podia usar essas notificações para isso mesmo. Claro que não existiram SPAM no corpo da notificação (é só o assunto) mas não é o que se passa hoje também? Ou os utilizadores além de lerem o assunto nas mensagens de SPAM vão abrir essas mensagens e ler o conteúdo?

Bem, é mais um sistema, espero que tenhas sucesso na sua implementação, como utilizador gostava de ver uma redução de SPAM, como alguém que gere serviços que enviam muito e-mail (todo legítimo, mesmo as newslettes requerem inscrição explicita), gostava que uma tecnologia nova não aumentasse ainda mais os custos que este tipo de envios tem.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
5 horas atrás, redinpais disse:

Se o destinatário não quer ver o email, apaga essa linha da fila que está no servidor de RECEÇÃO (visto pela app cliente, tal  como acontece hoje). A diferença é que os conteúdos ficam do lado do remetente dando a este a obrigatoriedade de  ter de lidar com aquilo que o destinatário não quis. Será justo afirmar que da mesma forma que quem paga uma chamada telefónica que efetuou, por analogia, terá de ser o remetente a ter o mesmo encargo de responsabilidade.

As notificações não "custam" nada do lado do destinatário. Nem tempo, nem trabalho, nem mudança de hábitos.

Não custam nada?  Das duas uma, ou o utilizador nem chega a ver a notificação -- e nesse caso é porque existe algum sistema de filtragem a filtrar as notificações relativas a spam --, ou então tens que andar a rever as notificações para dar a "ordem" de abrir ou não a mensagem completa!

Ora, o único ganho que vejo nisto é no tráfego de rede nas mensagens descartadas.  Mas ou tens o tal sistema de filtragem de notificações, ou num email com alguns anos a ser divulgado publicamente, passavas o dia o rever notificações à mão!

Adicionalmente, como é que o remetente sabe que a mensagem que ele tem retida é para apagar porque o destinatário a descartou?  É que há email legítimo que o destinatário não lê por variadas razões.  E ou o destinatário notifica o remetente, ou o remetente mantém a mensagem indefinidamente, ou vão haver emails perdidos.  Esta e outras complexidades adicionais parecem-me motivos suficientes para esquecer-mos os ganhos de tráfego.

5 horas atrás, redinpais disse:

Certamente que a responsabilidade onerosa é maior do lado do remetente, mas é isso mesmo que se pretende. A capacidade de proteção é demasiado grande para que um destinatário tenha de lidar com lixo (ou não) provocado por terceiros. O objetivo aqui é levar a uma troca de responsabilidades. É justo que assim seja.

É justo, então não é, até ao dia em que te começarem a cobrar para enviares emails.

É curioso que tenho ideia que o ViaCTT não tem spam.  Curiosamente também "ninguém" o usa, mas se queres um email sem spam já tens uma solução...

Há serviços hoje em dia a cortar nas notificações por email devidos aos custos de envios (é que ao contrário do que muita gente pensa,  envio de emails não é de graça).  Aumentos de custos iam aumentar este "problema".

5 horas atrás, redinpais disse:

Está calculado que o valor que todos pagamos para ter um serviço de proteção de spam é pago pelos utilizadores (http://p2t.email/redin/o-verdadeiro-custo-do-spam/). Não seria preciso se os sistemas não teimassem com métodos de filtragem que em nada tem resolvido.
E essa percepção que tens apenas está a ser entendida do lado de um utilizador particular. Não sou eu que o digo, são as estatísticas e os relatórios que saem com frequência.

Como já referi, só o facto de uma "notificação" ser na mesma enviada para o destinatário significa que íamos continuar a ter spam.

(E a percepção que tenho é a percepção de vários utilizadores que usam determinados serviços de email.)

5 horas atrás, redinpais disse:

No modelos atuais, se também não tiveres net, não recebes a mensagem porque até que a possas abrir ela não está contigo, mas sim no servidor (do teu lado). (A não ser que já a tenhas aberto antes da falha).

No sistema actual, o meu cliente POP/IMAP faz download da mensagem antes de eu a abrir.  É isto que permite que a abertura da mensagem seja instantânea, mesmo quando estou sem net.

Quando falámos de um cliente web (onde precisámos de rede), no teu modelo não consegues abrir a mensagem se o servidor do remetente falhar (ou seja, acrescentas um ponto de falha).

(Nem vou comentar o "Não existirá o tal atraso de que falas", pois parece-me que não fazes ideia do que é lidar com sistemas de larga escala...)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
15 horas atrás, Knitter disse:

Então, pelo que entendo, funciona como se antes de enviar o e-mail completo enviasse um e-mail só com o assunto da mensagem. Neste caso:

Correto.
Obviamente que para efeitos de segurança, o assunto teria de ser limitado a texto sem formatação.

Fica porém a noção de que os spammers podem continuar a "bombardear" os destinatários com mensagens "subliminares" através do assunto. Uma das particularidades nos modelos atuais onde isso ainda existe, é o fator de identificação do remetente que na sua grande maioria fica mascarado com endereços difíceis de tracking.
Num modelo P2T o endereço é sempre validado, seja por confirmação no momento de subscrição no ISP ou por subscrição de um utilizador tradicional que deseje continuar a se comunicar com endereços P2T.

15 horas atrás, Knitter disse:

porque é que eu hei-de escolher uma tecnologia diferente com custos mais elevados? Ou passo o custo para o cliente, porque não tenho capacidade para manter um servidor com os recursos que se esperam, ou removo o serviço. A minha dúvida prende-se com que vantagens existem para quem envia os e-mails e que passará a pagar mais por isso?

É claro que não será apetecível a um remetente ter estas dificuldades acrescidas, mas é precisamente este o intuito de um modelo antispam.
Mesmo sem existir o P2T, os remetentes atuais também sofrem a necessidade de melhorar os seus meios de envio para ultrapassar as barreiras dos modelos baseados em filtragem. Para poderes usufruir desse serviço de envio "inteligente" também pagas por isso.
Portanto, se o teu objetivo é enviar email sem custo, lamento mas o P2T não te vai ajudar. O objetivo de um modelo antispam é ajudar os destinatários mas lamentavelmente são eles que estão a pagar para uma proteção que será (legal ou ilegalmente) provocada por outros.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
13 horas atrás, Rui Carlos disse:

Não custam nada?  Das duas uma, ou o utilizador nem chega a ver a notificação -- e nesse caso é porque existe algum sistema de filtragem a filtrar as notificações relativas a spam --, ou então tens que andar a rever as notificações para dar a "ordem" de abrir ou não a mensagem completa!

Ora, o único ganho que vejo nisto é no tráfego de rede nas mensagens descartadas.  Mas ou tens o tal sistema de filtragem de notificações, ou num email com alguns anos a ser divulgado publicamente, passavas o dia o rever notificações à mão!

Porque razão o utilizador não iria chegar a ver as notificações? O servidor que se pretende construir não vai usar qualquer tipo de filtragem de conteúdos.
O trabalho de segurança para evitar propagação de virus ou ameacas continuará a pertencer a outros sistemas de software do mercado, mas objectivamente, o software antispam deixa de fazer sentido  e mesmo que alguém assuma o seu interesse, a carga de trabalho passaria de volumosa para incrivelmente ridícula. O investimento para software antispam num modelo P2T deixa de ser compensatório.

13 horas atrás, Rui Carlos disse:

Adicionalmente, como é que o remetente sabe que a mensagem que ele tem retida é para apagar porque o destinatário a descartou?  É que há email legítimo que o destinatário não lê por variadas razões.  E ou o destinatário notifica o remetente, ou o remetente mantém a mensagem indefinidamente, ou vão haver emails perdidos.  Esta e outras complexidades adicionais parecem-me motivos suficientes para esquecer-mos os ganhos de tráfego.

Está prevista essa funcionalidade de que falas. Só não a referi por ser demasiado extensa para ser explicada no contexto deste fórum. O remetente pode ou não vir a saber a causa da recusa na aceitação de uma mensagem. É uma configuração parametrizável.

13 horas atrás, Rui Carlos disse:

É curioso que tenho ideia que o ViaCTT não tem spam.  Curiosamente também "ninguém" o usa, mas se queres um email sem spam já tens uma solução...

Há serviços hoje em dia a cortar nas notificações por email devidos aos custos de envios (é que ao contrário do que muita gente pensa,  envio de emails não é de graça).  Aumentos de custos iam aumentar este "problema".

Eu sempre apoiei iniciativas tal como os ViaCTT onde, para se ter uma troca de correspondência oficial, usaríamos os portais deles. O único problema para a massificação da comunicação por email é exactamente o facto de ser necessário uma autenticação diferente para cada serviço e abrir p.ex. 20 portais diferentes para enviar mensagens para 20 utilizadores desses portais. Mas é como dizes, não tem spam e compreende-se porquê. Está para breve uma iniciativa governamental para a criação de uma morada digital e tal como a CNPD diz, esse será um erro de segurança quando o seu portal deveria proporcionar esse serviço tal como acontece com o ViaCTT. A poder existir um dia a "Morada Digital" ela seria apenas bem vinda com uma simples mensagem de email somente no assunto uma frase "Visite o seu portal das finanças. Tem uma mensagem para ler".

14 horas atrás, Rui Carlos disse:

Como já referi, só o facto de uma "notificação" ser na mesma enviada para o destinatário significa que íamos continuar a ter spam.

Já respondi a esse problema através de resposta ao Knitter.

 

14 horas atrás, Rui Carlos disse:

(Nem vou comentar o "Não existirá o tal atraso de que falas", pois parece-me que não fazes ideia do que é lidar com sistemas de larga escala...)

Convido-te a fazê-lo.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
21 horas atrás, redinpais disse:

Num modelo P2T o endereço é sempre validado, seja por confirmação no momento de subscrição no ISP ou por subscrição de um utilizador tradicional que deseje continuar a se comunicar com endereços P2T.

Um sistema de validação está algures entre o facilmente acessível (nomeadamente para spammers) e o nada acessível (que afasta os utilizadores legítimos).

Os serviços de email actuais andarão num meio termo, implementando alguns mecanismos de validação, mas sem comprometer a massificação do serviço.  Adicionalmente, funcionam sem mecanismo de validação centralizado, o que mais uma vez é importante para a massificação do serviço, mas limita a possibilidade de implementar validações robustas.  Era trivial implementar uma validação de entidades baseada em certificados digitais (toda a infraestrutura já está montada), mas isso mataria o email enquanto método "universal" para comunicação.

A questão da massificação é essencial, pois qualquer alternativa que surja, por mais perfeita que seja, ou atinge um nível de massificação semelhante ao email, ou continua toda a gente a ter que usar email, com todos os custos associados, aos quais acrescem depois os custos da alternativa.

Seria interessante também começares a estimar os custos da validação das entidades (e já agora, de aumentar a capacidade dos servidores de envio de email, por exemplo), para saberes quanto custa combater o spam com o teu sistema.

Temos ainda o problema de privacidade que representa a validação.

Citação

[...] o software antispam deixa de fazer sentido  e mesmo que alguém assuma o seu interesse, a carga de trabalho passaria de volumosa para incrivelmente ridícula. O investimento para software antispam num modelo P2T deixa de ser compensatório.

Ainda não indicaste nada em concreto que permita concluir que não vai haver aumento do spam através de notificações com a remoção dos sistemas anti-spam.

Citação

Está prevista essa funcionalidade de que falas. Só não a referi por ser demasiado extensa para ser explicada no contexto deste fórum. O remetente pode ou não vir a saber a causa da recusa na aceitação de uma mensagem. É uma configuração parametrizável.

Resumindo, há a hipótese de nunca saberes quando é que podes eliminar uma mensagem.

Um outro problema das notificações e dos pedidos das mensagens está ao nível da privacidade.  Ou abres as mensagens todas (e nesse caso lá se vai a poupança no tráfego), ou o remetente fica sempre a saber quais as mensagens que abriste.

Citação

Eu sempre apoiei iniciativas tal como os ViaCTT onde, para se ter uma troca de correspondência oficial, usaríamos os portais deles. O único problema para a massificação da comunicação por email é exactamente o facto de ser necessário uma autenticação diferente para cada serviço e abrir p.ex. 20 portais diferentes para enviar mensagens para 20 utilizadores desses portais.

O ViaCTT tem muitos problemas.  Um dos que mais afecta a massificação do serviço é precisamente um dos que mais contribui para não haver spam: a necessidade de validar a identificação da entidade a quem pertence a conta.  Usar este sistema a nível global é simplesmente impensável.  E mesmo a nível nacional, nem com o "empurrão" do estado se consegue impor.

Como já referi, sem massificação é só mais um sistema, para além do email.

Citação

Convido-te a fazê-lo.

Para te dar um exemplo simples, a abertura de uma página web é suposto ser também instantânea.  Ainda assim, vários browsers hoje em dia têm a funcionalidade de carregar páginas em background antes de as abrires.  Por que o fazem se podiam carregar a página "instantaneamente" depois do utilizador clicar no link?  Também estão só a desperdiçar tráfego?

Adicionalmente, sabes que os servidores SMTP usam habitualmente filas para gerir a carga, certo?  Isto para além de alguns serviços definirem quotas para o software cliente.  Assim podes dimensionar o teu servidor para a carga média (ou um pouco mais).  Agora muda o cenário para o teu sistema, em que tens um servidor de envio de newsletters, que passa a ter que lidar com picos de pessoal que chega ao trabalho de manhã, começa a processar os emails, e ficas com o servidor a ter que enviar naquele momento os emails todos que podiam ter sido enviados algures durante a noite.  Junta a isto o facto de teres que guardar os emails numa "base de dados" indexada (em vez de teres simples filas), dos sistemas não escalarem linearmente com aumentos de concorrência e de teres que melhorar a tolerância a falhas (para não teres utilizadores que receberam notificações mas não conseguem abrir o email), e pensa em quantas vezes terias que aumentar a dimensão dos sistemas para que os emails não demorassem mais do dobro do tempo a abrir do que demoram actualmente (vamos esquecer o abrir instantaneamente, pois só num sistema que faça pre-fetch dos emails -- como por exemplo o Gmail e IMAP/POP -- e talvez com servidores locais é que consegues a aparência de abertura instantânea, ou sequer de abrir no mesmo tempo que abrem agora, pois há mais uma comunicação remota a fazer, com um componente que tem tudo para ser o bottleneck do sistema).

E já agora não sei se a tua proposta contempla uma alternativa ao protocolo SMTP, mas se não contempla era capaz de ser boa ideia pensares numa...  É que o SMTP é tudo menos um protocolo para trocas de mensagens "instantâneas".

1

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
14 horas atrás, Rui Carlos disse:

Seria interessante também começares a estimar os custos da validação das entidades (e já agora, de aumentar a capacidade dos servidores de envio de email, por exemplo), para saberes quanto custa combater o spam com o teu sistema.

É muito interessante esse teu ponto de vista e importante para um contributo de melhoria, mas não seria já uma novidade na minha linha de pensamento. Pretendo exactamente chegar a esse meio termo sem comprometer essa massificação mas a única forma de poder chegar a essa conclusão, será a construção de um MVP simplista para submeter a testes e tirar nesse momento essas conclusões. Posteriormente poderiam colocar-se em hipótese as afinações ao conceito.

Não é à toa quando digo que eu estou disponível para oferecer 90% da exploração da minha patente. As minhas competências a nível de programação são zero e daí que necessito de alguém que assuma essa posição. Estou a pensar na construção de um servidor em Java. Existe publicamente código que poderá ser aproveitado para ser alterado de acordo com as especificações da patente e criar uma comunidade interessada em participar em testes. As condicionantes legais não seriam importantes nesta fase porque iriam apenas serem necessárias para prova de conceito. Escolhi o Java por ser aquela hipótese que é transversal a qualquer sistema operativo sem obrigar a criar MVPs diferentes.

Poderíamos falar sobre isso numa reunião presencial?

14 horas atrás, Rui Carlos disse:

Ainda não indicaste nada em concreto que permita concluir que não vai haver aumento do spam através de notificações com a remoção dos sistemas anti-spam.

Como deves imaginar, levar a uma explicação em concreto seria enfadonho poder explicar por esta via. Através dos fluxogramas e reivindicações explicadas na patente consigo dar-te essa "imagem" do conceito.

14 horas atrás, Rui Carlos disse:

Resumindo, há a hipótese de nunca saberes quando é que podes eliminar uma mensagem.

Um outro problema das notificações e dos pedidos das mensagens está ao nível da privacidade.  Ou abres as mensagens todas (e nesse caso lá se vai a poupança no tráfego), ou o remetente fica sempre a saber quais as mensagens que abriste.

Sejamos realistas. Se eu para saber que vale a pena ou não abrir ou apagar uma mensagem, tiver que a abrir primeiro, perde-se o interesse em proteger o destinatário. O "mal" já está feito e o trabalho do spammer ficará aliviado. Voltaríamos à estaca zero.

Mais importante do que ficares com a duvida de saberes quando abrir ou eliminar uma mensagem é o facto de que o potencial spammer fica a saber que ao aderir a um sistema P2T vai ter de ser ele agora a lidar com correio que não foi desejado. Se eu for uma empresa que deseje manter uma reputação forte, qualquer mensagem enviada pelo sistema P2T, permite criar uma sensação de credibilidade e de interesse, levando a que com grande probabilidade deixe de ter mensagens bloqueadas para envio. Ao passo que um spammer alem de correr riscos de traking facilitado, tem de ponderar o tipo de mensagens que envia sob pena de ter de perder tempo na sua gestão.

15 horas atrás, Rui Carlos disse:

os servidores SMTP usam habitualmente filas para gerir a carga

Sobre um sistema de larga escala.
Um modelo baseado em paginas web, percebe-se bem o interesse em aliviar essa carga. É do interesse deles que o façam, mas o utilizador final que as recebe nos seus browsers não se queixa disso, porque só vai ver essas páginas no momento em que o deseja. O ónus fica do lado do dono do website e é justo que assim o seja.

Mas no caso do email já se passa ao contrário. É o utilizador que é bombardeado com tráfego sem o ter pedido para tal.

Eu ainda pensei no inicio do meu estudo num principio baseado em download direto para o computador do utilizador mas isso iria implicar que tivesse de transportar sempre consigo o mesmo dispositivo para ler a mensagem que antes tinha transferido.

A carga e cotas de cliente estão sempre maioritariamente do lado do destinatário. Com o modelo P2T este problema será transferido para o remetente. Este balanceamento será posteriormente aliviado pela inexistência de tráfego inútil a circular na rede. É insustentável que seja o destinatário a pagar a factura tal como o documento que te indiquei num post anterior sobre os custos do spam.

Gostei da vossa abordagem de critica construtiva que me leva a ponderar em alguns factos de melhoria. Contudo, como disse no inicio, se estiverem interessados em discutir interesses mútuos, terei todo o prazer em o fazer presencialmente. Mais que não seja, para podermos beber um café ou uma "bejeca" de forma divertida.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

redinpais: acho que não estás a compreender o impacto dos problemas que já foram identificados e que a postura na discussão é demasiado defensiva. Os comentários do Rui Carlos foram bastante detalhados e valem ouro; numa situação normal seria necessário pagar por uma análise deste género. 

Eu vou sumarizar em dois pontos simples qual o motivo de uma abordagem deste género estar condenada ao fracasso:

  1. A solução não é uma alternativa ao email. Neste momento já existem soluções alternativas onde o spam é nulo, portanto esta solução não tem qualquer interesse se assumirmos uma stack tecnológica toda nova.
  2. A solução não funciona como complemento ao email. Uma pergunta simples: o que faz a caixa de entrada se uma mensagem não obedecer ao protocolo?
    1. Ou a mostra tal como agora, de modo que não impede spam. Basta quem envia o spam ignorar as mudanças.
    2. Não a mostra, pelo que obriga todos os remetentes a obedecer ao protocolo. Se vamos obrigar os remetentes a fazer algo diferente, então mais vale criar uma alternativa decente de raiz em vez de um "patch" ao email actual.

Sem ser possível resolver este problema de base, não existe nenhuma possibilidade desta solução ver a luz do dia.

Editado por Warrior
1

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
3 minutos atrás, Warrior disse:

Os comentários do Rui Carlos foram bastante detalhados e valem ouro; numa situação normal seria necessário pagar por uma análise deste género. 

Bom dia Warrior

Se tiveste a oportunidade de ler o meu post anterior, eu acabei por agradecer as criticas construtivas que me fizeram garantindo que irão ser úteis para uma necessidade de melhoramento.

É da discussão que se encontram soluções e a minha intervenção defensiva tem sentido se eu tiver de comentar os teus 2 últimos pontos. É estranho que se continue a apostar em ferramentas de proteção que são consumidas baseadas na reação e não na prevenção. Esta constante corrida do "gato e rato" ou do "policia e ladrão" já tem quase 40 anos. E porque não apostar numa nova stack tecnológica? Onde é que está o mal? Não me parece que estejamos perante um paradigma. Recuso-me a pensar nisso.

Agora que me venhas dizer que estão implícitos vários tipos de interesse em lóbis, isso já estou de acordo. O tráfego na rede seja ele legal ou ilegal gera muitíssimo valor.

Os protocolos existentes podem continuar a existir se ponderarmos apenas a gestão interna de como a informação é tratada. O protocolo apenas define regras e a forma como a informação é trocada entre dispositivos diferentes mas não impede que dentro desses dispositivos seja utilizada um controlo diferente. Os routers da Cisco não são diferentes disso. A Cisco tem os seus dispositivos a cumprir os mesmos protocolos de comunicação de rede mas internamente funcionam de forma diferente em que entre eles existem outros protocolos construídos para se comunicarem, visto que são equipamentos de modelo proprietário.

Os servidores P2T irão funcionar nessa análise e nesse principio.

Para haver uma discussão, tem de haver no mínimo duas pessoas, tal como para dançar o tango. Sendo assim, estou muito longe de me sentir isolado. Havendo discussão, existe interesse. Se não quiseres participar, então tens duas soluções. Ou és inconveniente ( e não acredito que o sejas ) e começas a criticar sem nexo no tipo "bota a baixo" ou simplesmente ignoras e não respondes.

De outra forma és sempre bem-vindo, tal como em forma de terminar, agradeço as tuas palavras e as tuas opiniões são sempre bem-vindas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
1 hour ago, redinpais said:

E porque não apostar numa nova stack tecnológica? Onde é que está o mal? Não me parece que estejamos perante um paradigma. Recuso-me a pensar nisso.

Mas isto já foi feito. Acontece que desistindo da backwards compatibility com o email, deixas de lhe chamar email. Passas a chamar snapchat, ou hangouts, ou whatsapp, ou telegram, ou qualquer uma de outras aplicações que alteraram a stack e desistiram de ser compatíveis com o email. Esse caminho já foi trilhado variadíssimas vezes, e na minha opinião é o que vai acontecer a médio prazo. 

1 hour ago, redinpais said:

Agora que me venhas dizer que estão implícitos vários tipos de interesse em lóbis, isso já estou de acordo. O tráfego na rede seja ele legal ou ilegal gera muitíssimo valor.

Lobies a favor do spam? Longe disso, nem quem faz software nem que gere a rede tem interesse em defender o spam.

Voltamos ao problema que levantei: se vai ser backwards compatible com email, então de que maneira resolves o problema do spam? O spam pode ignorar o protocolo novo. 

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Obrigado Warrior  pelas tuas questões:

22 horas atrás, Warrior disse:

Lobies a favor do spam? Longe disso, nem quem faz software nem que gere a rede tem interesse em defender o spam.

Então de que outra forma se pode explicar o seguinte?

- Faz já para o próximo mês de abril, 39 anos que existe spam de email.
- Todos os métodos de combate a esta praga prometem capacidades de filtragem na ordem dos 99,99%.
- A tecnologia melhora quase dia a dia de forma exponencial.
- Os grandes players do mercado de segurança não apresentam soluções que demonstrem sustentabilidade.

... e no entanto o spam continua a apresentar prejuizos descomunais todos os anos, estando neste momento nos 65% de penetração nas redes.

a minha resposta está apenas nos métodos utilizados e que não têm mudado em todos estes anos. Filtragem.
Está visto e provado que este tipo de receita não funciona e por causa disto estaremos todos condenados?

22 horas atrás, Warrior disse:

Voltamos ao problema que levantei: se vai ser backwards compatible com email, então de que maneira resolves o problema do spam? O spam pode ignorar o protocolo novo.

Sim, vai.
Que tipo de interesse tens em entrar em detalhes? Apenas por mera curiosidade ou para um provável interesse técnico no seu desenvolvimento?

Se for meramente por curiosidade, podes consultar a minha patente em http://www.marcasepatentes.pt/files/collections/pt_PT/49/55/533/569/2015-11-20.pdf
página 98 tem lá o link para fazeres o download.

Se for por interesse técnico para investigar um possível interesse no desenvolvimento, podermos falar pessoalmente.

Em final de comentário, penso já o ter afirmado antes. Não se pretende ignorar os protocolos atuais de comunicação, mas sim criar novos de controlo entre servidores P2T em modelo proprietário.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
15 minutes ago, redinpais said:

Então de que outra forma se pode explicar o seguinte?

- Faz já para o próximo mês de abril, 39 anos que existe spam de email.
- Todos os métodos de combate a esta praga prometem capacidades de filtragem na ordem dos 99,99%.
- A tecnologia melhora quase dia a dia de forma exponencial.
- Os grandes players do mercado de segurança não apresentam soluções que demonstrem sustentabilidade.

... e no entanto o spam continua a apresentar prejuizos descomunais todos os anos, estando neste momento nos 65% de penetração nas redes.

O facto do spam existir não prova a existência de lobbying, isso é uma falácia argumentativa.

16 minutes ago, redinpais said:

Que tipo de interesse tens em entrar em detalhes? Apenas por mera curiosidade ou para um provável interesse técnico no seu desenvolvimento?

Se for meramente por curiosidade, podes consultar a minha patente em http://www.marcasepatentes.pt/files/collections/pt_PT/49/55/533/569/2015-11-20.pdf
página 98 tem lá o link para fazeres o download.

Se for por interesse técnico para investigar um possível interesse no desenvolvimento, podermos falar pessoalmente.

Em final de comentário, penso já o ter afirmado antes. Não se pretende ignorar os protocolos atuais de comunicação, mas sim criar novos de controlo entre servidores P2T em modelo proprietário.

Investi parte do meu tempo a explicar o motivo de não arranjares ninguém disposto a desenvolver: porque a ideia tem falhas graves. Não tenho tempo para ler a patente, até porque sei por experiência própria que são documentos difíceis de compreender devido ao legalês necessário. Se conseguires perceber o motivo da tua ideia não funcionar, então podes poupar tempo no futuro. Se pretendes ignorar os seus problemas, então boa sorte, mas um inventor ou empreendedor devia ser o maior crítico, nunca o maior defensor.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sinceramente partilho da opinião já referida pelo @Rui Carlos: não tenho grande problema em utilizar publicamente o meu endereço de email, uma vez que mais cedo ou mais tarde, mesmo que eu o proteja com unhas e dentes, alguém há-de incluí-lo numa cadeia de "Re: Fw: FW: RE: FWD:".

Além do referido, saliento que hoje em dia os filtros contra spam são bastante bons, e de facto vejo cada vez mais pessoas (leigos) a queixarem-se de falsos positivos do que do inverso, no que toca a spam.

Por estes motivos e pelos expostos tanto pelo @Rui Carlos como pelo @Knitter e @Warrior, a ideia do P2T parece-me pouco sustentável. Não estou tão por dentro dos pormenores técnicos por eles referidos, mas percebo o suficiente para certas características enunciadas me preocuparem no que diz respeito à credibilidade da conceptualização do serviço -- p.ex. as mensagens que são entregues "instantaneamente", a falta de substância no que diz respeito a distribuição de carga e picos de transmissão de dados (já que o envio é deferido até que o leitor o decida ler). Tudo isto já foi apontado, sem respostas concretas.

Sinceramente, já faz alguns anos desde que recebi no meu email principal qualquer tipo de spam (o serviço que utilizo nem sequer tem uma opção para ver o Spam, como existe no Gmail, o server pura e simplesmente recusa Spam).

Não considero este tema um não-problema, mas diria que há coisas mais importantes a resolver no email, como por exemplo a autenticação das mensagens entregues, entre outros. Isso sim é um flagelo nos dias de hoje, com tanto esquema de phishing que por aí anda...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em 22/03/2017 às 11:54, redinpais disse:

Sejamos realistas. Se eu para saber que vale a pena ou não abrir ou apagar uma mensagem, tiver que a abrir primeiro, perde-se o interesse em proteger o destinatário. O "mal" já está feito e o trabalho do spammer ficará aliviado. Voltaríamos à estaca zero.

Mais importante do que ficares com a duvida de saberes quando abrir ou eliminar uma mensagem é o facto de que o potencial spammer fica a saber que ao aderir a um sistema P2T vai ter de ser ele agora a lidar com correio que não foi desejado. Se eu for uma empresa que deseje manter uma reputação forte, qualquer mensagem enviada pelo sistema P2T, permite criar uma sensação de credibilidade e de interesse, levando a que com grande probabilidade deixe de ter mensagens bloqueadas para envio. Ao passo que um spammer alem de correr riscos de traking facilitado, tem de ponderar o tipo de mensagens que envia sob pena de ter de perder tempo na sua gestão.

Aquilo que estava a discutir no texto que originou esta resposta era sobre o problema de eliminar mensagens que o utilizador não quer ler (como é que o servidor remetente sabe quando eliminar, particularmente se forem mensagens legítimas mas que o utilizador não leu), e como resolver o problema de privacidade.  Depois de ler a patente, fica a ideia que a abordagem tem todo o potencial para criar "mail leaks" (mails que ninguém quer ler, mas quem armazena o email não sabe disso).

Quanto ao spammer ter que gerir as mensagens, a consequência óbvia, como já foi referido, seria o spam passar para os assuntos (coisa para a qual já disseste ter solução, mas que eu ainda não percebi qual era, nem depois de ver a patente, a menos que queiras impor mecanismos de validação de identidade que resultem num novo ViaCTT que ninguém usa).

Citação

Sobre um sistema de larga escala.
Um modelo baseado em paginas web, percebe-se bem o interesse em aliviar essa carga. É do interesse deles que o façam, mas o utilizador final que as recebe nos seus browsers não se queixa disso, porque só vai ver essas páginas no momento em que o deseja. O ónus fica do lado do dono do website e é justo que assim o seja.

Mas no caso do email já se passa ao contrário. É o utilizador que é bombardeado com tráfego sem o ter pedido para tal.

A referência aos websites veio a propósito do "instantâneo", e do facto de passar a gestão para quem envia ter vários tradeoffs para quem recebe (o ponto da privacidade para mim é suficiente para preferir o modelo actual).

Mas relativamente a quem deve ter o ónus depende do email.  No spam é óbvio que é o remetente.  Num serviço de notificações em que é o utilizador que quer receber o email, por exemplo, o interesse é do destinatário.  Quando um professor envia material didáctico ou avisos aos alunos, o interesse é do destinatário.  Quando alguém dá uma resposta a a outra pessoa por email, o interesse é dos destinatário.  Há muitos outros exemplos em que o destinatário é quem tem mais interesse no email, e como tal devia ser ele a gerir a maior parte dos custos com a sua gestão.

Citação

A carga e cotas de cliente estão sempre maioritariamente do lado do destinatário. Com o modelo P2T este problema será transferido para o remetente. Este balanceamento será posteriormente aliviado pela inexistência de tráfego inútil a circular na rede. É insustentável que seja o destinatário a pagar a factura tal como o documento que te indiquei num post anterior sobre os custos do spam.

A carga e quotas também estão no remetente (até diria que estão maioritariamente no remetente).  Tens organizações com newsletters (legítimas) com milhares (ou até milhões) de destinatários. Há sites com milhares de notificações enviadas por dia.  Há mailing lists com milhares de emails trocados por dia (enviados a partir de um mesmo servidor). É mais comum um utilizador querer enviar uns milhares/milhões de emails "de uma vez" (ou que seja num dia) do que um destinatário receber uma carga semelhante de emails.

O único custo que o destinatário veria reduzido é o do tráfego e algum armazenamento.  Tenho dúvidas que isto seja um problema tendo em conta os padrões de utilização da net hoje em dia, com serviços de streaming cada vez mais populares, utilização de imagens e vídeos quando texto era suficiente, etc. (i.e. desperdícios de tráfego por todo o lado).  Adicionalmente os ganhos de armazenamento parece-me reduzidos, mas dependeria do utilizador.

Em contrapartida teria custos em termos de privacidade, comodidade, e do aumento da complexidade da infraestrutura de envio.  E da mesma forma que se pode dizer que é o destinatário que paga o spam (armazenamento, tráfego, sistema de filtragem, etc.) mesmo num serviço de email gratuito, também se pode dizer que será o destinatário a acabar por suportar o aumento de custos de envio de email (por exemplo, através do aumento da publicidade em newsletters que o utilizador quer ler).

9 horas atrás, redinpais disse:

Sim, vai.
Que tipo de interesse tens em entrar em detalhes? Apenas por mera curiosidade ou para um provável interesse técnico no seu desenvolvimento?

Se for meramente por curiosidade, podes consultar a minha patente em http://www.marcasepatentes.pt/files/collections/pt_PT/49/55/533/569/2015-11-20.pdf
página 98 tem lá o link para fazeres o download.

Pelo que vi da patente, colocas demasiadas dificuldades a quem quer enviar email a partir de fora, o que vai levar os utilizadores a ter que manter emails alternativos (mantendo os custos actuais) para continuarem a receber emails "automáticos", e contactar com utilizadores que não se vão dar ao trabalho de criar e gerir uma conta para poder enviar email para o vosso sistema.

Dá a ideia que o sistema teria uma gestão centralizada (caso contrário precisarias de uma conta extra para cada domínio para o qual querias enviar email?), o que leva o serviço ainda mais para o nível do hangouts, whatsapp, skype e afins, como o @Warrior referiu (onde o spam já é bem controlado).

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em 23/03/2017 às 14:29, Warrior disse:

O facto do spam existir não prova a existência de lobbying, isso é uma falácia argumentativa.

Então de que maneira se explica? Alguma coisa está a falhar...

Em 23/03/2017 às 20:50, pwseo disse:

Além do referido, saliento que hoje em dia os filtros contra spam são bastante bons, e de facto vejo cada vez mais pessoas (leigos) a queixarem-se de falsos positivos do que do inverso, no que toca a spam.

Pois... Deve ser por isto que continua a mesma cena de sempre. Ainda hoje saiu este artigo e não sou eu que o estou a inventar. https://www.futurebehind.com/relatorio-seguranca-cisco-spam/
é de referir a seguinte questão que se coloca no texto: "Se os utilizadores já estão mais consciencializados para os perigos do spam, se os filtros tecnológicos ficaram cada vez mais apurados, como se explica este regresso indesejado?"

21 horas atrás, Rui Carlos disse:

Pelo que vi da patente, colocas demasiadas dificuldades a quem quer enviar email a partir de fora, o que vai levar os utilizadores a ter que manter emails alternativos (mantendo os custos actuais) para continuarem a receber emails "automáticos", e contactar com utilizadores que não se vão dar ao trabalho de criar e gerir uma conta para poder enviar email para o vosso sistema.

Dá a ideia que o sistema teria uma gestão centralizada (caso contrário precisarias de uma conta extra para cada domínio para o qual querias enviar email?), o que leva o serviço ainda mais para o nível do hangouts, whatsapp, skype e afins, como o @Warrior referiu (onde o spam já é bem controlado).

Dos três cenários possíveis para o qual este modelo está preparado para responder, apenas o que diz respeito ao controlo de mensagens no sentido "tradicional para P2T" (serviços na cloud) é que poderá ser usada uma gestão centralizada. Compreende-se assim a necessidade de dificultar os benefícios a quem envia email de fora. De outra forma, não valeria a pena incentivá~los para serem clientes de um ISP que distribua serviços de email através de um servidor P2T.

---

Fico sensível aos vossos "avisos" relacionados com a carga e picos de esforço, mas tal como a patente é um modelo teórico, também os receios que vocês relatam só passam a fazer sentido após os testes a efetuar num modelo funcional minimo. Prefiro aguardar essa possibilidade na vez de desistir só porque se diz que sim.
O mundo está cheio de exemplos de grandes feitos que foram recusados e mal vistos.

http://image-store.slidesharecdn.com/d90faa39-371f-4110-85e2-36e936168bd8-original.jpeg

Editado por redinpais
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora