[GTER] sobre spam: bloquear reverso inconsistente funciona mesmo?
Andre guimarães
andre.ramoni at gmail.com
Fri Aug 24 11:26:35 -03 2012
2012/8/23 Lend <lend.sp at gmail.com>
>
> e o pior é quando clientes ou prospects estão em RBL ou mal configurados...
> e eu tenho q abri a portera...
>
Por isso que aqui fazemos essas restricoes do postfix por dominio do
cliente... assim, abre a porteira apenas pros clientes que precisam e
aceitam o risco, sem influenciar nos outros clientes do mesmo ambiente.
>
>
>
> 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