Notas desde el Mundo Real: Exchange Server

Soporte para Exchange Server en Entornos Virtualizados

Tue, 19 Aug 2008 16:21:28 GMT

Es realmente un agrado poder escribir sobre 2 tecnologías que me gustan: Exchange Server y Virtualización.

Ayer se actualizó el documento llamado Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments (en español sería algo así como: Políticas de Soportes y Recomendaciones para Servidores Exchange en Entornos de Virtualización de Hardware), el cual responde a cuáles son las configuraciones de hardware soportadas [1] por Microsoft para tener servidores exchange en producción.

Vamos por Partes…

1. Hyper-V/Virtual Server 2005 vs “los otros”

Como sabemos, aparte de Hyper-V y Virtual Server hay otros actores de importancia en el mercado de la Virtualización: VMWare, Xen, Virtual Iron, etc, etc, etc.

Hace poco Microsoft ha abierto una instancia llamada Windows Server Virtualization Validation Program “abierta a cualquier vendedor que entregue soluciones de virtualización para Windows Server 2008, Windows 2000 Service Pack 4 y Windows Server 2003 SP2 y siguentes SP. Esta solución pues estar basada en Hypervisor o en host. El programa permite a los vendedores validar varias configuraciones a fin de que los clientes de Windows Server puedan recibir soporte técnico en entornos virtualizados …”.

Actualmente están participando: Cisco, Citrix, Novell, Sun y Virtual Iron. (Veremos alguna vez a VMWare en la lista?)

Más información en: Windows Server Virtualization Validation Program

2. Soporte para Exchange Server

2.1 Exchange 2007 SP1

Microsoft Soporta Exchange Server 2007 en ambientes de producción sólo cuando se cumplen todas las siguientes condiciones están presentes.

El software de Virtualización es Hyper-V o cualquier otro hypervisor que haya sido validado en el Windows Server Virtualization Validation Program.
La máquina Virtual (Guest) de Exchange:
- Sea Exchange 2007 SP1 o superior.
- Se haya instalado sobre Windows Server 2008
- NO tenga el Rol de Mensajería Unificada (UM) instalado
El almacenamiento de la máquina virtual puede ser VHD de tamaño fijo, Discos SCSI Pass-Through o iSCSI. Se recomienda que los VHD's no superen los 2048 GB (2 TB!!) de tamaño.
No está soportado el uso de discos diferenciales.
La Partición Padre o Root (máquina física) no debe tener instalado ningún software que no sea de administración (Antivirus, Backup, etc), es decir, sólo puede estar dedicada a virtualización.
No está soportado un ambientes de cluster combinados, por ejemplo, Cluster CCR de máquinas Virtuales MAS Quick Migration (Failover Cluster) en Hyper-V. pero si está permitido tener una solución CCR o SCC usando una combinación de nodos Físicos y virtuales (Cool :D)

2.2 Exchange 2003

Microsoft Soporta Exchange Server 2007 en ambientes de producción sólo cuando se cumplan todas las siguientes condiciones:

El software de Virtualización es Virtual Server 2005 R2 o superior
La máquina virtual (Guest) de Exchange debe tener instalado Exchange server 2003 SP2 o superior
Deben estar instaladas las las Virtual Machine Additions de Virtual Server 2005 R2 en la máquina virtual.
Exchange Server 2003 debe estar configurado como servidor único y no como parte de un Cluster.
El Driver (Controlador) de disco SCSI instalado en la máquina virtual debe ser Microsoft Virtual Machine PCI SCSI Controller.
No debe estar habilitada la función de “Deshacer" (Undo Disk) para la máquina virtual

2.3 Exchange 2000 y Anteriores

No está soportada para producción ninguna versión de Exchange Server anterior a Exchange 2003, esto incluye a Exchange 2000 y Exchange 5.5

Finalmente, en el documento Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments no sólo está la Política de Soporte que acabo de transcribir/traducir, sino que también una serie de recomendaciones, las cuales discutiremos en otro post o en alguna conferencia por ahí ;)

Gonzalo

[1] Valga la aclaración: “soportado por MS” significa que si llamas a microsoft pidiendo soporte, entonces MS va a tomar tu caso y encontrar una solución a tu problema, pues es un entorno que ya fue probado, re-probado y recontra-probado por ellos y por lo tanto saben cómo funcionan sus productos. Esto es valido tanto si eres un usuario doméstico y tienes problema con Office, XP o Vista como si eres una gran empresa con un contrato de soporte premier. Lo anterior no significa bajo ningún punto de vista que “no funcione” alguna configuración por el hecho de no estar “soportada por MS”.

Technorati Tags: Exchange Server,Soporte,Virtualización,Hyper-V,Virtual Server

iPhone se pone pantalones largos (en su versión 2.0)

Tue, 15 Jul 2008 16:55:07 GMT

Los fans de apple [1] deben estar muy contentos con la aparición del nuevo iPhone, con soporte para 3G (navegación en internet más rápida) y a mitad del precio de lo que costaban los primeros iPhones.

Según leí, dos son los principales cambios en la nueva versión del iPhone:

Soporte para redes 3G
Actualizaciones de Software respecto de la versión 1.0.

El soporte para Redes 3G es un aporte para quienes utilizan sus dispositivos móviles para navegar por internet, especialmente en sitios con contenido multimedia como youtube, soapbox, facebook, etc.

Las actualizaciones de software, que es lo que nos interesa en este artículo, estarán también disponibles para los usuarios que tengan una iPhone de “primera generación”.

Por qué el título hace mención a los “pantalones largos”?

Una de las principales falencias del iPhone en su versión anterior es que no tenía soporte para integrarse en ambientes empresariales (Exchange Active Sync, para ser más específicos), por lo tanto el teléfono servía como “juguete” para personas que leen gmail, pero no servía como herramienta de trabajo en un entorno corporativo, a diferencia de equipos Nokia, Blackberry, Palm, etc. (aquí está el resto del “etc”).

Luego del acuerdo firmado en marzo de este año (Versión MS, Versión Apple), y de unos tantos meses de trabajo de ambos equipos, con la liberación del iPhone 2.0 también se liberó la actualización (parche? :p) para que el iPhone pueda sincronizar información con servidores Exchange usando tecnología Exchange ActiveSync (EAS para los amigos), con lo cual el iPhone comienza a ser considerado como una alternativa válida en entornos empresariales.

Más información:

Integración Empresarial de iPhone con Exchange (Versión Apple)
iPhone desde la perspectiva del Administrador Exchange (Versión MS)

Espero que les sirva.

Gonzalo

Technorati Tags: Exchange Server,iPhone,Exchange ActiveSync

[1] En marketing es un caso de estudio la relación de “amor” que genera apple con sus ~~fans y amantes~~ clientes…

Cómo ver Calendarios de Google en Outlook

Mon, 10 Mar 2008 23:08:44 GMT

Debido a mi "doble vida" de estudiante y Trabajador Freelance, debo mantener más de un calendario: Uno para la universidad, uno para eventos familiares, uno para cada cliente, etc., Algunos de estos calendarios están asociados a un Buzón en un Servidor Exchange (Trabajo) y otros en Calendarios de Gmail (GCalendar).

El problema es ¿cómo, al menos, hacer visible el todos los calendarios en un sólo lugar?

La solución: MS Outlook. Con MS Outlook 2007 (desconozco si con versiones anteriores también es posible).

1. Compartir el Calendario Web.

Veamos un día cualquiera (hoy) en un calendario de Google Cualquiera (el que uso para las actividades de la Universidad). Como pueden ver hay una cita de un seminario de Diseño para hoy a las 15 horas (Izquierda), pero esa cita no se refleja en mi calendario de Outlook (Derecha)

Lo primero que hay que hacer es compartir el calendario en GCalendar, para eso presionamos el la flecha hacia abajo al lado del nombre del calendario en la página web, se desplegará un menú y elegimos la opción "Configuración de Calendario", y en la nueva ventana vamos a la opción: "Dirección Privada".

Hacemos Click en el Botón verde ICAL, y aparecerá un pop-up con la dirección del calendario, Debemos COPIAR esta dirección, pues la necesitaremos para realizar la suscripción al calendario.

2. Suscribir el Calendario

Ahora vamos a Outook, y en el Menú "Herramientas" seleccionamos "Configuración de la Cuenta", se nos abrirá una venta, y en ésta seleccionamos la lengüeta "Calendarios de Internet", y presionamos el Botón "Nuevo...".

En esta ventana debemos ingresar el URI (o URL, para los más antiguos) de la "Dirección Privada" , que copiamos desde la configuración de GCalendar

Al Hacer Click en Aceptar, se despliega una ventana con "Opciones de Suscripción", Seleccionamos lo que nos parezca conveniente (como el nombre) y Click en "Aceptar"

Luego, nos aparece el calendario configurado, y en estado de "pendiente" hasta la siguiente sincronización, y un mensaje explicando por qué. presionamos Aceptar.

Al refrescar la ventana de Outlook, ahora podemos ver el calendario al que nos suscribimos en la barra de menús de la izquierda, y seleccionamos este nuevo calendario.

Al seleccionar el nuevo calendario, parte central de la ventana de outlook ahora despliega 2 calendarios:

Y en el calendario de la Derecha (Verde) ahora SI aparece la Cita que tengo en un rato más (debo terminar de escribir esto rápido!)

Para ver UNA sola vista de ambos calendarios, podemos presionar sobre la flecha que apunta hacia la izquierda en la lengüeta del nombre del calendario...

Ahora podemos tener en una sola vista AMBOS calendarios. Esto aplica a más de un calendario.

Finalmente sólo 2 observaciones.

1. Los calendarios a los que uno se suscribe son de sólo lectura, por lo que no es posible crear o editar citas en GCalendar desde Outlook.

2. Para quienes se hayan dado cuenta del detalle, la cita original es a las 15 Hrs., pero al suscribir el calendario, ésta se muestra a las 16 Hrs. Esto se debe al cambio de Zona horaria que se realizó en Chile y que afectará las próximas 3 semanas (Tengo mi PC con Zona Horaria correspondiente a Brasilia). Pero en condiciones "normales", no hay desfase de horas entre los calendarios ;)

Espero que este "truco" les sirva a Uds. tanto como me ha servido a mi

Gonzalo

IMPORTANTE: Extensión del Horario de Verano

Thu, 06 Mar 2008 19:08:42 GMT

Les publico el mail que recibí hoy sobre el cambio de hora en Chile. Esta es la comunicación Oficial de Microsoft sobre cómo realizar la actualización de la zona horaria de Chile para reflejar el cambio de hora de este año. Para ir al sitio de las recomendaciones, pueden hacer click en la imagen o en el link del texto.

Importantísimo es tener en consideración que el cambio de hora aplica a todos los sistemas que tengan relación con la hora, en especial Sistemas de Monitoreo/Tiempo Real, Reloj Control de Asistencias, Tareas programadas, etc.

Gonzalo

Santiago, 6 de marzo de 2008
Estimado cliente:
Cómo usted ya debe estar informado, el Gobierno de Chile ha decidido extender de forma excepcional el horario de verano en el país por 21 días, hasta la noche del 29 de marzo. Esto implica que no se llevará a cabo el cambio de hora como es tradicional en nuestro país el segundo sábado de marzo, que es el próximo día 8 de Marzo.
Precisamente a las 23:59:59 de esa noche los sistemas computacionales realizarán un cambio automático retrasando la hora en 60 minutos, en concordancia con el inicio habitual del horario de invierno.
Microsoft Chile aconseja a sus clientes corporativos seguir las recomendaciones que hemos publicado en nuestra página web www.microsoft.com/chile/cambiodehora, incluido el aviso de exención de responsabilidad allí contenido para aminorar el impacto que esta extensión del horario de verano pueda tener en su organización.
De no seguirse las recomendaciones sugeridas, los sistemas computacionales de su empresa estarán funcionando durante tres semanas con una hora de diferencia con respecto a la hora oficial del país.
Esto impactará principalmente en las aplicaciones y programas que utilizan la hora como uno de los insumos centrales, estos son: agendamiento electrónico de reuniones, correos electrónicos y transacciones comerciales.
Esperamos que estas sugerencias le sean útiles durante los próximos días.
Atentamente.
Microsoft Chile

Antispam: Cómo Habilitar el Filtrado de Conexión usando Listas Negras en Nuestro Servidor Exchange 2003? Parte 1

Fri, 24 Aug 2007 06:32:19 GMT

Hoy recibí el llamado de un amigo preguntándome cuales proveedores de listas negras yo uso. Asi que aquí vamos...

Una de las opciones de filtrado de mensajes por conexión que nos ofrece Exchange 2003 es el uso de RBL's. (En Exchange 2000 había que usar productos de terceros o add-ons para poder usarlas).
Desde el punto de vista del administrador de un servidor de correo, las listas negras pueden ser un gran aliado, o un gran dolor de cabeza si caes en una :(
Veamos Por Qué.

1. Qué son las listas negras?

Para quienes no lo sepan, las listas negras (Black List), o RBL's por Real Time Block/Black List, son Bases de Datos que contienen listados de direcciones IP's pertenecientes a servidores de correo que han sido detectadas o reportadas como Open Relay, o que envían Spam.

2. Cómo Funciona el uso del filtrado de conexión usando listas negras?

Cada vez que llega una conexión SMTP a nuestro servidor, éste realiza una consulta de DNS reverso a su proveedor de lista negra, preguntando por la dirección IP del servidor de correo que está tratando de entregarnos un mensaje.

Por ejemplo, si el servidor que está estableciendo conexión con nostros tiene una dirección 192.168.8.2, y nuestro proveedor de listas negras es odioelspam.org, entonces nuestro servidor exchange hará una consulta de DNS Reverso de la forma: 2.8.168.192.odioelspam.org.

Nuestro proveedor de listas negras nos dará una respuesta, la cual podría ser:

"Host Not Found": indicando que la IP del servidor que nos está tratando de enviar un correo NO ESTÁ en su base de datos.
"127.0.0.Código": El proveedor no está indicando que la dirección IP del servidor que nos está tratando de enviar un correo SI ESTÁ en la Base de Datos. El "Código" que viene en la respuesta varía de proveedor en proveedor, no hay un estándar, pero generalmente indica el tipo de "abuso" con que se ha registrado la dirección IP en la lista negra (spam, masivo, open relay, etc). Consulte la documentación de su proveedor ;)

Si la dirección IP del Servidor que nos está tratando de enviar correo está en la lista negra, entonces nuestro servidor Virtual SMTP entregará un código de error 550 5.x.x como respuesta al comando RCPT TO.

Yo recomiendo utilizar más de un proveedor de Listas negras. Se puede establecer el orden en el que serán consultados.

NOTAS IMPORTANTES:

Puesto que este es un filtrado de conexión, el mail no es recibido, por lo que no se (mal)gastan recursos de red ni de máquina (procesando por virus o spam en otros niveles).
Este filtrado aplica sólo a nivel de Servidor Virtual SMTP, es decir, no sirve para mails internos enviados por MAPI (Outlook), OWA, RPC sobre HTTPs, etc (creo que es obvio por qué no, cierto?)
Esta técnica es bastante efectiva, pues cuando recibimos mails de un servidor que envía spam, generalmente nos trata de enviar MUCHOS mensajes en la misma conexión (Directory Harvest), por lo que me basta con sólo una consulta al proveedor de RBL's para bloquear MUCHOS mensajes que provengan de la misma dirección IP.

3. Cuánto Cuestan?

Hay proveedores de Listas Negras pagados, pero también hay proveedores gratuitos, como SpamCop.Net y SpamHaus.org. La principal diferencia entre ambos radica en la velocidad con la cual se actualizan las bases de datos y en la posibilidad de poder descargar una réplica de la Base de datos (zona DNS Reversa) del proveedor a un servidor local, con lo cual puedes acelerar mucho el tiempo de respuesta a las consultas.

5. OK. Se ven Bien, pero, Aplican a la Realidad Latinoamericana?

Esta es una pregunta que yo me estuve haciendo mucho tiempo, y la respuesta es... Claro que Si!!
A pesar que las principales fuentes de spam en el mundo no están en latam, mucho de su spam SI llega a nuestros servidores.

Cuánto es mucho?
Para motivarlos un poco más a que utilicen el filtrado de conexión basado en listas negras, les muestro las estadísticas (reales), sacadas mientras escribo este artículo, desde un servidor en producción configurado con los 2 proveedores gratuitos ya mencionados:

Consultas DNS Realizadas Block List: 30.510
Conexiones Rechazadas debido a Reglas de Block List: 18.549

El 60% de las conexiones que se tratan de establecer con este servidor Exchange son rechazadas debido a que las IP's están en listas negras!!!

6. Bonus: Yo soy Administrador de un servidor de correo y creo estar en una lista negra. Qué Hago?

El procedimiento para salir de una lista negra es bastante simple:

Primero: debe saber en cuáles listas estás metido, y por qué.
Segundo: debes resolver tu problema (generalmente debido a opciones de relay mal configurado o de equipos en tu red, posiblemente infectados con virus, que están enviado spam).
Tercero: debes comunicarte con el administrador de las listas negras en donde estabas metido, para contarles (generalmente mediante un formulario de contacto) que ya solucionaste tu problema y que te quite de la lista.
Esperar... a que seas removido de la lista.

Puedes revisar al final de éste artículo, la sección correspondiente a las listas negras y cómo saber en cuales estás ;)

Espero haber podido explicar qué son, como funcionan y los beneficios de usar filtrado de conexión basados en Listas Negras (RBLs). En un próximo artículo, les muestro cómo y dónde se configuran estas opciones en Exchange Server.

Gonzalo

Cosas que siempre quisiste saber sobre el correo electrónico y que nunca te atreviste a preguntar

Tue, 21 Aug 2007 01:28:18 GMT

Graciosamente, yo tenía pensado escribir exactamente este artículo, pero antes de escribirlo, chapoteando por internet, encontré que alguien ya lo había escrito por mi!!!

Daniel Matey, MCSE y MVP español en MOM, escribió en su blog una serie de artículos Básicos, respondiendo a las preguntas básicas clásicas que se ha encontrado en foros... justo justo lo que yo esperaba hacer en mi blog ... ;)

Para no reinventar la rueda, y puesto que está casi lo mismo que yo pensaba poner en este artículo, mejor les dejo estos links, pues los artículos están buenisimos y responden a preguntas del tipo: qué son los registros MX?, cómo crear registros MX?, cómo saber si mi servidor hace Relay?, cómo saber si estoy en una lista negra?, etc, etc...

Disfrútenlos ;)

Gonzalo

Relay Bueno: Permitiendo Relay en Exchange 2000/2003

Thu, 16 Aug 2007 17:16:46 GMT

En los artículos previos explicamos:

Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado
Cómo saber si tu servidor de correo permite Relay?:
- Qué es el Relay, distinguiendo entre "Relay Bueno" y "Relay Malo".
- Cómo verificar manualmente que nuestro servidor no permita Relay
Verificando las opciones de Relay en Exchange 2000/2003: Verificar en nuestro servidor y desde internet usando herramientas en línea, que no seamos un Open Relay.

Ahora, me gustaría hablar un poco sobre cómo efectivamente y de forma "segura" permitir el Relay (Reenvío) a través de nuestro servidor SMTP.

La pregunta obvia es: Por qué razón alguien querría permitir Relay en sus servidores de correo?
Razones pueden haber varias: Clientes de correo qué sólo poseen compatibilidad para POP3/IMAP4 necesitarán un servidor de correo SMTP para enviar mensajes (Clientes de correo antiguos o dispositivos móviles que no soporten ActiveSync, etc.), usuarios que viajan, etc.

Nota: en realidad, existiendo un cliente webmail tan bueno como OWA 2000/2003, no veo una buena razón para no usar OWA en vez de otros protocolos ;). Además de OWA está ActiveSync y RPC sobre HTTP(S), que permiten acceder al servidor de correo de forma segura para dispositivos móviles.

Bueno, la escencia del Relay Bueno es que sólo permitiremos el envío de correo para los usuarios del dominio que se autentifiquen con nuestro servidor de correo. En el artículo sobre Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado, vimos este comportamiento. Ahora les mostraré cómo hay que configurar el Servidor para que funcione de ésta forma.

Paso 1. Cerrar el Open Relay

En Exchange 2003 el Open Relay viene cerrado por defecto. De todas formas, les sugiero comparar la configuración de su servidor con la mostrada en éste artículo:

Verificando las opciones de Relay en Exchange 2000/2003.

Paso 2. Permitir el Relay SOLO a Usuarios Autenticados

En las propiedades del servidor Virtual SMTP (Exchange System Manager -> ... -> Servidor -> Procolos -> SMTP -> SMTP Virtual Server), en la lengüeta Acceso (Access) presionamos el botón de Autenticación (Autentication). Tendremos un par de ventanas como las del siguiente dibujo:

En la ventana de Autenticación, deben estar seleccionados los 3 checkboxes principales (como muestra la figura).
Ahora presionamos el botón Usuarios (Users) y se abrirá una nueva ventana.

En esta nueva ventana debemos dejar sólamente el grupo de Usuarios Autenticados (Authenticated Users), con los permisos de Enviar (Submit) y Reenviar (Relay).

En este último paso realizamos la configuración más importante: le dijimos al servidor smtp que los usuario autenticados y sólo éstos (es decir, los usuarios que se identificaron exitosamente con su nombre de usuario y contraseña al establecer la sesión smtp), pueden reenvíar correo a través de este servidor smtp a direcciones que no pertenecen a la organización (dominio smtp).

Luego cerramos todas las ventanas y reiniciamos el servicio SMTP para que se apliquen los cambios.

Finalmente, debo recordar que toda la información de usuarios y sus claves que se envían al servidor smtp (y al pop3 y al imap4), viajan en texto plano (o codificadas en Base64), por lo que es trivial con un sniffer poder obtener estas contraseñas.
Por eso es recomendable usar otros protocolos de envío/recepción de correo (Mapi, RPC sobre HTTP(S), HTTPS, ActiveSync, HTTPS, etc), o al menos cifrar las comunicaciones a estos servicios usando TLS (con certificados digitales para cada protocolo).

Gonzalo

Technorati Profile

SPAM.PDF y SPAM.XLS

Wed, 15 Aug 2007 04:30:22 GMT

Por lo visto, llegó para quedarse :(

La nueva moda en SPAM (o SPAM modelo 2007) es enviar un mensaje "inofensivo" con un archivo pdf adjunto... y en el archivo PDF viene la mención comercial indeseada.

Esta nueva técnica para enviar correo basura con publicidad adjunta es bastante "efectiva" pues los archivos pdf adjuntos vienen con caracteres "desordenados", similares a los que algunos sitios web piden ingresar para para poder registrarse o resetear las contraseñas.
De esta forma se consigue burlar los actuales mecanismos de filtrado por remitente, destinatario, links e imágenes incrustadas y palabras claves en el cuerpo o asunto del mensaje. (Salvo que el software antispam posea un módulo de OCR)

Un ejemplo que me llegó hace unos dias son las siguientes imágenes.

Lo peor es que parece que les está dando buenos resultados, pues ya se están detectando correos spam donde el mensaje viene dentro de un .xls adjunto.

La buena noticia es que las empresas que desarrollan soluciones antispam ya se están haciendo cargo de esta nueva amenaza.

Para más información sobre SPAM.PDF, puedes ver el siguiente White-Paper de GFI (en Inglés) o en éste artículo de Security Focus (en Inglés)-
Para más información sobre SPAM.XLS, puedes ver éste artículo. (En Inglés)

Gonzalo

Cómo Redirigir un correo a más de un destinatario externo con Exchange Server 200X?

Wed, 15 Aug 2007 03:44:50 GMT

En el foro/mailing-list del G.L.U.E. he visto un par de veces que se ha hecho esta pregunta. Por ese motivo les dejo un manualcillo mostrando cómo se puede configurar Exchange Server 200X para realizar esta tarea.

Supondremos que tenemos un usuario "Juan Perez" con dirección de correo jperez@empresa.com, que desea que todos los mails que llegan a su casilla sean redirigidos a dos casillas de correo externas (fuera de la organización Exchange): hotmail y yahoo.

Paso 1: Creación de Contactos

En Active Directory Users and Computers (ADUC), Ir a la OU donde vamos a crear a los nuevos contactos. Hacer click Derecho sobre la OU y seleccionar nuevo -> Contacto.
tenemos que tener los siguientes datos para crear el contacto:
Nombre: Juan
Apellido: Perez
e-mail Externo: jperez@hotmail.com
Personalmente me gusta poner junto al apellido el dominio al cual pertenece el contacto. En nuestro caso, es Juan Perez y el Dominio es Hotmail, por lo que en el apellido escribo Perez - Hotmail. Eso me permite visualmente saber a cuál dominio/empresa perteneces el contacto (y hacía dónde se dirigirá el mail), como se ve en la figura:

Al en la siguiente pantalla del wizard, tenemos que crear el alias de exchange asociado al contacto y su dirección de correo. El alias viene "pre-llenado", podemos mantener el mismo o cambiarlo.

Luego debemos presionar el Botón "Modify" para ingresar la dirección de correo externa.
Aparecerá una nueva ventana con varios tipos de direcciones de correo, seleccionaremos "SMTP Address" y presionamos OK.

Aparecerá una nueva ventana, en donde ingresaremos la dirección de correo de nuestro contacto, en nuestro caso: jperez@hotmail.com

Presionamos OK, volvemos a la ventana original y presionamos Finish para que se cree el nuevo contacto.

Nota: con esto ya es suficiente para que el contacto pueda ser encontrado en la GAL y enviarle mails, los cuales serán enviados directamente a su casilla externa.

Ahora debemos crear tantos contactos como necesitemos para hacer el envio de mails a direcciones externas. El proceso es exactamente el mismo.
En nuestro ejemplo crearemos sólo 2, tal como se ve en la imagen.

Paso 2: Creación de un Grupo de Distribución

En ADUC, Ir a la OU donde vamos a crear el grupo de distribución, Click Derecho sobre la OU y seleccionar Nuevo -> Grupo. Aparecerá la siguiente ventana.

Aquí debemos dar un nombre al grupo, éste puede ser cualquiera, pero es recomendable usar nombres de objetos que sean razonables y que permitan una fácil identificación.
Los conceptos sobre el Alcance (Scope) y el tipo (type) del grupo están fuera del alcance de este tutorial, pero para nuestro propósito, es más que suficiente con seleccionar: Global y Distribution, respectivamente. Presionamos Next.

En la nueva ventana activamos la opción de Crear una dirección de correo de Exchange, tal como muestra la figura. El Nombre del Alias no es relevante, sólo importa que no esté repetido.

La advertencia nos indica que si estamos en una situación con varios dominios o incluso varios forest, tenemos que privilegiar el uso de grupos Universales.
Presionamos Next y finalmente Finish en la siguiente ventana.

Con esto el Grupo ya ha quedado Creado.

Ahora, hacemos doble click sobre el grupo creado y en la nueva ventana seleccionamos la lengüeta de Miembros

Presionamos ahora sobre el botón Agregar (Add).
Aparecerá la típica pantalla de búsqueda, pero para que busque contactos, debemos presionar el botón de Tipos de Objetos (Object Types).

Se nos abrirá una nueva ventana y en ésta debemos seleccionar el tipo de Objeto: "Contactos".

Presionamos OK, volvemos a la ventana original de búsqueda y escribimos o buscamos a nuestros contactos. (por su nombre, por ejemplo)

Una vez agregados los contactos, tenemos que los miembros del grupo de distribución son nuestros contactos, como en la siguiente figura.

Nota: Otra forma de agregar los contactos al grupo es: desde las propiedades de cada contacto, seleccionando la lengüeta miembro de (Member Of) y ahí poner el grupo de distribución del cual el contacto va a "ser miembro".

Paso 3: Configurar el Reenvio de Correos

Finalmente, para poder configurar el reenvio de los correos, nos vamos a las propiedades del usuario a quien deseamos configurar que sus correos sean reenviados, y seleccionamos la lengueta: Exchange General, y ahí presionamos el botón de Delivery Options (Opciones de Entrega).

En la ventana "Opciones de Entrega", en la sección de Reenvío (Forward), seleccionamos "Reenviar a" (Forward To) y presinamos el botón "Modificar" (Modify).

Nos aparecerá la ya conocida ventana de búsqueda, ahi escribimos o buscamos el nombre de nuestro grupo de distribución recién creado, como muestra la figura, y presionamos OK.

Volvemos al la ventana original y tenemos que decidir si vamos a reenviar los mails conservando una copia en el buzón del usuario, para lo cual debemos marcar la opción de "entregar el Mensaje a Ambas direcciones la de reenvio y la del buzón".
Si no no queremos que quede una copia en el buzón del usuario, dejamos la opción sin seleccionar.

Presionamos OK dos veces y salimos de las propiedades del usuario.

Listo! Ahora cada vez que alguien le envie un correo a nuestro usuario (jperez@empresa.com), ésta será reenviada a las direcciones de correo Externas (Ambas), definidas en los contactos que creamos y que forman parte del grupo de distribución al cual configuramos el reenvío.

Gonzalo

Haciéndole la vida difícil a los Spammers: SMTP Tar Pitting (Pozo de Brea)

Tue, 14 Aug 2007 06:08:57 GMT

Como vimos en los artículos sobre envío de correo SMTP (PARTE I, PARTE II y Relay), al establecer una conexión SMTP es bastante fácil poder obtener una lista de las direcciones de correo válidas en un dominio: Basta con adivinar los nombres de usuario al enviar al correo el comando "rcpt to: <usuario_adivinando>@dominio.org".
Por ejemplo, si Juan Perez tiene una cuenta de correo jperez@dominio.org, generalmente veremos en los logs de recepción (y/o bloqueo) de correo, más de algún mensaje dirigido a casillas del tipo: jperez128@dominio.org, juanjperez@dominio.org, etc.
Claramente el spammer está intentando adivinar direcciones de correo válidas.

Si tenemos habilitado en nuestro servidor exchange el filtrado por destinatario (recipient filter) para que no acepte mensajes a destinatarios que no están en el directorio, es decir, sólo reciba correos para destinatarios que posean una dirección de correo válida, el servidor entregará un mensaje de error con código 5.x.y al atacante durante la conexión smtp.
Esto tiene 3 problemas:

Estamos dándo a nuestro atacante información sobre cuáles son las direcciones de correo electrónico válidas en nuestra organización.
Nuestro servidor SMTP está procesando un alto volumen de peticiones del atacante y realizando una gran cantidad de consultas al Servicio de Directorio (Active Directory), consumiendo inútilmente recusos valiosos.
El servidor de correo está obligado, por adhesión a la RFC 2821 a envíar un correo con un NDR al "remitente" que trata de enviar correos a las direcciones "equivocadas". En el caso de un ataque, aún más recursos desperdiciados.

La situación recién mencionada es conocida como un ataque de Directory Harvest, o Cosecha de Directorio).

Cómo respuesta a este problema, se puede implementar en nuestros servidores SMTP la funcionalidad de Tar Pitting, la cual consiste en introducir un retraso en las respuestas con código 5.x.y, usualmente asociadas a problemas derivados de ataques de SPAM.

La funcionalidad de TarPitting no es exclusiva de Exchange, pues es una característica del servidor SMTP, y por tanto de IIS, la cual está disponible para cualquier equipo tenga instalado el SP1 de Windows 2003 Server.

Cómo se configura?

Súper simple.

Debemos abrir el editor del registro (Inicio -> Ejecutar -> Regedit).
Buscamos la siguente ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters
Click derecho - Nuevo Valor DWORD.
Escribir: TarpitTime (OJO con las mayúsculas y minúsculas), Presionar Enter.
Abrir el nuevo valor creado (TarpitTime) haciéndo doble click sobre él, luego haga click sobre decimal e ingrese un número en el cuadro de texto. Por ejemplo: 8.
Cierre el editor de Registro.
Reinicie el Servicio SMTP del servidor.

Qué hicimos?. Creamos el valor en el registro y configuramos una demora de 8 segundos en las respuestas del tipo 5.x.y.
Por qué 8 segundos? porque 8 segundos es un tiempo razonable para que un usuario que escribió mal una dirección espere por su respuesta, pero es una eternidad para un robot spammer ;)... además, me gusta el número 8 :p

Referencias:

Último Minuto: Mi Amigo Christian Aguilera me comentó que en la implementación del Tar Pitting de Exchange 2007, el retraso tiene una "Duración Aleatoria". Con esto se persigue engañar a los robots de spam, para que así no logren detectar que existe un mecanismo de Tar Pitting configurado en nuestro servidor. Esta es una de las ventajas que Exchange 2007 traiga su propio servicio SMTP (y ya no use el servicio SMTP del IIS).
Si quieren conocer más sobre Exchange 2007, les recomiendo los sitios de:

Gonzalo

Códigos de Respuesta de un Servidor SMTP

Tue, 14 Aug 2007 05:14:07 GMT

Te has visto alguna vez en una situación como esta?

Usuario: (te llama y te dice:) "Hola. sabes, no puedo enviar un correo".
ADMIN: OK, me podría decir por favor qué mensaje de error le aparece en la pantalla?
Usuario: "Si, aquí dice: su mensaje no se ... ha podido entregar... código del error: 5.2.3. Qué puede ser?".
ADMIN: ???? (Este tipo cree que me sé TODOS los códigos de error de memoria o qué?!).

Bueno, al menos yo sí .. un par de veces.... y no me sé los mensajes de error de memoria, pero... al menos sé donde encontrarlos :D

KB284204: Notificaciones del estado de entrega en Exchange Server y Small Business Server

Espero que les sirva.

Gonzalo

PS: Cualquier relación o parecido con las historias del BOFH es completamente intencional ;)

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

Mon, 13 Aug 2007 03:12:56 GMT

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 Relay 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 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 debiesemos 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 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).

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.

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

Mon, 13 Aug 2007 01:52:42 GMT

En un artículo anterior aprendimos cómo enviar un correo electrónico a mano, es decir, utilizando sólamente 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 derechamente las exigen, como veremos 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:

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.

Nota: algunos sistemas verifican que nososotros 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, ya sabemos lo que significa ;), y nuestro decodificador de base64 nos dice que "UGFzc3dvcmQ6" es simplemente 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.

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 estabamos 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

4. Enviamos el Cuerpo del Mensaje. Usamos el comando DATA. Dentro del cuerpo del mensaje es muy recomendable incluir un nombre de destintario (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.

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

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

Sat, 11 Aug 2007 23:58:02 GMT

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 Outllook 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:

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).

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.

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").

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.

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

Notas desde el Mundo Real: Exchange Server

Soporte para Exchange Server en Entornos Virtualizados

iPhone se pone pantalones largos (en su versión 2.0)

Cómo ver Calendarios de Google en Outlook

IMPORTANTE: Extensión del Horario de Verano

Antispam: Cómo Habilitar el Filtrado de Conexión usando Listas Negras en Nuestro Servidor Exchange 2003? Parte 1

Cosas que siempre quisiste saber sobre el correo electrónico y que nunca te atreviste a preguntar

Cosas que siempre quisiste saber sobre el correo electrónico y nunca te atreviste a preguntar (Parte 1)

Índice de la serie Básicos

Relay Bueno: Permitiendo Relay en Exchange 2000/2003

SPAM.PDF y SPAM.XLS

Cómo Redirigir un correo a más de un destinatario externo con Exchange Server 200X?

Haciéndole la vida difícil a los Spammers: SMTP Tar Pitting (Pozo de Brea)

Códigos de Respuesta de un Servidor SMTP

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

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

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