[GTER] RBL

[Marcio Gomes]

Pessoal,

Uma ideia adicional que venho utilizando em testes e'  a seguinte :


MX   0  server1.xxx.com.br
MX 10  server2.xxx.com.br
MX 15  server3.xxx.com.br


server1.xxx.com.br tem todo pacote inbound tcp/syn com destino a port 25 
do mesmo com uma regra "REJECT" ,
aqui poderia-se criar um DSN de erro transitorio,  ainda nao verifiquei 
ser totalmente de acordo com as rfcs' e
se neste caso,  de erro transitorio ( acredito que existam alguns erros 
transitorios que obriguem isso ),   o sender
seria  obrigado a tentar outros MX.

MX 10 e MX 15 aceitam pacotes externos e utilizam-se das rotinas 
spam-block e dnsbl de sua escolha..

MX 10 e MX 15 tem trafego garaantido p/ MX 0.

C om essa medida normalmente toda primeira tentativa de envio ganha um 
REJECT e normalmente
os SPAM Senders nao fazem muitas verificacoes, ou seja utilizam-se do se 
passou passou.. E"  mais
ou menos uma ideia que vimos aqui a algum tempo atras que a 1a tentativa 
de1 mta desconhecido se
conectar ganhava um disponivel temporariamente, e depois era aceito se 
dentro de X tempo voltasse
a se conectar.

De acordo om a rfc 2821,  o sender deve verificar pelo menos 2 MX 
adicionais ( ou seja um total de 3 MX's  ),
ou seja ele sempre ao menos deve tentar o 10 e o 15. Nem sempre esta 
situacao e'  eficiente ( principalmente quando
nao se tem como garantir que MX 10 e 15 vao estar sempre up ), depende 
do volume de emails e forma de
implementacao que e'  uma particularidade de cada rede, valendo aqui a 
ideia de dar um reject na 1a tentativa.

5. Address Resolution and Mail Handling

   Once an SMTP client lexically identifies a domain to which mail will
   be delivered for processing (as described in sections 3.6 and 3.7), a
   DNS lookup MUST be performed to resolve the domain name [22].  The
   names are expected to be fully-qualified domain names (FQDNs):
   mechanisms for inferring FQDNs from partial names or local aliases
   are outside of this specification and, due to a history of problems,
   are generally discouraged.  The lookup first attempts to locate an MX
   record associated with the name.  If a CNAME record is found instead,
   the resulting name is processed as if it were the initial name.  If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" rule
   above applies only if there are no MX records present.  If MX records
   are present, but none of them are usable, this situation MUST be
   reported as an error.

   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds.  However, there MAY also be a configurable
   limit on the number of alternate addresses that can be tried.  In any
   case, the SMTP client SHOULD try at least two addresses.




[s] 




Antonio Carlos Pina wrote:

>Caros,
>
>Recomendo enfaticamente o SPAMCOP. Vejo que essa questão que eles colocam de
>"Não usá-los" é muito mais uma defesa contra possíveis processos ("Ei! Eu
>disse para não usar!") do que alguma falha deles (que em anos de operação só
>vi acontecer 1 vez).
>
>A única coisa que precisamos fazer foi criar um arquivo de exceções para não
>barrar no SPAMCOP servidores de correio conhecidos (ex: AOL, UOL, iG, etc) e
>deixo para o SPAMCOP o trabalho de barrar os servidores de correio de
>empresas pequenas (principalmente as que não têm contatos abuse at xxxx),
>provedores e indivíduos.
>
>Já fomos bloqueados no SPAMCOP e posso dizer que não há nada melhor para
>você se mexer.
>
>Essas são as listas que usamos:
>
>  reject_rbl_client relays.ordb.org,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client opm.blitzed.org,
>   reject_rbl_client dun.dnsrbl.net,
>   reject_rbl_client spam.dnsrbl.net,
>   reject_rbl_client list.dsbl.org,
>
>Cordialmente,
>Antonio Carlos Pina
>INFOLINK Internet
>http://www.infolink.com.br
>----- Original Message ----- 
>From: "Alex Vitola" <listas at vitola.com.br>
>To: "Grupo de Trabalho de Engenharia e Operacao de Redes"
><gter at eng.registro.br>
>Sent: Monday, September 13, 2004 7:35 AM
>Subject: Re[2]: [GTER] RBL
>
>
>
>Não recomendo a spamcop, por melhor que seja o serviço que eles fazem, até
>pq a sua finalidade não é essa, como eles mesmo informam.
>
>
>  
>