<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comentários sobre: Como funciona a parada da Gestão da Porta 25</title>
	<atom:link href="http://core.eti.br/2009/05/22/como-funciona-a-parada-da-gestao-da-porta-25/feed/" rel="self" type="application/rss+xml" />
	<link>http://core.eti.br/2009/05/22/como-funciona-a-parada-da-gestao-da-porta-25/</link>
	<description>geekness, music power and opensource</description>
	<lastBuildDate>Fri, 12 Aug 2011 21:16:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
	<item>
		<title>Por: Yves Junqueira</title>
		<link>http://core.eti.br/2009/05/22/como-funciona-a-parada-da-gestao-da-porta-25/comment-page-1/#comment-80095</link>
		<dc:creator>Yves Junqueira</dc:creator>
		<pubDate>Sat, 23 May 2009 01:17:25 +0000</pubDate>
		<guid isPermaLink="false">http://core.eti.br/?p=458#comment-80095</guid>
		<description>Não concordo.

Essa gerência da porta 25 assume um monte de coisas errada:

1) Assume que os clientes vão usar o relay do provedor apenas para mandar mensagens &quot;do bem&quot;. Errado, vão usar pra mandar SPAM também. Spammers-de-quintal vão configurar isso manualmente, e botnets/vírus vão dar seu jeito de encontrar esses relay hosts e usá-los também.
2) Assume que esses os provedores sabem cuidar dos seus servidores e configurá-los corretamente. Muito falso. Vão fazer merda, vão deixar spammer usar o servidor, não vão configurar o PTR DNS do IP, não vão fazer quase nada certo. O servidor vai virar um relay de spam, assim todos os filtros vão marcar as mensagens inocentes como spam também.

Um amigo caiu numa dessas RBLs malditas porque adicionaram toda uma sub-rede /20 da Embratel, e ele deu azar de ficar na lista negra, porque a Embratel foi/era/é(?) negligente ao lidar com spam vindo de outros clientes.

Provedores têm todas as ferramentas para combatar SPAM, mas eles são pão duros. Nem mesmo pagam gente capacitada para lidar com denúncias e evitar abusos por parte dos clientes (em outras palavras, tão se lixando para as reclamações que mandam para abuse@provedora-do-caraleo.cu).

As provedoras brasileiras conseguem ser piores do que a média quanto à lidar com abuso de clientes spammers, e pelo jeito essa história de bloquear porta 25 é pura preguiça - que não funciona de qualquer jeito.</description>
		<content:encoded><![CDATA[<p>Não concordo.</p>
<p>Essa gerência da porta 25 assume um monte de coisas errada:</p>
<p>1) Assume que os clientes vão usar o relay do provedor apenas para mandar mensagens &#8220;do bem&#8221;. Errado, vão usar pra mandar SPAM também. Spammers-de-quintal vão configurar isso manualmente, e botnets/vírus vão dar seu jeito de encontrar esses relay hosts e usá-los também.<br />
2) Assume que esses os provedores sabem cuidar dos seus servidores e configurá-los corretamente. Muito falso. Vão fazer merda, vão deixar spammer usar o servidor, não vão configurar o PTR DNS do IP, não vão fazer quase nada certo. O servidor vai virar um relay de spam, assim todos os filtros vão marcar as mensagens inocentes como spam também.</p>
<p>Um amigo caiu numa dessas RBLs malditas porque adicionaram toda uma sub-rede /20 da Embratel, e ele deu azar de ficar na lista negra, porque a Embratel foi/era/é(?) negligente ao lidar com spam vindo de outros clientes.</p>
<p>Provedores têm todas as ferramentas para combatar SPAM, mas eles são pão duros. Nem mesmo pagam gente capacitada para lidar com denúncias e evitar abusos por parte dos clientes (em outras palavras, tão se lixando para as reclamações que mandam para <a href="mailto:abuse@provedora-do-caraleo.cu">abuse@provedora-do-caraleo.cu</a>).</p>
<p>As provedoras brasileiras conseguem ser piores do que a média quanto à lidar com abuso de clientes spammers, e pelo jeito essa história de bloquear porta 25 é pura preguiça &#8211; que não funciona de qualquer jeito.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Daniel Sobral</title>
		<link>http://core.eti.br/2009/05/22/como-funciona-a-parada-da-gestao-da-porta-25/comment-page-1/#comment-80094</link>
		<dc:creator>Daniel Sobral</dc:creator>
		<pubDate>Fri, 22 May 2009 19:32:45 +0000</pubDate>
		<guid isPermaLink="false">http://core.eti.br/?p=458#comment-80094</guid>
		<description>Pois é. O problema disso é o seguinte:

Opção 1: outra porta. Quando a porta 25 não for mais útil aos spammers, eles usarão outras portas populares. No fim das contas, acaba não adiantando nada.

Opção 2: quebra a única solução de longo prazo contra spam: Sender ID. Isso porque SOMENTE o servires cadastrados de um domínio podem enviar e-mails por aquele domínio, no Sender ID. Se o MSA de sua operadora enviar o e-mail, ele (o e-mail) não terá o domínio autenticado.

A única solução para spam é autenticar o cliente no envio ao MTA, e autenticar o domínio do remetente entre MTAs. Ir para uma solução que vai afetar o curto prazo e atrapalhar o longo prazo é uma péssima idéia.</description>
		<content:encoded><![CDATA[<p>Pois é. O problema disso é o seguinte:</p>
<p>Opção 1: outra porta. Quando a porta 25 não for mais útil aos spammers, eles usarão outras portas populares. No fim das contas, acaba não adiantando nada.</p>
<p>Opção 2: quebra a única solução de longo prazo contra spam: Sender ID. Isso porque SOMENTE o servires cadastrados de um domínio podem enviar e-mails por aquele domínio, no Sender ID. Se o MSA de sua operadora enviar o e-mail, ele (o e-mail) não terá o domínio autenticado.</p>
<p>A única solução para spam é autenticar o cliente no envio ao MTA, e autenticar o domínio do remetente entre MTAs. Ir para uma solução que vai afetar o curto prazo e atrapalhar o longo prazo é uma péssima idéia.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

