[GTER] Emails p/ o IG

[Jorge Godoy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 16 January 2004 10:57, Danton Nunes (Danton Nunes 
<danton at inexo.com.br>) wrote:

> chiii, os gerenciadores de lista tipo ezmlm vão ter xiliques.

Na verdade não. Eles já mandam uma mensagem para cada assinante para 
poder rastrear os erros de entrega e realizar os descadastramentos... 
Claro, há maneiras de se evitar isso, mas geralmente não é feito para 
beneficiarmo-nos desta facilidade e reduzirmos a carga no servidor e 
no link com endereços que nunca receberão nada. 

O problema é que os MTAs têm que abrir mais de uma conexão para 
realizar as entregas e isso consome bastante tempo.

> isto está parecendo uma medida desesperada (e absurda) contra SPAM,
> especialmente contra o spam de dicionário, em que o spammer tenta o
> dicionário do aurélio e mais alguma coisa @ig.com.br. Alguns MTAs,
> notadamente o qmail, não testam a validade de um destinatário local
> durante o diálogo do SMTP, dando OK para todos e só depois, se o
> mané não existir, devolve uma mensagem de bounce. Não duvido que o
> iG esteja atolado em mensagens de bounce que vão para lugar nenhum,
> ou alguém acredita em 'errors-to:' de spam?

Essa é uma falha de implementação no qmail... Deve haver algum patch 
por aí para que ele faça a checagem antes, não?


Outro problema do iG era com relação ao servidor LDAP ou o que quer 
que seja que eles usem por lá. Muitos usuários existentes estavam 
desativados há uns tempos atrás. Não sei se todos já estão 
normalizados... Em uma das listas que administrei na época mais de 
1000 usuários foram descadastrados devido a esses erros. 

> há quem argumente que o comportamento do qmail é correto, por não
> confirmar para os spammers se fulano é um usuário real ou não. só
> que provoca essa enxorrada de bounces quando vem spam de
> dicionário.  pessoalmente acho que um erro tipo '550 User unknown
> (#5.1.1)' logo no envelope é a coisa mais razoável a fazer, se não
> quiser lidar com zilhões de bounces para endereços falsos depois.

Acho que o correto é adotar a política de poisoning: o primeiro erro 
vem rápido, o segundo demora mais, o terceiro mais ainda e assim vai, 
com um atraso exponencial. Desta maneira o spammer fica preso e você 
perde apenas uma conexão ao invés de diversas conexões para dar os 
erros. 

> no caso de não se querer receber mensagens com mais de um rcpt (uma
> bobagem, pois quebra o comportamento de servidores de listas
> válidas, mas se quiser insistir na bobagem...) o MTA do iG deveria
> retornar um erro 5xx após o segundo rcpt e não cortar a conexão
> assim de sopetão, porque assim o MTA remetente pensa que o erro é
> transitório e vai tentar enviar depois, dando novamente com os
> burros n'água.

Exatamente. E poderiam colocar uma mensagem mais clara também. O BOL, 
IIRC, tem o mesmo comportamento só que mostra a mensagem de erro, o 
que facilita muito para o administrador do servidor "remetente".

- -- 
Godoy.      <godoy at g2ctech.com>

Consultoria e serviços em redes Linux, FreeBSD e Windows.
Desenvolvimento de software e projetos. Treinamentos.
Telefones: +55 (41) 9114-5901     /    +55 (41) 362-7020
Curitiba, Paraná - Brasil         http://www.g2ctech.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAB+VoEzC+baSjBiURAt+GAKChFHwp7X3C/EG0JGu54s4SQIJM0gCfa8U8
040EFvPp74suueUBrMcmqEs=
=vt1S
-----END PGP SIGNATURE-----