Bsicos: Cosas que siempre quisiste saber sobre el

correo electrnico y nunca te atreviste a preguntar

(Parte 1).
La serie Bsicos.
Esta serie de artculos nace de la necesidad de tener una
referencia que poder usar para dar una respuesta sencilla a las
preguntas bsicas que frecuentemente aparecen en los foros.

Introduccin
Desgraciadamente con frecuencia, las pequeas y medianas
empresas se enfrentan al reto de querer disponer de su propia
infraestructura de correo sin tener los conocimientos adecuados,
cuando finalmente han conseguido desplegar este servicio, se
encuentran con los problemas relativos al relay, el spam y los virus.
Por ultimo las pequeas operaciones del da a da, tambin
suponen un problema si no se cuenta con la formacin adecuada.
En este artculo espero que puedas encontrar las respuestas a
algunas de tus preguntas, para las dems, yo y otros MVP y
colaboradores de la comunidad te esperamos en los foros de la
technet.

El funcionamiento del correo a alto nivel.

Para poder entender como logran los servidores de correo de
otros dominios dar con los nuestros es necesario que entandis el
concepto de los registros MX (Mail Exchangers o intercambiadores de
correo)
Para qu sirven los MX?
Los registros MX son un tipo especial de registro en la zona DNS
de un dominio, estos registros identifican que servidores se encargan
del correo de ese dominio.
Los registros MX no especifican una IP, si no que en realidad
hacen referencia a otro registro, ser ese registro el que este
asociado a una IP publica en internet, esta IP ser la del servidor de
correo o router/firewall que lo publique en Internet.
Dado que el registro en la zona DNS apuntara a una IP, es
imprescindible que este IP sea fija.
El correo de entrada desde otros dominios nos llega por el
puerto 25 que es el del protocolo SMTP (Simple Mail Transfer

Protocol o Protocolo Simple de Transferencia de Correo), por lo

tanto necesitareis publicar o redirigir este puerto en vuestros
firewalls o routers hacia el servidor que desempee esa funcin
dentro de vuestra red.
Cuando un servidor de un dominio cualquiera quiere enviar
correo a un usuario de nuestro dominio, lo primero que tratara
de hacer es averiguar la IP de un servidor de correo de ese
dominio, para eso se conectara al DNS y le solicitara los
registros MX del dominio en cuestin.
El registro MX solo es vlido para el dominio que lo contiene,
esto significa que si tienes varios dominios, cada uno tendr
que tener su propio MX.
Un solo servidor con una sola IP puede ser el MX de tantos
dominios como quieras, pero tendrs que configurar en tu
servidor de correo que acepte los correos que entren de esos
dominios.
Un dominio puede tener ms de un MX, a cada MX se le asocia
un peso o prioridad que es simplemente un numero, los
servidores de correo siempre trataran de conectarse a los MX
con menor peso, si no lo logran se conectaran al siguiente.
En empresas grandes es habitual que se coloquen varios MX y
que los servidores que respondan a esas IPS se encuentren en
diferentes puntos geogrficos y con lneas de diferentes
proveedores de comunicaciones, de esta forma las empresas se
garantizan que en caso de que un servidor tuviera problemas de
cualquier tipo, otro servidor recibira el correo.
Muchos proveedores de correo, ofrecen como servicio poner sus
servidores de correo como MX secundarios de forma que si tu
servidor tiene problemas ellos recibirn el correo por ti, cuando
tu servidor se recupere ellos te reenviaran todo el correo que
hayan almacenado.
En el siguiente diagrama vemos grficamente el funcionamiento
de lo explicado hasta ahora.

Cuando el servidor de correo de la empresa A quiere mandar un

correo a la empresa B sucede lo siguiente:
1) El servidor de correo trata de conectarse con el servidor
DNS que tenga configurado en la tarjeta de red del servidor
de correo o en la configuracin de Exchange, para esto
necesitara que el firewall o router le dejen salir por el puerto
53 de TCP y UDP, una vez que se ha conectado pregunta al
servidor DNS por los MX de la zona de la empresa B.
2) El servidor DNS responde con los datos de los MX
3) El servidor de correo de la empresa A trata de conectarse a
la IP del MX por el puerto 25 TCP, el firewall de la empresa A
tiene que dejar salir ese trfico y el de la empresa B tiene
que estar publicando el puerto 25 del servidor de correo en
la IP publica a la que se haga referencia en el DNS.

Cmo crear un MX si no lo tengo y que necesito para

poder crearlo?
Una vez que ya has registrado un domino, el siguiente paso es crear
los registros MX.
Cuando registras un dominio suele haber dos opciones.
Opcin 1) Dejar que la empresa que te vende el
dominio se encargue de los DNS; en esta modalidad
no tienes que montar un DNS, la empresa en la que has
registrado el dominio se encarga de proporcionarte uno,
normalmente tendrn una pgina web en la que podrs
gestionar los registros en la zona del dominio que has
registrado, as que este caso solo tendrs que entrar en
esa pgina con el usuario y contrasea que te han dado e
introducir un nuevo registro MX con la IP que tengas.
Imagen 1, ejemplo de pagina web de administracin de
los MX de una zona.

Opcin 2) Tener tus propios DNS; una vez que has registrado un
dominio, es posible indicarle que quieres que los servidores DNS
encargados de ese dominio sean los tuyos, usualmente no recomiendo
que se haga esto, ya que aunque aporta ms flexibilidad es una gran

responsabilidad, si los servidores DNS fallan, nadie podr acceder a

ningn servicio prestado en el mismo.
Dentro de las zonas DNS es posible tener un servidor primario y varios
servidores secundarios, los secundarios replican la informacin del
primario por si este dejara de funcionar, es posible tener el primario a
nuestro cargo en nuestros servidores y que el secundario lo tenga el
proveedor o que este en otros servidores nuestros.
Los servidores DNS de una zona se especifican con registros de tipo NS.
Si nosotros tenemos el DNS es importante que nunca lo pongamos en un
servidor unido al dominio de Windows, especialmente si es un DC, los
DC contienen informacin muy valiosa en trminos de seguridad, dado
que los servidores DNS han de exponer su puerto 53 (TCP y UDP) en
internet son siempre un punto inicial para un ataque, por esta razn es
recomendable que los DNS que tengamos en Internet estn
completamente aislados de la red interna.
Veamos ahora como configuraramos el registro MX en un servidor DNS
de Windows 2003 Server en caso de tener en un servidor nuestro la zona
del DNS.
Imagen 2, creacin del registro A que representa al servidor de correo.

Imagen 3, Creacin del registro A y asociacin a la IP publica en Internet.

Imagen 4, Creacin del registro MX.

Imagen 5, Creacin del registro MX asocindolo al registro de tipo A

creado anteriormente.

Cmo saber cul es mi MX o mis servidores DNS?

Hay dos formas de realizar estas averiguaciones.
Opcin 1) La forma fcil; podemos usar alguna pagina como
http://www.dnsstuff.com desde la cual podemos sacar un informe de nuestra zona DNS
Imagen 6, Pidiendo a dnsstuff.com un informe sobre la zona DNS de
Microsoft.com

7, Servidores NS (servidores DNS) mostrados en el informe de dnsstuff.com.

Imagen 8, Servidores MX mostrados en el informe de dnsstuff.com

Opcin 2) La difcil; Yo prefiero esta opcin la razn es que la puedo ejecutar

desde mi propio servidor de correo y esto me ayuda cuando tengo problemas al
enviar correo a otros dominios, ejecutando este proceso desde un servidor de
correo, podris averiguar si es capaz de encontrar los MX de otros dominios.
Usaremos el comando nslookup para conectarnos al DNS, el servidor DNS
usado por un servidor de tipo Exchange tiene que poder ser capaz de responder a
preguntas sobre zonas en internet, pero tambin tiene que ser capaz de permitirle
ser miembro del directorio activo, una de las posibles soluciones a este problema

la podis encontrar en este otro artculo:

http://geeks.ms/blogs/dmatey/archive/2007/01/16/basicos-configuraci-n-dedns.aspx
Imagen 9, entrando en nslookup y preguntando por los registros NS de
Microsoft.com

Imagen 10, preguntando por los servidores MX de Microsoft.com

Como veis la informacin obtenida es la misma, pero nos garantizamos que es

exactamente como nuestro servidor la ve.
Es posible conectarnos a servidores DNS especficos usando el comando server
IP desde el comando nslookup y cambiando IP por la IP del servidor dns al que nos
queramos conectar.

Cmo probar el servidor de correo que escucha en un MX?

Una vez que sabemos cul es el registro MX de una zona, podemos probarlo
simplemente haciendo telnet al puerto 25 de ese servidor concreto, si no
obtenemos respuesta de ninguno de los MX del dominio significara que no
podremos enviar correo a ese dominio, si lo intentamos hacer contra un servidor
nuestro, es importante no hacerlo desde el mismo servidor.
De esta forma podemos saber si otros servidores se pueden conectar contra el
nuestro.
Para probarlo contra un servidor de Microsoft ejecutaremos el siguiente
comando.
Imagen 11, conectando a un servidor MX de Microsoft.com

Imagen 12, Recibimiento del MX de Microsoft.com.

Si os fijis veris que aunque hemos hecho un telnet a maila.microsoft.com nos

ha recibido un servidor llamado mail04, esto se debe a que en las empresas
grandes es comn que se usen balanceos de carga de varios servidores para
responder a cada MX, especialmente al de mas bajo peso que ser el que ms
correo reciba.

Precauciones antes de poner un servidor

en internet.
Como habis visto una vez que publiquemos nuestro correo en internet,
cualquiera podr conectarse al puerto 25 de nuestro servidor, en este puerto
escuchara nuestro sistema de correo, por ejemplo Exchange, si Exchange tuviera
algn fallo de seguridad un atacante con los conocimientos adecuados podra
intentar hacerse con el control del servidor.
Este problema es comn a todos los servidores de correo ya sean Linux,
Windows, Solaris, etc.
Por esta razn es siempre muy importante mantener actualizado nuestro servidor
y tratar de exponer lo menos posible el servidor al exterior, si montamos y
publicamos mas servicios en el mismo servidor estaremos multiplicando
exponencialmente el riesgo.
A la hora de defender nuestra red, es clave pensar detenidamente donde
pondremos nuestro servidor o servidores SMTP.
En medianas y grandes empresas es usual que si se usa Exchange 2003, se
disponga de servidores denominados Front-End, dichos servidores se encargan
del acceso de los usuarios a su correo por Web, POP3, Imap y tambin prestan
los servicios de SMTP.
Mucha gente sostiene que estos servidores Front-End al estar expuestos a
Internet se tienen que situar en la DMZ o zona desmilitarizada.
La DMZ es una red que se suele configurar entre Internet y la red local.
Podemos encontrar infinitos modelos de DMZ, los ms comunes serian.
Imagen 13, Diferentes configuraciones de DMZ.

En el caso de las empresas ms pequeas, nos podemos encontrar que no hay

firewall, en ese caso simplemente contaremos con el router para poder filtrar los
puertos abiertos, algunos routers cuentan con bocas especiales para crear una
DMZ.
Yo sostengo que no se deben poner los servidores de Front-End de Exchange en
la DMZ, mis argumentos se basan en que Exchange requiere ser miembro del
dominio y trabajar estrechamente con los controladores de dominio, por esta
razn es necesario abrir demasiados puertos en los firewalls perimetrales,
adems parte de este trfico a permitir es de tipo RPC, los protocolos de tipo
RPC requieren de un rango dinmico de puertos para funcionar, es cierto que es
posible cambiar este comportamiento reduciendo el rango de puertos dinmicos,
aun as, creo que si alguien lograra conquistar un Front-End en la DMZ podra
usar estos puertos abiertos y el hecho de que el servidor sea miembro del
dominio, para lograr penetrar en la red interna.
Bajo mi forma de ver este problema creo que hay dos posibles variantes de
diseos, los expresare bajo el modelo de back to back simple aunque obviamente
se puede extrapolar a cualquier configuracin de firewalls que cuente con una
DMZ.
Variante 1.
Imagen 14, variante 1 del emplazamiento del SMTP dentro de una arquitectura
de correo.

En esta variante, confiamos en el filtro de aplicacin SMTP de los firewalls y

usamos IPSEC para garantizar que si alguien consiguiera el control del FrontEnd no lograra salir de ese grupo y reglas, a esta configuracin se la
llama server isolation.
Variante 2
Imagen 15, variante 2 del emplazamiento del SMTP dentro de una arquitectura
de correo.

En esta variante colocamos en la DMZ un servidor SMTP con el antivirus y el

Antispam, este servidor no forma parte del dominio y simplemente filtra todo el
correo entrante y lo reenva hacia el Front-End, este ser el servidor del que
publicaremos su puerto 25 en internet, aun asi usaremos IPSEC, dado que
tambin ser necesario publicar en internet los puertos del correo por web
(OWA) y siempre existe el riesgo de un ataque.
Este servidor no tiene por qu tener Exchange, se puede usar el servidor SMTP
de Windows 2003.
En Exchange 2007 existe un tipo especial de rol de servidor de Exchange
denominado Edge Services, estos servidores estn pensados para hacer lo mismo
que expreso en esta variante de diseo, podis leer mas sobre este rol en mi
artculo sobre el diseo de arquitecturas con Exchange 2007 en:

http://geeks.ms/blogs/dmatey/archive/2007/01/16/ejemplo-de-dise-o-dearquitectura-de-mensajeria-con-exchange-2007.aspx
Insisto en la importancia de mantener actualizados todos los servidores de la
solucin, para ello lo mejor es contar con servidores de actualizacin del tipo de
WSUS, tambin recomiendo usar MBSA
(http://www.microsoft.com/technet/security/tools/mbsahome.mspx)y Exchange
Best Practice Analyzer
(http://www.microsoft.com/exchange/downloads/2003/exbpa/default.asp)
Exchange cuenta con un producto gratuito denominado IMF que esta incluido
dentro de Exchange y que nos ayudara a reducir el Spam.
Como sistema de Antivirus recomiendo usar ForeFront de Microsoft que es uno
de los pocos antivirus de correo que permite usar varios motores de deteccin
simultneos garantizndonos as que tendremos la mxima proteccin.

El problema del Relay.

Qu es el relay?
El relay consiste en reenviar correo de un servidor a otro, de por si no es malo,
pero sin embargo si lo es y mucho cuando ni el dominio origen ni el destino es nuestro.
Todos somos vctimas del SPAM o correo no deseado, hemos visto que podemos
utilizar herramientas como IMF para evitar que nos entre SPAM, pero
desgraciadamente el problema va mas all, las personas que se dedican a hacer
SPAM suelen usar servidores vulnerables al Relay para enviar estos miles de
correos, estos servidores se ven atacados por miles de correos que consumen sus
recursos y ancho de banda.
El problema puede ser aun peor, ya que para evitar el SPAM muchas
organizaciones indican a sus servidores de correo que validen en unas listas
conocidas como listas negras si los servidores que les intentan mandar correo
estn en dichas listas o no.
De tal forma que si por alguna razn nuestro servidor ha hecho relay y alguna
lista negra lo ha detectado y listado, es posible que otros servidores de correo
rechacen nuestros envos pensando que son SPAM.
Cmo saber si hago relay?
Hay pginas en Internet que pueden hacernos un test de relay probando varias
tcnicas, en esta que os pongo de ejemplo y que podeis encontrar en:
http://www.abuse.net/relay.html , podeis considerar que no haceis relay si pasais
las 8 primeras pruebas con xito.
Imagen 16, pagina para hacer un test de relay.

Una forma fcil y rpida de comprobar si hacemos relay o no, es conectarnos

desde otro punto a nuestro servidor de correo por telnet al puerto 25.
Imagen 17, conexin al SMTP de un servidor de correo de Microsoft.

Imagen 18, intento de hacer relay.

Como podemos ver si tratamos de usar el servidor de correo de Microsoft para

hacer relay sea enviar un correo de alguien que no es de Microsoft a alguien
que no es de Microsoft, el servidor no responder con un unable to relay
indicndonos que no podremos hacer esto en su servidor.
Microsoft al igual que otras empresas usan una tcnica denominada tarpit que
hace que una vez que el servidor de correo detecta un intento de relay empieza
cada vez a responder mas lento al atacante, de esta forma los que intentan hacer
el spam dejan de intentarlo ya que no les resulta productivo, podis leer mas
sobre esta tcnica en: http://support.microsoft.com/kb/842851
Cmo evitar hacer relay con Exchange 2003?
Editaremos las propiedades del servidor SMTP de Exchange que tengamos
publicado.
Imagen 19, editando el servidor SMTP publicado.

Imagen 20, configurando el relay en el servidor SMTP.

Imagen 21, configurando el relay en el servidor SMTP.

Una vez hecho esto, probar vosotros mismos con el telnet a hacer relay.
Si por alguna razn necesitis hacer relay desde el interior de vuestra red, es
posible aadir estos servidores a las excepciones mostradas en la imagen 21, aunque yo
prefiero crear otro servidor virtual de SMTP desde la consola de Exchange.
Cmo saber en qu listas negras estoy metido?

Si creis que estis metidos en alguna lista negra, hay paginas en internet que os
pueden ayudar a interrogar varias listas negras.
Imagen 22, viendo si Microsoft.com est en alguna lista negra desde dnsstuff.com

Imagen 23, resultados del informe.

Si buscis en google por relay blacklist database encontrareis otros sitios

donde poder consultar estas bases de datos.
Qu hacer si estoy en una lista negra?
Esta pregunta no tiene fcil respuesta, lo primero es aseguraros de que no hacis
relay o si lo hacis corregirlo, luego tendris que buscar la web de la lista negra
en la que estis listados y tratar de poneros en contacto con ellos para que os
quiten, en algunos casos es rellenando un formulario en la web, en otros casos

solicitan donativos para quitaros o simplemente no aceptan solicitudes de

quitar de las listas, afortunadamente cada vez es menor las empresas que usan
estas listas, ya que en algunos casos se estn convirtiendo en fuentes de
problemas, falsos positivos y estafas.
Conclusiones
Espero que este articulo os haya servido para aprender un poco
ms sobre el funcionamiento del correo electrnico, en siguientes artculos
de la serie bsicos tratare el tema del IMF, y las operaciones del da a da
con Exchange tales como listas de distribucin, usuarios, desvos de correo,
etc.