Cómo saber si tu servidor de correo permite Relay?

NOTA: Este post fue publicado originalmente en mi anterior blog el
13/08/2007

Como «Corolario» a los artículos sobre Cómo Enviar Correo Electrónico «a mano» (PARTE I y PARTE II), les quiero mostrar una forma rápida de verificar si un servidor de correo está permitiendo el reenvío no autorizado de de correos (Open-Relay).

Primero que todo, me gustaría quitar un poco el estigma negativo a la palabra Relay: Relay significa simplemente «retransmitir». El Relay en sí no es malo, de hecho, hay un «Relay Bueno» y un «Relay Malo«.

Todo Servidor SMTP, por definición, debe aceptar los correos que van dirigidos hacia su dominio SMTP, es decir, «si yo soy el servidor de @dominio.org, debo aceptar todos los correos entrantes dirigidos a *@dominio.org». (dejamos de lado por un momento las consideraciones de filtrado antispam previas y posteriores a la conexion SMTP, hasta un próximo post).
 
Que pasa si, por ejemplo, tengo a muchos clientes remotos que revisan su correo usando protocolos POP3 o IMAP (diversas razones pueden justificar este escenario: desde las preferencias personales del administrador hasta el uso de dispositivos móviles como PDAs o BlackBerry en modo «Profesional»). Ellos necesitarán un Servidor de Correo Saliente (SMTP) para poder enviar su correo electrónico, el cual no solamente irá dirigido a nuestro dominio SMTP, sino que muchos otros dominios SMTP de clientes, proveedores, amigos, familiares, etc, etc, etc. Por lo tanto, en este escenario, nosotros debiésemos permitir el relay a través de nuestros servidores a nuestros usuarios en ubicaciones remotas. Esto sería «Relay Bueno«.

Por otra parte, si yo soy un spammer, me gustaría poder enviar miles (o millones) de correo comercial  no solicitado (UCE, Unsolicited Comercial E-Mail, o SPAM), idealmente a costa de los recursos de otros servidores (entre otras razones, para no caer yo mismo en una lista negra). Entonces yo busco a servidores que me permitan, sin autentificarme, enviar correos electrónicos a cualquier dominio SMTP. (ver Cómo Enviar correo electrónico a mano, Parte II: SMTP Autenticado). Esto sería el «Relay Malo»

Enredado?
En realidad es súper simple: Si yo soy el servidor de correo que sirve al dominio SMTP @empresa.org, nadie debe ser capaz de enviar correo electrónico a través mío a un dominio que no sea @empresa.org. (salvo mis usuarios autenticados).

Luego de esta larga, pero necesaria introducción sobre relay, manos a la obra.

La prueba para verificar si un servidor está permitiendo el Relay Abierto (Open Relay o Anonymous Relay), es conectarse anónimamente al servidor y tratar de enviar un correo a un dominio cualquiera de internet, distinto del dominio SMTP del servidor.
(Los detalles los puedes ver en el Artículo sobre cómo enviar correo electrónico a mano).

image

En este caso, el servidor de correo, al verificar que, anónimamente, estamos tratando de enviar un correo a un dominio que no es el propio, de inmediato arroja un mensaje de error (550 5.7.1 Unable to relay for usuario88@hotmail.com) indicando que no va a reenviar este mensaje.
Espero, en un próximo post mostrarles cómo se configura el servidor Virtual SMTP de un Exchange Server 2003 para conseguir este resultado.

Update: … y en Exchange 2007 y 2010 también!

Finalmente, no puedo dejar de mencionar que existen varias herramientas gráficas y sitios de internet a través de los cuales revisar si un servidor está permitiendo Relay, es cosa de pedirle a nuestro buscador favorito que nos encuentre «test open relay»…. pero no es tan divertido como hacerlo uno mismo usando la línea de comandos, verdad? 😉

Gonzalo

Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado

NOTA: Este post fue publicado originalmente en mi anterior blog el
11/08/2007

En un artículo anterior aprendimos cómo enviar un correo electrónico a mano, es decir, utilizando solamente la línea de comandos y las instrucciones del protocolo SMTP. 

La gran mayoría de los servidores SMTP del mundo piden credenciales a los clientes que tratan de enviar correos a través de ellos, cuando el correo no está dirigido al dominio SMTP de éste (algunos simplemente las exigen, como espero mostrarles en una futura sección de Antispam), por esta razón en esta segunda parte veremos cómo es el procedimiento para enviar correo electrónico autentificándonos en el servidor, es decir, entregando nuestros nombre de usuario y contraseña durante la sesión SMTP. 

Los detalles sobre cómo es una sesión SMTP pueden verlos en el post sobre cómo enviar un correo electrónico a mano, por lo que ahora nos centraremos en la parte de la autenticación.

Primero, desde una línea de comandos, hay que conectarse al Servidor SMTP usando:

telnet <Servidor_SMTP> 25

Como respuesta obtendremos un banner similar a este:

image

Los pasos a seguir son:

1. Saludo al Servidor. Ahora, saludaremos al servidor con un comando EHLO, en vez de HELO. Esto no es dislexia (ni disteclia), sino que es una abreviación de Extended HELO ;).
En el Banner vimos que el Servidor es un Servidor que soporta Extended SMTP (ESMTP), por lo que como respuesta a este saludo, el servidor nos entregará una lista de los comandos de ESMTP que soporta.

image

Nota: algunos sistemas verifican que nosotros seamos realmente quienes decimos ser realizando consultas de DNS-Reverso o verificando nuestra IP en una Lista Negra, pero esos temas los veremos pronto, en los artículos de Antispam que pronto publicaré 😉 

2. Ingresamos el nombre de usuario y contraseña. usando el comando AUTH LOGIN, decimos al servidor que vamos a autenticarnos usando login y password, por lo que el servidor nos responde con un amistoso: 334 VXNlcm5hbWU6  QUË?

ESMTP usa como método de codificación Base64, por lo que, salvo que seas un balazo (de)codificando en Base64, es indispensable que tengas un codificador/decodificador de Base64 a mano ;).
Luego de una búsqueda por «Base64 Decoder», nuestro buscador favorito debiese darnos al menos una respuesta, por ejemplo yo usé éste decodificador.

Ahora si …

334 es un código para indicarnos: OK, esperando Datos, y VXNlcm5hbWU6 , que es la codificación para «Username:«-. 

Usando el Codificador transformamos nuestro nombre de usuario a Base64, y lo pegamos en la línea de comandos. Si nuestro login name fuese, por ejemplo: nombre.apellido, al servidor hay que ingresarle: bm9tYnJlLmFwZWxsaWRv.

La respuesta del servidor ahora es:  334 UGFzc3dvcmQ6.
334, al menos ahora ya sabemos lo que significa ;), y nuestro decodificador de base64 nos dice que «UGFzc3dvcmQ6» es la codificación para «Password:».
Necesitamos, entonces, codificar nuestro password y pegarlo para enviárselo al servidor. Si nuestro password fuese, por ejemplo: P@assw0rd, la codificación sería: UEBhc3N3MHJk.

image

Finalmente, si ingresamos bien la contraseña, el servidor nos entrega un mensaje de autentificación exitosa: 235 2.7.0 Authentication successful. (mmm….esta vez sin codificar? … cómo?, y justo cuando ya nos estábamos acostumbrando al Base64… 😉

En este momento, ya estamos autenticados en el servidor, por lo que en adelante el proceso de envío de mail es el ya conocido.

3. Indicamos el remitente y destinatario(s): MAIL FROM: y RCPT TO.
Lo importante es que ahora, dependiendo de la configuración del servidor, podríamos enviar correos sin importar que el remitente y/o destinatario pertenecieran al dominio SMTP del servidor. En nuestro ejemplo, el dominio smtp del servidor es @dominio.org, pero como remitente se usó una dirección @gmail.com, y como destinatarios direcciones @gmail.com y @hotmail.com

image

4. Enviamos el Cuerpo del Mensaje. Usamos el comando DATA. Dentro del cuerpo del mensaje es muy recomendable incluir un nombre de destinatario (Esto le indica al servidor que comenzaremos a enviar el cuerpo del correo («la Data»).

El Servidor nos responde que podemos comenzar a enviar los datos, y que debemos presionar la secuencia Enter -> . -> Enter para indicarle que hemos terminado con el cuerpo del mensaje (Enter, luego un punto y Enter nuevamente).

En el cuerpo del mensaje se incluye una línea con el comando From: (Usuario Gonzalez), y otra con el comando subject: (mail de prueba). Estas líneas son importantes pues la gran mayoría de los servidores de correo bloquean los mensajes sin «asunto», o sin nombre de remitente por considerarlos SPAM.

image

Update: Los servidores de Correo Exchange 2007 exigen que el remitente sea una dirección de correo válida: usuario@dominio.org.

Luego, el Servidor nos responderá que el mensaje fue recibido correctamente, indicándonos el identificador interno que le dio al correo.

5. Cerrar la Conexión. Finalmente, debemos cerrar la sesión en el servidor con el comando QUIT. (como lo muestra la imagen anterior) 

En este segundo artículo de la serie, vimos como enviar un correo electrónico autentificándonos en el servidor con nuestro nombre de usuario y contraseña usando el protocolo ESMTP.

Gonzalo

Etiquetas de Technorati: ,,

Cómo Enviar Correo Correo Electrónico "a mano"?: Parte I

NOTA: Este post fue publicado originalmente en mi anterior blog el
11/08/2007

En una conferencia sobre Troubleshooting que dimos en el GLUE, me llamó la atención que muy pocas personas supieran enviar correos electrónicos usando sólo la línea de comandos (y no a través de un cliente de correo, como Outlook u Outlook Express). Por eso el siguiente artículo.

Muchas veces, como parte de las pruebas que realizamos para resolver problemas de flujo de correo entre servidores, luego de hacer un TroubleShooting de Redes Básico, el siguiente paso es revisar que la comunicación SMTP pueda establecerse exitosamente.

Para esto es necesario conocer un poco de «SMTP-nés».

Primero, desde una línea de comandos, hay que conectarse al Servidor SMTP usando:

telnet <Servidor_SMTP> 25

El 25 luego del nombre o dirección IP del servidor corresponde al puerto al cual estamos estableciendo la conexión, en este caso el 25 es el estándar para smtp.

Si la conexión se establece exitosamente, el servidor mostrará una respuesta consistente de un código, y un banner con su nombre, el software SMTP que está ejecutando, la versión de éste, la fecha y la hora. Un servidor SMTP MS Exchange 2003 SP2, despliega un banner similar a este:

image 

En este punto es interesante mencionar que como respuesta a nuestros comandos (o verbos), el servidor siempre nos entregará un código numérico con la siguiente nomenclatura:

  • 2XX: operación ha concluido con éxito. 
  • 3XX: operación aceptada, pero se esperan nuevos datos.
  • 4XX: error, servidor queda a la espera que se repita la instrucción.
  • 5XX: error permanente.

Los pasos a seguir son:

1. Saludo al Servidor. Como personas educadas que somos, lo que corresponde es saludar al Servidor, indicando nuestra identificación (nuestro nombre dns). El Servidor, que también es todo un caballero, nos responderá el saludo (con su correspondiente código).

image

Nota: algunos sistemas verifican que nosotros seamos realmente quienes decimos ser realizando consultas de DNS-Reverso o verificando nuestra IP en una Lista Negra, pero esos temas los veremos pronto, en los artículos de Antispam que pronto publicaré 😉 

2. Indicamos el remitente y destinatario(s), usando los comandos MAIL FROM: y RCPT TO:, éste último más de una vez, en caso de querer enviar mail a más de un destinatario.

Nota: Los comandos SMTP no son sensibles a mayúsculas y minúsculas.

image

El servidor nos validó como remitentes válidos y validó al destinatario de nuestro mail (su dirección de correo electrónico) como válida, y está listo para recibir el mensaje.

3. Enviamos el Cuerpo del Mensaje. Para realizar esto le escribimos el comando DATA. Esto le indica al servidor que comenzaremos a enviar el cuerpo del correo («la Data»).

image

El Servidor nos responde que podemos comenzar a enviar los datos, y que debemos presionar la secuencia Enter -> . -> Enter para indicarle que hemos terminado con el cuerpo del mensaje (Enter, luego un punto y enter nuevamente). 
En el cuerpo del mensaje se incluye una línea con el comando subject: (mail de prueba). Esta línea es importante pues la gran mayoría de los servidores de correo bloquean los mensajes sin «asunto» por considerarlos SPAM.

Luego, el Servidor nos responderá que el mensaje fue recibido correctamente, indicándonos el identificador interno que le dio al correo.

4. Cerrar la Conexión. Finalmente, debemos cerrar la sesión en el servidor con el comando QUIT.

image

En este primer artículo de la serie, vimos como enviar un correo electrónico usando sólo comandos smtp. En el Próximo Artículo veremos cómo enviar correo cuando el servidor SMTP Requiere de Autentificación.

Gonzalo

Etiquetas de Technorati: ,,

Troubleshooting de Redes Básico

NOTA: Este post fue publicado originalmente en mi anterior blog el
10/08/2007

Cuando se está tratando de resolver un problema de comunicación, por ejemplo de flujo de correos entre servidores, lo segundo que hay que revisar (lo primero, todos sabemos: verificar que el servidor esté «encendido y con todos sus cables bien conectados» 😉 ), es probar que se pueda establecer comunicación con éste. Para realizar las pruebas utilizaremos herramientas que ya vienen incorporadas en Windows.

1. Lo primero es lo Primero: Ping

Abrimos una ventana de Símbolo de Sistema (o D.O.S., o consola, o línea de comando, o shell) y escribimos:

ping <IP_Destino> -N 10

El comando ping, realiza una solicitud de echo ICMP (echo-Request) al servidor que queremos verificar. Por defecto se realizan 4  solicitudes, pero yo prefiero usando el parámetro -N <número>, darle un múltiplo de 10. Esto tiene 2 razones bastante simples: 

  • Si hay problemas de intermitencia en el enlace (me ha pasado con enlaces de microondas), sólo 4 ping no siempre detectan esta situación.
  • Si se realiza una cantidad múltiplo de 10 es inmediato el cálculo del porcentaje de pérdida de paquetes 😉

image

El ejemplo anterior corresponde a un cliente que perdía la conexión con el servidor de Escritorio Remoto dónde estaba el ERP de la empresa. Este era un enlace de microondas que tenía “mal apuntada” la antena y gracias a éste (y otros muchos reportes, con más paquetes) pudimos identificar el problema.

Otra información importante que se puede sacar desde este ping es que tan rápida o lenta está la red, viendo el tiempo de recorrido redondo (roundtrip). Claramente no hay un tiempo óptimo, pues depende de las características de la red, la congestión y el ancho de banda. Aún así este valor no debiese superar los 20 ms (en el ejemplo: un mínimo de 80 y un máximo de 841 no fueron buenos números).

Finalmente se puede determinar qué tan “lejos” está el emisor del receptor del mensaje, comparando los valores del TTL.

IMPORTANTE: En el ejemplo anterior se hace ping desde el equipo cliente en la ubicación a un servidor web de una muy conocida y prestigiosa Universidad 😉 . Por qué?, porque yo sé que ese servidor “SI responde PING”. Es posible que el “destino” del Ping no esté configurado para responder Ping, o que haya un firewall bloqueando las peticiones de echo, por lo que si como respuesta a un ping “no hay respuesta” esto no necesariamente indica problemas en la red o en el servidor.

2. NSLookup

En el ejemplo anterior en realidad hicimos una pequeña trampa: asumimos que el servidor DNS estaba funcionando 😉

El servidor DNS es el encargado de hacer la traducción <nombres> = <dirección IP>. En este caso: www.uc.cl = 146.155.99.60, pues en realidad, la petición de eco se hace a la IP de destino, no al <nombre>.

La herramienta más básica para revisar que el servidor DNS al cual estamos consultando esté respondiendo es nslookup, que en su forma más simple puede invocarse de la siguiente forma:

nslookup <IP_Destino>

Una posible respuesta a esta solicitud es la del siguiente ejemplo:

image 

Las primeras líneas identifican al servidor que me está respondiendo la consulta: 192.168.8.1 y el puerto 53 (estándar para DNS)

La tercera línea indica que el servidor no es “dueño” ni “parte” de la zona DNS, por lo que su respuesta no es “de primera mano”, sino que responde “lo que sabe”.

Finalmente las últimas líneas identifican el nombre con su dirección IP. Una respuesta distinta a ésta implicaría problemas con el servidor DNS o con su capacidad para resolver (por sí mismo o preguntando a otros servidores) las consultas que se le realizan. En este caso (y como regla general), es mejor ejecutar los comandos con la dirección IP en vez del nombre.

3. Tracert

OK. Ya sabemos si tenemos, o no, pérdida de paquetes, y sabemos encontrar la dirección IP de nuestro destino. Otra herramienta muy útil en la resolución de problemas es Tracert (traceroute en sistemas basados en Unix), pues nos permite saber por dónde (por cuáles routers) pasan los paquetes mientras viajan entre el origen y el destino.

tracert <IP_Destino>

Una ejecución se muestra en el siguiente ejemplo:

image 

La Primera columna indica el número de salto. Las siguientes 3 muestran el tiempo de respuesta del router frente a los paquetes enviados, si el resultado es un (*) simplemente indica que no se obtuvo respuesta. La cuarta columna muestra el router: nombre, si es capaz de resolverlo, o su dirección IP.

La primera línea (primer salto), si tiene el número 0, es el equipo local, si tiene el número 1 es el Default Gateway o puerta de enlace del equipo desde el cual se está ejecutando el Tracert. La última línea debiese ser el Servidor o Equipo de destino. (no siempre es alcanzable).

Una variante súper interesante de Tracert es VisualRoute, que muestra visualmente en un mapa del mundo la ubicación (aproximada, por cierto) de los routers por dónde pasa un paquete en su recorrido por la súper carretera de la información. (Se requiere JAVA)

3. PathPing

Una de mis favoritas, pues combina en una sólo herramienta las 3 anteriores :D.

pathping <IP_Destino>

El funcionamiento de pathping es más o menos el siguiente:

  • Primero resuelve el nombre del destino a su dirección IP. (Nslookup)
  • Luego obtiene el camino por dónde viajan los paquetes (Tracert)
  • Finalmente, realiza una prueba de conectividad enviando una ráfaga de solicitudes de eco ICMP, es decir, hace ping muchas veces a cada router en el camino recién obtenido.
  • Y lo mejor, despliega estadísticas sobre pérdidas de paquetes al final de la ejecución 🙂

En nuestro ejemplo del enlace vía microondas:

image 
image 

Notas:

  • BORRADA corresponde a IP’s públicas reales, borradas para proteger la identidad de los implicados 😉
  • Los saltos (routers) 7 y 8, destacados en otro color, presentaban pérdidas de paquetes.
  • Pathping tarda un rato, alrededor de 5 minutos, en terminar de ejecutarse, debido a la cantidad de paquetes (100) que envía a cada salto, pero vale la pena esperar.

4. Notas Finales

Muchas de estas herramientas (si no todas) poseen una versión en entorno gráfico, tal vez más amigables y tal vez hasta gratis. De todas formas creo importante saber que existen y vienen junto al sistema operativo, pues a veces es a lo único a lo cual podemos echar mano.

Tip: para quienes den exámenes de certificación sobre networking, el uso de estas herramientas son preguntas seguras 😉

Otra consideración importante es que en este artículo revisamos las herramientas con sus opciones más elementales (o las que eran mis favoritas), pero todas éstas poseen muchas otras funcionalidades que son interesantes y útiles. Sólo basta con escribir el nombre de la herramienta seguido de un “/?” para descubrirlas 😉

Espero que esto les haya resultado de utilidad y que NO tengan que usarlo para resolver problemas en sus redes 😉

Gonzalo

Exchange 2010 Disponible ahora YA!

Hoy se liberó Exchange 2010 en su versión final (RTM).

Esto quiere decir que ya está disponible para ser descargado por usuarios corporativos, personas con suscripciones technet o msdn, y por cualquier persona que quiera probarlo en los siguientes links:

Les dejo algunos links con información de capacitación gratuitos sobre Exchange 2010

 

Gonzalo

Home

 

Nuevo Libro Gratuito: Exchange 2010 – A Practical Approach

Jaap Wesseluis, MVP en Exchange, escribió un muy interesante libro sobre Exchange 2010, el cual está disponible para su descarga gratuita (previo registro) en el siguiente link:

FREE! «Exchange 2010 – A Practical Approach

La tabla de contenidos es la siguiente:

  • Chapter 1: Introduction to Exchange Server 2010
  • Chapter 2: Installing Exchange Server 2010
  • Chapter 3: Exchange Server 2010 Coexistence
  • Chapter 4: Managing Exchange Server 2010
  • Chapter 5: High Availability in Exchange Server 2010

y tal como dice su título, es una presentación de Exchange 2010 desde un enfoque práctico, con muchos diagramas y aún más guías paso a paso para la implementación y configuración de Exchange 2010.

Espero que les sea de utilidad.

Gonzalo