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

[Raphael Bittencourt S. Costa]

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