[GTER] sobre spam: bloquear reverso inconsistente funciona mesmo?
Silmar A. Marca
smarca at gmail.com
Fri Aug 24 11:35:33 -03 2012
Concordo com Lend.
Acho inclusive que bloquear reversos não adianta muita coisa, pode
inclusive bloquear emails válidos de clientes. Aqui, uso o Exim. Não tenho
grande volume de spam, nem virus,mas tive de implementar muitas linas de
código.
O site http://www.antispam.br/admin/ fala das técnicas superficialmente.
Talvez seja interessante dar uma olhada.
Além de SPF, DKIM, Graylist, RBL (não tem funcionado muito ultimamente) é
necessário filtrar mais. Caso não tenha SPF ou DKIM e não seja enviado pelo
MX é importante verificar o CallOut.
Importante também filtrar por exemplo as imagens com query CGI (que validam
seu email para o spammer), usar na saida do email a técnica de assinatura
BATV e assim nunca aceitar retornos bounce email de <>, usar em
redirecionamentos externos a assinatura SRS, colocar SPF em seu dominio e
verificar o dos outros, assinar por DKIM suas mensagens e verificar a
mensagens dos outros, verificar dentro de arquivos zipados/rar/gz/tar etc,
além de verificar CallOut também possibilitar que outros provedores o facam
no seu domínio de maneira segura, exigir headers excenciais como Date,
From, Message-ID, Filtrar Message-ID duplicados de senders diferentes,
dificultar os spammers colocando delays em bloqueios de mensagens, validar
mensagens falsas olhando os dominios de todos os Headers, ajudar os outros
colocando reverso em seu IP (mesmo sendo uma ADSL com ip fixo por
exemplo)....
Há muita coisa que pode ser feita.
Mas que dá pra filtrar spam dá...
Att, Silmar A. Marca
Em 23 de agosto de 2012 21:39, Lend <lend.sp at gmail.com> escreveu:
> A coisa piora a cada dia !!!
>
> Tem empresa de e-mkt que lança mais de 30.000 conexoes aqui por hora.
> parece que o registro.br não se importa com o volume de spam...
>
> SPF, reverso, DKIM, graylist, rbl, blacklist, filtro de conteudo, controle
> total da 25 FAÇO TUDO !
>
> O pior é que os spammers (empresas de e-mkt) tambem configuram tudo
> direitinho ... registram o dominios não pagam os tickets só pra fazer as
> sacanagens. tendo sempre dominios e IPs limpos e bem configurados
>
> e o pior é quando clientes ou prospects estão em RBL ou mal configurados...
> e eu tenho q abri a portera...
>
>
>
> 2012/8/23 Andre guimarães <andre.ramoni at gmail.com>
>
> > Sobre estas restrições, na minha opiniao, eu habilitaria todas elas.
> > Porem, em um ambiente onde hospedamos varios dominios de clientes
> > diferentes o que fazemos é dar a opçao ao cliente caso ele queira mesmo
> > desabilitar algumas dessas checagens.
> >
> > Hoje oferecemos, POR DOMINIO as seguintes checagens e modos:
> > - Ip reverso: pode ser ip->nome->ip, somente ip-> nome ou desabilitada
> > - Ehlo hostname: nome->ip, nome valido ou desabilitada
> > - Checagens de DNSBL: oferecemos spamhaus, sorbs, spamcop e barracuda,
> cada
> > uma delas pode ser desabilitada caso precise. Claro que se o problema for
> > pequeno aconselhamos utilizar whitelists, porem se a coisa foge ao
> controle
> > causando muito impacto no cliente podemos desabilitar cada uma das
> > checagens do postfix apenas para tal dominio, nao afetando outros
> clientes.
> >
> >
> > Em fim, essas foram somente as restricoes client_restrictions, mas
> podemos
> > habilitar/desabilitar cada restrição para cada dominio conforme a demanda
> > do cliente.
> >
> > E antes que pensem: NAO, isso nao é feito com mapas no postfix... essas
> > configurações estão em banco mysql, entao não há complexidade alguma na
> > configuração do postfix.
> >
> >
> >
> > On Wed, Aug 22, 2012 at 10:43 PM, Raphael Bittencourt S. Costa <
> > raphaelbscosta at gmail.com> wrote:
> >
> > > Henrique,
> > >
> > > Excelente explicação, mas na prática, nunca tive problemas com isso
> não.
> > >
> > > Bom... Eu trabalhava com e-mail há 3-4 anos atrás... Pode ser por isso.
> > :-)
> > >
> > > []s,
> > >
> > > Raphael Costa
> > >
> > > -----Original Message-----
> > > From: gter [mailto:gter-bounces at eng.registro.br] On Behalf Of Henrique
> > de
> > > Moraes Holschuh
> > > Sent: quarta-feira, 22 de agosto de 2012 15:48
> > > To: gter at eng.registro.br
> > > Subject: Re: [GTER] sobre spam: bloquear reverso inconsistente funciona
> > > mesmo?
> > >
> > > On 22-08-2012 14:07, Raphael Bittencourt S. Costa wrote:
> > > > 5.2.5 HELO Command: RFC-821 Section 3.5
> > >
> > > Olhe no RFC 5321 (que atualiza o 1123, e obsoletou o 2821 e 821):
> > >
> > > 2.3.5 Domain Names
> > > ...
> > > o The domain name given in the EHLO command MUST be either a
> primary
> > > host name (a domain name that resolves to an address RR) or, if
> > > the host has no name, an address literal, as described in
> > > Section 4.1.3 and discussed further in the EHLO discussion of
> > > Section 4.1.4.
> > >
> > > 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
> > >
> > > These commands are used to identify the SMTP client to the SMTP
> > > server. The argument clause contains the fully-qualified domain
> name
> > > of the SMTP client, if one is available. In situations in which
> the
> > > SMTP client system does not have a meaningful domain name (e.g.,
> when
> > > its address is dynamically allocated and no reverse mapping record
> is
> > > available), the client SHOULD send an address literal (see
> > > Section 4.1.3).
> > >
> > > RFC 2821, and some earlier informal practices, encouraged following
> > > the literal by information that would help to identify the client
> > > system. That convention was not widely supported, and many SMTP
> > > servers considered it an error. In the interest of
> interoperability,
> > > it is probably wise for servers to be prepared for this string to
> > > occur, but SMTP clients SHOULD NOT send it.
> > >
> > > 4.1.4.
> > > ...
> > > The SMTP client MUST, if possible, ensure that the domain parameter
> > > to the EHLO command is a primary host name as specified for this
> > > command in Section 2.3.5. If this is not possible (e.g., when the
> > > client's address is dynamically assigned and the client does not
> have
> > > an obvious name), an address literal SHOULD be substituted for the
> > > domain name.
> > >
> > > An SMTP server MAY verify that the domain name argument in the EHLO
> > > command actually corresponds to the IP address of the client.
> > > However, if the verification fails, the server MUST NOT refuse to
> > > accept a message on that basis. Information captured in the
> > > verification attempt is for logging and tracing purposes. Note
> that
> > > this prohibition applies to the matching of the parameter to its IP
> > > address only; see Section 7.9 for a more extensive discussion of
> > > rejecting incoming connections or mail messages.
> > >
> > >
> > > A verificação do EHLO é MAY, o bloqueio se a resolução do EHLO não
> bater
> > > com
> > > o IP do cliente é MUST NOT, e o reverso explicitamente pode não
> existir.
> > >
> > > Na prática, pegar pesado com o EHLO dá problema e você vai rejeitar
> MUITA
> > > email válida. Falo por experiência própria (se bem que não chegamos a
> > > rejeitar, o postfix tem uma diretiva "warn_if_reject" que é excelente).
> > >
> > > --
> > > Henrique de Moraes Holschuh <hmh at ima.sp.gov.br> IM@ - Informática de
> > > Municípios Associados Engenharia de Telecomunicações TEL
> > > +55-19-3755-6555/CEL +55-19-9293-9464
> > >
> > > Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente e
> do
> > > custo que você pode evitar.
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > >
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
>
>
>
>
> Leandro Souza
> (11)6716-2967 - OI
> (11)7188-1172 - VIVO
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list