Re: [OT] CNAMEs en MX [ era Servidor de correo de backup ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola :)))
On Wednesday 09 April 2003 23:09, Manuel Samper wrote:
> Victor Calzado Mayo, a las 10:20 del martes 8 abr 2003, comentó:
> > Hola
> >
> > On Tuesday 08 April 2003 09:02, Angel Luis Mateo Martínez wrote:
> > > El lun, 07 de 04 de 2003 a las 23:49, Manuel Samper escribió:
> > > > Aaggh! que patinazo. Borra eso de la IP; un registro MX siempre debe
> > > > contener un "hostname" (que debe poder resolver a una IP con un
> > > > registro A, por supuesto).
> > >
> > > Esta es una pregunta que siempre me he hecho... ¿por qué el MX debe
> > > apuntar a un registro A? ¿Por qué no debe apuntar a un CNAME?
> >
> > 2.3.5 Domain
> >
> > A domain (or domain name) consists of one or more dot-separated
> > components. These components ("labels" in DNS terminology [22]) are
> > restricted for SMTP purposes to consist of a sequence of letters,
> > digits, and hyphens drawn from the ASCII character set [1]. Domain
> > names are used as names of hosts and of other entities in the domain
> > name hierarchy. For example, a domain may refer to an alias (label
> > of a CNAME RR) or the label of Mail eXchanger records to be used to
> > deliver mail instead of representing a host name. See [22] and
> > section 5 of this specification.
>
> RFC2821:
> 3.6 Domains
>
> Only resolvable, fully-qualified, domain names (FQDNs) are permitted
> when domain names are used in SMTP. In other words, names that can
> be resolved to MX RRs or A RRs (as discussed in section 5) are
> permitted, as are CNAME RRs whose targets can be resolved, in turn,
> to MX or A RRs. Local nicknames or unqualified names MUST NOT be
> used. There are two exceptions to the rule requiring FQDNs:
En el fondo seguimos en lo mismo, todo lo que sea un FQDN puede usarse, pero
aquí si se nota alguna reticencia contra los CNAMES... [ ...as are CNAME RRs
whose targets can be resolved... ]
>
> - The domain name given in the EHLO command MUST BE either a primary
> host name (a domain name that resolves to an A RR) or, if the host
> has no name, an address literal as described in section 4.1.1.1.
Por desgracia tanto esto como lo siguiente ha caido pisoteado por todo el
software de correo que existe en la actualidad o ha perdido vigencia...
>
> [...]
>
Esta parte a mi me entristece bastante....
> 4.1.4 Order of Commands
> [...]
> The SMTP client MUST, if possible, ensure that the domain parameter
> to the EHLO command is a valid principal host name (not a CNAME or MX
> name) for its host.
Herencia clara del pasado...
> 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 and supplemental information provided that will assist in
> identifying the client.
Intento de adaptarse a los tiempos modernos...
>
> An SMTP server MAY verify that the domain name parameter in the EHLO
> command actually corresponds to the IP address of the client.
> However, the server MUST NOT refuse to accept a message for this
> reason if the verification fails: the information about verification
> failure is for logging and tracing only.
Rendición ante la triste realidad, nos tragamos lo que nos manden y que dios
nos perdone, ya encontraremos el postmaster y las direcciones administrativas
tirando de la dirección de correo del remitente..... ( había nacido el SPAM
inatacable e imparable.... )
>
>
> Parece ser que el "must" a propósito del EHLO es el origen de toda la
> cuestión... y si aplicamos la recomendación de "ser liberal en lo que se
> acepta y estricto en lo que se envía", pues lo estricto aquí es atenerse
> al "must" sobre el hostname en el EHLO. En cualquier caso, los
> rfc 821/2821 son lo suficientemente extensos como para que surjan
> contradicciones según el punto de vista del que los lee.
Bueno, pero nadie dice que un CNAME no sea un FQDN, con lo que estamos de
nuevo en los problemas de resolución de CNAMEs cacheos, descuidos..... y
empezaríamos a bucear en los rfc de DNS que por cierto no son de lo mejor que
se ha escrito....
>
> Que conste que no estoy defendiendo nada, únicamente indico que para
> andar "sobre seguro", es lógico encontrarse con afirmaciones categóricas
> acerca de no apuntar MX a CNAMES.
Que conste que yo prefiero tener una entrada A por cada entrada MX ( aunque
tenga múltiples entradas A contra la misma IP ) y por limpieza no crear
bonitas entradas para dns ni para smtp en las entradas de los dominios
virtuales, sino utilizar las entradas NS y MX del dominio padre ( sólo los
fallos en una zona son críticos.. )
>
> Saludos
>
> Manuel Samper
>
> PD: Perdón por mandar a la lista textos en inglés. Pero para el que no
> lo entienda, le aseguro que no se pierde nada interesante.
Pero como parece que nos queda claro a los dos son opiniones todo, pero me
alegro de coincidir contigo :)
Un saludo
Victor
- --
Abril
Uno de los peores meses para andar metiendo al mundo en guerras absurdas
El resto de meses del mismo tipo son: Enero, Febrero, Marzo, Mayo, Junio,
Julio, Agosto, Septiembre, Octubre, Noviembre y Diciembre.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+lSiIEzqHF8R72ekRArHMAJ0cmRuVg/0bgb45tNp1VXLpKKfNvACcCTkR
OtmzHcg1uKaY2WOBVucm5I4=
=Z45l
-----END PGP SIGNATURE-----
Reply to: