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

[Andre guimarães]

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
>