Archivo de la etiqueta: email

Comprobar disponibilidad de websites con PowerShell

En ocasiones, para un administrador de sistemas, resulta imprescindible saber si un determinado sitio web está levantado o no. Esta necesidad aumenta aún más, si cabe, si el administrador tiene a su cargo una elevada cantidad de sitios que monitorizar. Una solución rápida puede ser, por ejemplo, lanzar un comando ping para saber si un servidor responde a una cierta dirección. Pero esto no nos da información sobre si una cierta URL está activa o funcionando correctamente.

Para este tipo de situaciones, hace falta hacer procesamiento a un nivel más alto que simplemente “comprobar que la máquina responde”. Y aquí es donde PowerShell viene a ayudar, automatizando el proceso y proporcionando acceso a funciones de alto nivel que proporcionan información adicional.

El Código

Paso a paso…

En primer lugar, nos pide las credenciales de nuestra cuenta de correo. En este caso, las de un servidor de correo ficticio llamado “unsmtp.plainconcepts.com”. Para los que tengan Office365, también funciona con estas credenciales.

credentials

A continuación, se crea un array vacío en el que se van a guardar una serie de objetos a partir del cual se generará un informe. Justo después se define un array de URLs en el que se tiene una serie de sitios web a consultar. Importar la lista de URLs desde un archivo CSV es mucho más conveniente, pero a efectos de script demo, se decidió prescindir de esa parte para que el script funcione “tal cual” sin dependencia de otros archivos.

Para cada elemento de la lista de URIs, se hace una llamada al sitio web con invoke-webRequest. Esto hace que PowerShell conecte con el sitio web, en caso de éxito, nos muestra en pantalla un mensaje “el host está online”, y guarda un objeto en el listado con el que se va a generar el informe. En caso de error se captura la excepción correspondiente y se discrimina por código de error, siendo los más interesantes son el 404 y el 500. Si se desea completar el script, se puede consultar la lista completa de códigos de estado HTTP y añadir los manejadores que se considere necesarios.

psOutput

En penúltimo lugar, una vez procesados todos los elementos de la lista de sitios, toca procesar el listado de objetos para generar un informe de estado en formato CSV. Este informe se guarda en la carpeta temporal del usuario, donde no moleste.

Finalmente, se envía por correo con send-mailMessage. Se puede enviar al propio usuario, o adjuntar una copia a otra persona.

email

informePreview

Conclusión

Como se puede ver, las partes más importantes de este script son la consulta a cada URL, que posibilita obtener información detallada del estado de cada una, y el envío del informe de estado en formato CSV por correo electrónico. Este script se puede añadir a una tarea programada que se ejecute diariamente (en caso de necesitar un informe diario), o modificarlo para que la tarea programada se pueda ejecutar con mayor frecuencia, pero modificando la parte de envío de informe por correo electrónico, para que el informe sólo se genere con los hosts que tengan problemas, y el email sólo se envíe cuando se genere el archivo CSV de informe.

¡Las posibilidades son ilimitadas!

Comandos útiles en Powershell

Me gustaría hablar en este post de algunos comandos que, ya sea por necesidad o simplemente por curiosidad, uno se va encontrando por el camino. Son los siguientes:

Envío de mensajes de correo con archivos adjuntos (solo para Powershell v5)
Una funcionalidad interesante es la posibilidad de que un script pueda enviar un mensaje de correo electrónico con uno o más archivos adjuntos.
Cabe destacar que este cmdlet solo está disponible para Powershell v5. Los parámetros básicos que hay que indicarle son bastante intuitivos:

 

Creación de un trabajo o job en el planificador de tareas
Si bien esto se puede realizar directamente con el interfaz gráfico del propio planificador de tareas, la posibilidad de creación o eliminación dinámica de un job mediante Powershell puede ser bastante útil, sobre todo en el caso de integrarla en un script.
La ejecución de un job requiere de cuatro elementos principales:
a) El elemento que se va a lanzar, que puede ser un ejecutable, un batch o un script.
b) Los argumentos que empleará dicho elemento, separados por comas.
c) El disparador o ‘trigger’, evento que actúa de detonante en la ejecución del job. Por ejemplo, una hora concreta de un dia determinado.
d) Las opciones adicionales del propio job.

Algo a señalar es que, si hay que eliminar un job existente y éste ha sido creado con el anterior comando, es recomendable hacerlo con este otro:

ya que si bien es posible hacerlo con el interfaz gráfico del planificador de tareas, posteriormente al utilizar comandos Powershell relacionados con esto, por ejemplo Get-ScheduledJob, se puede producir un mensaje de error.

Alerta sonora
Un complemento a una alerta visual (como un mensaje o aviso), puede ser la emisión de algún tipo de sonido. Esto puede ser interesante a la hora de introducir algún tipo de alerta sonora para indicar algún evento relevante, como por ejemplo que se ha encontrado algo o la misma finalización de un script.

En su forma más simple, se puede indicar el código de control correspondiente a la alerta, mediante el siguiente comando:

Esto puede servir para indicar un tipo de evento, pero es bastante limitado. Sin embargo, es posible reproducir sonidos del sistema o incluso archivos con extensión .wav. No hace falta decir que esta última forma es que la que gana en versatilidad al resto

 

Uso de un puerto serie
Aunque de por sí el puerto serie en sí puede estar en desuso, sin embargo nunca ha dejado de utilizarse. Así, por ejemplo, se emplea para comunicarse con microcontroladores diversos. La conexión se puede llevar a cabo mediante una conexión física y empleando, al menos, las tres señales mínimas (TxD, RxD, GND) sin control de flujo, o incluso una conexión inalámbrica empleando Bluetooth. Bluetooth suporta múltiples perfiles, y uno de ellos es el SPP (Serial Profile Port), el cual a efectos prácticos lo hace comportarse como un puerto serie estándar.

 

Y esto es todo por ahora. Espero que alguien pueda sacar provecho de alguno de estos cmdlet para dotar de más funcionalidad a algún script de Powershell.

Envio de correo desde FIM (Conector de WebServices)

Hola a todos, hoy vamos a tratar un tema radicalmente distinto a mi habitual post de PowerShell. En este caso, vamos a hablar del conector de Web Services para FIM, y cómo se puede añadir un flujo para que envíe correo. En primer lugar, y a grosso modo, hablemos de FIM:

 Brevísima introducción a FIM

Forefront Identity Manager, FIM para los amigos,  es un gestor de Identidad. Su última versión ha sido renombrada como Microsoft Identity Manager (MIM), que en el futuro recibirá nuevos artículos en este blog. La parte más importante del producto es el Synchronization Service (FIM Sync), aunque también dispone de una funcionalidad llamada FIM Portal (basado en Sharepoint) que ayuda a simplificar algunas tareas de gestión. Su función consiste en sincronizar la identidad de los usuarios a través de muy diversos entornos. Dicho así suena a que es algo muy fácil, pero en realidad, la gestión de identidad puede suponer un dolor de cabeza muy serio en cuanto tenemos más de una única fuente de datos en la que se encuentre la identidad de los usuarios.

Vamos por partes: Entendemos por identidad como la esencia que identifica de forma inequívoca a una persona. En el caso de Active Directory, la identidad de una persona coincide con su cuenta de usuario. Pero ¿Qué sucede si lo que se tiene de esa persona es una tabla en una base de datos de Recursos Humanos? En muchos casos, lo que se hace es enviar un correo electrónico con los datos de dicha persona (su identidad) al administrador de Active Directory, quien procede al alta de dicha persona. En ocasiones, se ha automatizado el proceso, de forma que dar de alta a una persona en la BBDD de Recursos Humanos automáticamente crea una cuenta en Active Directory.

Ahora bien, ¿Qué sucede si con el paso del tiempo, el usuario notifica al administrador de Active Directory que ha cambiado su domicilio, pero no lo notifica a Recursos Humanos? O bien el administrador se encarga de decirle al responsable de RRHH que hay que cambiar el domicilio, o bien… siempre cabe la posibilidad de que el domicilio se quede sin cambiar.
La situación se complica, si además hay que gestionar la identidad del usuario en más de uno o dos sistemas diferentes. Máxime si uno de los sistemas es además un sistema personalizado propio y exclusivo de la empresa.

Forefront Identity Manager entra para poner un poco de orden en todo este caos de identidad. FIM, como herramienta, posee una base de datos llamada “Metaverso”, en la que va a guardar metadatos de todas las fuentes de identidad configuradas, y se encarga de poner en orden todo ello, asignando los datos correctos a la identidad (única e irrepetible) de una persona. Pero no sólo actúa de repositorio y almacén central de datos, adquiridos mediante conectores de muy diversa naturaleza. Sino que además, actúa como sincronizador, y se encarga de distribuir los cambios que se realicen a la entidad “usuario” a todos los sistemas afectados, de forma que los datos de dicho usuario Siempre estén en sincronía.

Para poder hacer esto, FIM proporciona una serie muy amplia de conectores, llamados Management Agents, que se pueden conectar a infinidad de orígenes de identidad, como puede ser Active Directory, Microsoft SQL Server, tablas en una Base de Datos, líneas en un archivo CSV…. la variedad es inmensa. Pero pese a la gran variedad de conectores disponibles, siempre queda la posibilidad de que una empresa esté usando un sistema de gestión de identidad propio… que debe ser sincronizado con otros sistemas. Un ejemplo, puede ser una aplicación personalizada de gestión de recursos humanos.

Para este tipo de sistemas, FIM proporciona herramientas que permiten la creación/desarrollo de nuevos Management Agent, ya sea el conector ECMA 2.0, o el conector basado en WebServices.

De los dos, a priori, el que parece más sencillo de usar, pero al mismo tiempo aparenta ser el más limitado, es el conector de WebServices. Pero eso es sólo en la superficie. Ya que al profundizar en él, no es tan sencillo de utilizar ni tampoco es tan limitado como parece. Así pues, y tras esta larga introducción ¿qué mejor forma de mostrar su potencia, que mostrando un pequeño snippet que nos permite enviar un correo desde FIM?

 Prerrequisitos

Para poder replicar el contenido de este post, es necesario más trabajo del habitual. La versión de FIM sobre la que se ha trabajado es FIM 2010 R2. Como requisito base, se va a necesitar un Active Directory, así que es necesario tener un laboratorio de AD con al menos un DC. También es necesario tener un Microsoft SQL Server instalado y configurado (aunque puede estar funcionando en la misma máquina donde se despliegue FIM Sync). La buena noticia, es que en ambos casos, tanto SQL Server (2008/2012) como FIM 2010R2 tienen una trial de 180 días, así que es posible desplegarlos sin preocupaciones, que nos van a durar casi 6 meses. Finalmente, y dado que se usa el conector de web services, es buena idea tener una máquina adicional con IIS en la que se despliegue un web service. Y ya puestos a pedir, también viene bien tener un Visual Studio con el que desarrollar el web service (por simplicidad), aunque es perfectamente posible implementar un web Service SOAP que se pueda usar en Apache y PHP.

Pregunta del millón: Si se va a utilizar FIM y el conector de Web Services para enviar correo, ¿realmente es necesario montar un servidor con un webservice (por muy simple que sea) para que todo esto funcione? La respuesta es . FIM va a comprobar que el conector tiene definido un web service y un tipo de objeto que va a leer en sus operaciones. Así que si no existen ni el objeto ni el servidor del que lo va a leer… no se va a poder crear el conector en el cliente de FIM Sync.

EstructuraServidoresEn definitiva, se necesita tener al menos tres máquinas virtuales en un laboratorio de AD: Domain Controller, un Servidor Web, y la máquina de FIM (que simultáneamente hospeda SQL Server). Esta configuración FIM-SQL_Server no es la aconsejada para despliegues físicos, pero en cambio, ésta es la configuración recomendada si se va a desplegar un servicio de FIM Sync en Azure

Conector de WebServices

Este conector está basado en Windows Workflow Foundation (WWF). Bueno, en un subconjunto de WWF, para ser más precisos. Esto de entrada ya parece un limitante, pero con suficientes dosis de creatividad, es posible hacer casi de todo.

Para poder trabajar con este conector, se utiliza un editor llamado “Web Service Configuration Tool“, absolutamente minimalista, pero que cumple con su cometido a la perfección. De entrada, se puede ver que hay tres secciones bien diferenciadas: Discovery, Object Types y Test Connection.

interface

  • Discovery es la sección donde se puede editar y añadir nuevos Web Services, en este caso basados en SOAP, aunque instalando una actualización también es posible usar servicios REST.
  • Object Types es la sección donde se definen los objetos que se van a sincronizar con FIM. Cuando se configura, aparecen las opciones para añadir el código WWF que va a gestionar las operaciones de Full Import, Delta Import, y Export (delete-add-replace) relacionadas con ese objeto. Estos objetos, se proyectan directamente en el metaverso de FIM a la hora de crear el Management Agent, así que es seguro decir que hay total libertad a la hora de definir los Object Type.
  • Finalmente, la sección Test Connection es la que vamos a usar en este post.

Obviamente, las cosas no son tan sencillas como decir “vamos a hacer un test de envío de correo” y listo. En este caso, para poder hacer el test, FIM hace comprobaciones sobre los archivos de configuración creados con la herramienta. Se fija en detalles tan insignificantes como que la herramienta se va a conectar a un Web Service SOAP existente, o que los datos que devuelve el Web Service son compatibles con un Object Type detallado previamente, etc. Por eso es necesario contar con una máquina adicional que

Cómo crear un Web Service en Visual Studio, e instalarlo en un servidor IIS adicional para que FIM pueda leerlo, es un tema aparte que merece un mini-post para detallarlo. Simplemente decir, que para que todo esto pueda funcionar con el Web Service Configuration Tool en modo SOAP, es necesario tener un web service accesible, y que haya sido configurado en la herramienta, de forma que pueda pasar las validaciones de FIM Sync. Para ello, simplemente acudimos a la sección de Discovery, y añadimos un nuevo servicio, con tipo de tipo de credencial none y con modo de seguridad none. Al fin y al cabo, es un servicio de pruebas, y no es necesario complicarse aún más con modelos de autenticación.

nuevoServicioSOAP

A continuación añadimos un objeto, para que las validaciones de FIM no se quejen y nos digan que el conector no es válido. Sumamente sencillo y rápido, que lo importante no es crear el objeto en el configurador

objetoMetaverso

Ahora que ya está todo preparado (Active directory, despliegue de máquinas, servicio web…) vamos a lo importante: cómo enviar correo.

Envío de Correo: Uso de la sección Test Connection

Con todo ya preparado, ¡toca ponerse manos a la obra! Tenemos el Web Service Configuration Tool, así que toca empezar a mover componentes. Como estamos trabajando con Windows Workflow Foundation, todo va a ser bastante visual, y sobre todo, hay que tener en cuenta que el código se incrusta dentro de bloques denominados secuencias.

Lo primero: Definir las variables que necesitamos para desarrollar el proyecto.

vars

El editor de configuración, dispone de tres secciones interesantes en la parte inferior de la ventana de edición de código: Variables, Arguments, Imports. Para el uso que importa en este artículo, sólo se va a hacer uso de la sección “Variables”, en la que definimos las variables que se van a utilizar. Es importante señalar dos apartados de esta sección: Scope que indica el ámbito de la variable, dentro de una secuencia, y Variable Type, que es donde definimos el tipo de las variables. En Variable Type, se muestra una serie de tipos predefinidos aunque, y aquí entra la magia, es posible buscar cualquier clase presente en el .NET framework para utilizarla como tipo de variable.

advancedTypes_WSConnectorEstablecer que las variables estén en el scope “sequence” (el top-level) es el equivalente a definirlas como variables globales que estarán disponibles para todas las secuencias que se creen dentro de la secuencia padre.

A continuación, es necesario definir la estructura de lo que es necesario para enviar un correo. Los pasos básicos. Esto lo vemos en la siguiente captura de pantalla:

overView Tenemos una Secuencia, que es el cuerpo principal del programa en WWF que se va a “escribir” en la sección de “Test Connection”. En esta secuencia, se añade una nueva secuencia, y se la llama “SendMail”. Una secuencia equivale conceptualmente a una función. Es una agrupación de elementos, que se puede plegar y desplegar a voluntad para ocultar sus contenidos. En este caso, la secuencia SendMail tiene tres partes: Una que es el cuerpo del Mensaje, que se define asignando un valor a una variable, otra sección que es “configurar Servidor SMTP”, y una última sección que es “Enviar Mail”. Estas secciones se despliegan a continuación para mostrar sus contenidos.

configurarSMTP

En la secuencia de “Configurar Servidor SMTP”, lo que se hace es configurar el objeto del tipo SMTPClient que se definió al principio del proceso. Para mejorar la claridad de lo que se hace, hemos renombrado las acciones del tipo “assign” para que su descripción muestre la ruta completa de variables que se está asignando. Convenientemente, las credenciales para conectar al servidor SMTP quedan oscurecidas dentro del textbox en el que están escritas, pero para que lo tengamos claro, son un objeto del tipo Net.NetworkCredentials. Para simplificar aún más, indicamos que el cuerpo del mensaje no es HTML.

A continuación, desplegamos la segunda secuencia “Enviar Mail”

enviarMail

 

En este caso, se establece la dirección de envío (mailMessage.From = New System.Net.MailAddress(fromMailAddress)), y aquí viene lo potente: El componente de WWF “InvokeMethod”, que permite ejecutar un método de una clase que haya sido instanciada en un objeto. En este caso, se añade la dirección a la que se quiere enviar a la lista de destinatarios. Es necesario usarlo, ya que internamente es una lista, y los correos destino se deben añadir uno a uno. Se define el Subject del mensaje, se define el Body del mensaje, y se vuelve a usar un InvokeMethod para, esta vez sí, hacer que el objeto SMTPClient (instanciado como smtpService) se encargue de enviar el correo electrónico que hemos definido.

anadirDestinatario

Finalmente, si queremos que FIM se entere de que todo ha terminado con éxito, toca añadir al final de la secuencia la siguiente asignación:

resultTrue

Con esto, hemos definido la configuración del conector de Web Services. Pero todo esto, por sí solo, no hace absolutamente nada. Es necesario Crear un Management Agent del conector de Web Services en FIM Sync, e indicarle que use este archivo de configuración. Para ello, lo más importante es copiar el archivo de configuración a una carpeta muy concreta, de lo contrario, FIM Sync no será consciente de su existencia.

url

 

Finalmente, con el archivo de configuración copiado en la carpeta de Extensiones, se puede proceder a crear el Management Agent. Para ello, se abre el Synchronization Service Manager on FIM, y se acude a la sección “Management Agents”, seleccionamos “Create”, y nos encontramos con esto:

creandoMA

Se selecciona que el Management Agent que se desea crear es el de “Web Service (Microsoft)”, se le pone un nombre, y se pulsa “Next”, esto nos lleva a la pantalla de configuración de conexión del MA.

creandoMA.2

En esta sección, es importante elegir el proyecto del configurador del conector que hemos creado, y el Host y el puerto que hemos definido en el proyecto, así como la misma configuración en el modo de seguridad y el tipo de credencial de cliente. FIM va a validar todo esto, y en caso de que haya algún error no va a dejar que continuemos bajo ningún concepto.

Una vez  todo está validado, FIM pasa a la siguiente pantalla “Global Parameters”, en la que aparece un único checkbox disponible:

creandoMA.3¡¡¡¡ “Test Connection” !!!! Marcando este checkbox, FIM va a ejecutar el código que hemos creado anteriormente en el apartado “Test Connection”, que existe única y específicamente para ser ejecutado en este instante. Esto es muy útil para probar partes del código del conector de Web Services, ya que se pueden ejecutar sin ningún tipo de compromiso, y en caso de que todo haya funcionado bien, lo sabremos gracias a la sección “Result = true” que añadimos al final del código. Para pruebas más complejas, es muy útil no devolver ningún valor de Result (por defecto es false), o cambiarlo a False en caso de que algún tipo de validación no se haya ejecutado como se espera.

Es la hora de la verdad: En cuanto se pulse “Next”, teniendo el checkbox marcado, FIM va a compilar el conector de Web Service, y va a ejecutar la sección de “Test Connection”. En caso de que todo salga bien, se enviará un correo electrónico a la dirección deseada, y el cuadro de diálogo para crear un Management Agent pasará a la siguiente sección “Configure Partitions and Hierarchies”. Pero todo ello ya no pertenece al ámbito de este post.

En cambio, lo que sí pertenece, es la última captura de pantalla…

correoFIM

Finalmente, ¡los correos han llegado a su destino!

 

Conclusión

En este artículo se ha compartido un fragmento de código para el conector de Web Services, que es muy útil a la hora de diagnosticar problemas en casos de importaciones masivas. Por ejemplo, si hay que sincronizar medio millón de usuarios, eso es un proceso que puede tomar varios días de proceso para el conector. En caso de que hubiese algún tipo de problemas, un sistema de alertas por email que indique que algo está pasando es vital para ayudar a actuar de inmediato, corrigiendo la situación que esté dando problemas en el lado servidor antes de vernos forzados a interrumpir el proceso. Cualquier interrupción de una operación de full Import puede suponer días de espera, ya que es una operación que no puede ser reiniciada.

En definitiva, una herramienta útil para desarrollos más complejos utilizando el conector de Web Services.

¡Hasta la próxima!

Exportar e importar firmas de correo electrónico en Microsoft Outlook

¡Feliz Año Nuevo a todos! 2014 ha sido un año cargado de retos y exploraciones de nuevas tecnologías, además de ser el año que iniciamos andadura en el blog del equipo de Enterprise IT de Plain Concepts. ¡Esperamos disfrutaseis del 2014 tanto como nosotros y que el 2015 empiece para todos con las pilas cargadas!

Mi primer post del año no es muy técnico, pero sí pienso que tremendamente útil. Como usuario y administrador de Office 365 no es ninguna sorpresa que mi correo esté basado en Exchange Online y que acceda a él habitualmente utilizando Outlook 2013. Algo que siempre he lamentado profundamente es que Outlook almacene las firmas de los correos electrónicos en local y no en el servidor de Exchange. Este hecho conlleva problemas bastante obvios:

  • Si reinstalo mi PC, necesito volver escribir o –en el mejor caso- copiar y pegar las firmas de mis cuentas de correo.
  • Si adquiero un nuevo equipo, debo realizar la misma operación que en el punto anterior.
  • Si tengo un parque de 3-4 equipos (como es mi caso), es frecuente que no todos tengan las firmas sincronizadas.
  • Yo uso 2 firmas –una para mensajes nuevos y otra para respuestas- para cada dirección de correo. Con 3 direcciones de correo me junto con 6 firmas.

Mientras esta ansiada característica de Exchange llega o no, he creado un par de sencillos archivos de procesamiento por lotes (BAT) que se encargan de exportar todas firmas de nuestro Outlook y de importarlas de vuelta al mismo. Combinando estos scripts con algún servicio de sincronización como Dropbox o OneDrive, tenemos toda la magia que necesitamos.

Script para exportar firmas de Outlook

Como podéis ver, es realmente sencillo. En primer lugar nos vamos a apoyar en algún programa de archivado de ficheros. 7-Zip es nuestra primera elección por se gratuito, open source, poder trabajar con formato ZIP y tener una potente versión de línea de comandos. Otras alternativas serían TAR, RAR, LZH o cualquier otro.

El script básicamente:

  1. Guarda en la variable ZIP la ruta de instalación de 7-Zip, para poder hacer uso del mismo. La expuesta es la más habitual. Modificar en cada caso.
  2. Guarda en la variable SIGFILE el archivo que vamos a generar tras exportar las firmas.
  3. Como Outlook guarda las firmas en carpetas distintas dependiendo del idioma que estemos utilizando, utilizamos los IF y la variable FOLDER para establecer el lugar donde Outlook almacena los archivos que nos interesan.
  4. Si existe otro archivo anteriormente generado lo eliminamos.
  5. Llamamos a 7-Zip para que genere un empaquetado de los contenidos del directorio. Con el “a” decimos que queremos crear un archivo y agregar contenido, –tzip para utilizar el formato ZIP y –r para recorrer todos los subdirectorios.

Script para importar firmas de Outlook

Muy similar al anterior, sólo cambia en el comando 7-Zip donde ahora le especificamos que vamos a extraer los contenidos del empaquetado. Tras realizar esta acción nuestras firmas aparecerán para seleccionar y configurar mágicamente en nuestro Outlook.

Si almacenamos estos dos scripts en una carpeta de Dropbox, OneDrive o nuestro servicio de sincronización, operar con ellos será sencillo.

  • Ejecutar backup_outlook_sigs.bat desde el equipo del que queramos extraer las firmas.
  • Ejecutar restore_outlook_sigs.bat desde todos los equipos en los que queramos importar las firmas extraídas.

Espero que estos scripts os permitan ahorrar tiempo poniendo a punto vuestros nuevos sistemas.

Happy signing!

UPDATE: José Ángel Fernández nos ha sugerido una versión equivalente del script en PowerShell que tiene la peculiaridada de no necesitar ninguna herramienta de archivado externa, pues se vale del ZIP que se encuentra en la propia API de Windows:

Asegura la legitimidad de tu email con los registros SPF

Los que nos dedicamos a la mensajería y la colaboración tenemos bien presente que el SPAM y el phishing son dos de los grandes enemigos a los que debemos enfrentarnos, dos tipos de amenzadas que tienen el denominador común de la legitimidad del email, entendiendo por email legítimo aquél que se ha generado por parte de una persona al cargo de un buzón que se encuentra en el dominio del remitente que indica.

Desde hace ya más de una década hay esfuerzos más o menos coordinados para luchar contra el correo basura a través de múltiples estrategias entre las que podemos comentar:

  • Crear listas negras que incluyan servidores SMTP que se encuentren configurados como open relay,una configuración que permite que un tercero pueda utilizar esa máquina para enviar correo usando a su vez identidades falsas.
  • Establecer una regulación de las listas de distribución y correos masivos por parte de organizaciones e individuales que garantice que la recepción de dichos mensajes es autorizada por parte de sus correspondientes destinatarios, que a su vez pueden anular su suscripción en cualquier momento.

Sin embargo, las distintas estrategias planteadas con anterioridad no han sido suficientemente prácticas para erradicar completamente estas malas prácticas. Es por ello que en este artículo os vamos a hablar del Sender Policy Framework (SPF), que es una solución eficaz a estos problemas a medida que se va implementando cada vez más en los servidores SMTP de todo el mundo.

El SPF es un sistema de validación de email extremadamente sencillo que se apoya en la infraestructura DNS de las distintas organizaciones. El concepto es bien sencillo: a través de nuestro DNS vamos a declarar qué servidores están autorizados a enviar email a nombre de los dominios que tenemos en nuestra propiedadComo la información de los DNS es pública, cualquier sistema SMTP puede consultarla para cotejar si el servidor desde el que el correo electrónico ha sido enviado figura como autorizado por el listado.

La sintaxis y la forma de operar con el registro es bien sencilla. Veamos un ejemplo real con el SPF de Plain Concepts:

Sin ser demasiado expertos podemos ver una serie de IPs declaradas. En efecto, todas ellas constituyen direcciones que potencialmente pueden tener la capacidad de enviar correos electrónicos a nombre de plainconcepts.com y que nosotros estamos declarando como legítimas.

¿Cómo construimos un buen SPF para nuestro dominio?

La sintaxis es tremendamente sencilla. El concepto clave es: si el mensaje no está gestionado o enviado por cualquiera de las cosas que declaremos, entonces especificamos una política por defecto. Para ello, seguimos los siguientes pasos para… imaginemos el dominio cantoso.com:

  1. Creamos un nuevo registro TXT en cantoso.com. Si quisiéramos declarar SPF en subdominios, deberemos crear una entrada por cada uno de ellos.
  2. El valor del registro debe comenzar por v=spf1 donde especificamos que vamos a declarar un SPF y su versión.
  3. Lista de máquina autorizadas a enviar correo en nombre de nuestro dominio. Para ello podemos usar las siguientes palabras clave:
    • A: si vamos a declarar un nombre declarado como registro A ó AAAA. Ejemplo: a:mail.plainconcepts.com
    • IP4: si vamos a declarar una dirección IPv4 o un rango. Ejemplo: ip4:2.212.170.67 ó ip4:192.168.0.0/24
    • IP6: similar al anterior, pero usando direcciones o rangos IPv6.
    • MX: si vamos a usar una resolución de registro MX. Ejemplo: mx:plainconcepts.com.
    • INCLUDE:  que utilizaremos si vamos a usar las políticas SPF declaradas en otro dominio, muy usada en entornos cloud. Ejemplo: include:spf.protection.outlook.com.
    • ALL: esta palabra clave hace match con todo.
    • La palabras clave A, MX, e INCLUDE implican resolución de nombres DNS. SPF limita a 10 consultas DNS, por lo que debemos tener cuidado de no abusar de los registros que hacen uso de ellas.
  4. Cerramos nuestra cadena con -all. Usando -all especifica que todo lo que no haya cumplido con los elementos anteriores, fallará la validación SPF. Una alternativa común es usar ~all que nos indica que los mensajes serán aceptados pero etiquetados.

Así, volvamos a echar un vistazo a la cadena de plainconcepts.com y el significado de cada elemento:

Examinemos los elementos:

  • v=spf1 es la declaración del registro SPF.
  • include:spf.protection.outlook.com deriva de nuestro uso de Office 365, por lo que incluimos sus servidores SMTP como autorizados para nuestro dominio.
  • include:sendgrid.net es similar al anterior, pero relativo a los servicios de SendGrid.
  • ip4: todas estas entradas están autorizadas a enviar correo en nuestro nombre.
  • -all: si la dirección IP del remitente no entra dentro de ninguna de las reglas anteriores, especificamos que la validación falla.

¿Sólo con establecer este registro estamos protegidos?

Lamentablemente no, aunque hemos hecho la parte que nos toca en relación a la declaración del SPF. El registro como tal sólo proporciona información a los MTA y es decisión de cada uno hacer validación mediante este mecanismo o no.

Si un servidor SMTP usa SPF, su flujo sería parecido al siguiente:

  1. mail.plainconcepts.com recibe un email de jorge@cantoso.com desde la IP 193.153.214.55.
  2. mail.plainconcepts.com coteja la IP 193.153.214.55 con el SPF declarado por cantoso.com, que resulta ser “v=spf1 ip4:2.213.33.45 -all”.
  3. La IP no coincide con ninguna de las declaradas y la validación falla.
  4. mail.plainconcepts.com considera el correo ilegítimo y lo marca como tal.

Si jorge@cantoso.com envía un email a paco@fabrikam.comFabrikam no implementa validación SPF, de poco sirve a cantoso.com tener publicada esa información en el DNS para ese caso concreto.

¿Cómo activo el SPF en Office 365?

Por defecto Office 365 tiene DESACTIVADA la validación SPF. Sin embargo, activarlo es un proceso realmente sencillo:

  1. Iniciamos la sesión como administrador de Exchange Online.
  2. Vamos a Protección -> Filtro de contenido.
    spf1
  3. Seleccionamos la política por defecto y la editamos.
  4. Nos dirigimos a Opciones avanzadas -> Registro SPF: error
    spf2
  5. A partir de este momento Office 365 empieza a realizar validaciones SPF.

Espero que este artículo os haya servido para aprender una forma sencilla y eficaz de proteger y legitimar tanto la identidad de vuestro correo electrónico saliente, como de aquellos mensajes entrantes que pasan por vuestras estafetas SMTP.

Happy mailing!

Enlace relacionado: RFC 7208 – Sender Policy Framework
Enlace relacionado: SPF – Wikipedia