<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
<tt>Algumas considerações adicionais:<br>
<br>
1 - o provedor pode (e deve) estabelecer um valor a ser pago para que um
usuário possa se livrar do filtro e com isso ganhar um dinheirinho extra
(sugestão: preço proporcional ao número de mensagens a serem enviadas). Será
que isso não vai abrir uma brecha para os spammers? IMHO, quando se fala
em gastar dinheiro, esses caras amarelam...<br>
<br>
2 - aliás, esse tipo de filtro (se os provedores pagos implementarem) terá
que ser implementado tb pelos provedores gratuitos senão todos os spammers
vão correr para lá, e a performance deles que já é pior que ruim, vai definitivamente
para o espaço.<br>
<br>
Alberto França</tt><br>
------------------------------------------------------------------------------------------------<br>
Danton Nunes wrote:<br>
<blockquote type="cite"
cite="midPine.LNX.4.10.10301101036540.26738-100000@quantum.inexo.com.br">
<pre wrap="">On Fri, 10 Jan 2003, [windows-1252] Alberto França wrote:</pre>
<blockquote type="cite">
<pre wrap="">Seria possível os provedores implementarem um filtro (ou procedimento) de tal modo que o delivery time das mensagens crescesse exponencialmente dependendo do número de mensagens enviadas durante o mês anterior? Ou seja, se o usuário enviou x mensagens no mês anterior, as proximas serão enviadas num tempo segundo uma formula onde o X é o expoente? Por exemplo, se ele enviou 100 mensagens no mês anterior, as proximas serão enviadas asap, enquanto que se ele enviou 100.000 no mês anterior, as
proximas poderão levar vários anos ou mais. Quando o spammer ligar
irritado querendo explicações do porque as mensagens não foram enviadas, a resposta será "sim senhor, estamos examinando o problema". Após o milésimo telefonema do spammer a resposta será sempre a mesma. Como ele vai ficar muito irritado (essa é a parte boa) ele deverá procurar outro provedor que se adotar a politica acima, também ficará livre do chato.
</pre>
</blockquote>
<pre wrap=""><!---->
hummm, mas que idéia mais diabólica! nem precisa esperar um mês, vai
modulando o delay dele em função do número de mensagens transmitidas nos últimos xxx minutos. mas ela só funciona se voce obrigar a usar um relay controlado, o que o spammer não fará por vontade própria.
semana que vem vamos testar em São José dos Campos um esquema de policy routing para forçar o tráfego tcp/25 para um relay controlado, mais ou menos à maneira que se costuma fazer com o squid. o que obtivermos vamos postar nesta lista e, quiçá, apresentar na reunião do GTER.
Danton.
--
GTER list <a class="moz-txt-link-freetext" href="http://eng.registro.br/mailman/listinfo/gter">http://eng.registro.br/mailman/listinfo/gter</a>
</pre>
</blockquote>
</body>
</html>