[GTER] Spam

[Danton Nunes]

On Thu, 16 Jan 2003, Joao Carlos Mendes Luis wrote:

> > finalmente, ou deveria ser primeiramente, não vi de onde tiramos a
> > informação de quem é o servidor de destino. não pode ser do pacote
> > IP porque seu campo de destino foi reescrito pelo roteador que
> > desviou o tráfego.
> 
>     Essa informacao é importante, e nao pode ser descartada, pode?  Ou
> como voce teria certeza do usuário destino do email?  A RFC obriga a
> usar nomes completos?  Se nao obrigar, temos uma falha no projeto
> aqui.

o conteúdo dos pacotes não é reescrito, mas os cabeçalhos são. os endereços de
e-mail (RCPTs) estão lá, mas o endereço IP do MTA remoto se perdeu. não sei
como fazer testes no MTA remoto original. deduzir um endereço IP para o MTA
remoto a partir do MX/A do nome de domínio do RCPT não pega abuso de relay no
pulo e os testes propostos são inúteis.

>     De qualquer forma, para solucionar suas dúvidas: O mecanimso de
> redirecionamento usado tem que ser tal que NAO mude o campo IP
> destino.  Isso pode ser feito, por exemplo, com WCCP em Cisco, ou com
> redirecionadores de camada 2. O problema de redirecionadores de camada
> 2 é que eles tem que ser configurados a CADA hop entre o ponto de
> filtragem e o servidor transparente.  Se estiver na mesma sub-rede ou
> no mesmo host não é complicado de se fazer.  Se tiver mais de um hop,
> pode ficar bem complicado.

too clumsy. é melhor não criar hipóteses na camada 2. em princípio não devemos
saber o que está acontecendo na camada 2, se não quisermos introduzir
restrições exageradas na topologia da arapuca.

danton