[GTER] sobre spam: bloquear reverso inconsistente funciona mesmo?

[Lend]

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