Cuentas de correo de “usar y tirar” o de un solo uso

correo Los correos electrónicos de un sólo uso son una gran herramienta para evitar el spam. Cuando queremos probar o evaluar un servicio para el que nos exigen una cuenta de correo electrónico y la evaluación no se hace efectiva mientras que no validemos dicha cuenta (por regla general haciendo click en un link que recibimos en la misma) lo más cómodo y práctico es recurrir a una de estas cuentas. Tienen, por supuesto, otros usos, pero mejor no te doy ideas por si acaso… 😉
Este tipo de correos tienen también una parte negativa, no lo olvides: la privacidad de lo que recibes en ellos es nula, puede que no puedas volver a usarlos en el futuro para recuperar la contraseña del servicio o, por el contrario, puede que alguien que no seas tu “suplante” tu personalidad a través de dicho correo y te robe la identidad en el servicio para el que la utilizaste en primer lugar… Así que ten mucho cuidado donde y para que las usas y trata de ser consciente de los riesgos que corres.

Allá por el año 2000 que fue cuando empecé a usar este tipo de cuentas e hice mi primera lista había apenas cinco servicios de este tipo. Ahora tengo listados más de 30. El único que sobrevive de aquellos tiempos es Mailinator…

No te voy a recomendar ninguno. Échales un vistazo por ti mismo. En esta lista encontrarás de todo: servicios con registro, sin él, que destruyen los correos en unos minutos, que los guardan para siempre, que te permiten elegir la cuenta o que la generan de forma aleatoria… Lo dicho, si necesitas algo así busca por ti mismo que es lo que mejor se ciñe a lo que quieres:

Evita que tus correos sean marcados como spam (y II). Registros DMARC

correo Hace un par de meses hablábamos por aquí de como implementar el uso de registros PTR, SPF y DKIM en tu servidor de correo con objeto de que el servidor destinatario de los mismos pudiera comprobar que el servidor remitente es legítimo. Los registros DMARC (Domain-based Message Authentication, Reporting & Conformance) van un paso más allá y dan instrucciones al servidor destinatario de cual debería de ser su forma de proceder (a quién notificarlo, por ejemplo) en caso de sospechar de un uso fraudulento.

MUY IMPORTANTE: No se trata de un método de control que podamos usar de forma aislada. Debe de usarse conjuntamente con DKIM, SPF o ambos puesto que su objetivo, como ya hemos dicho, no es validar la autenticidad del correo sino informar de como proceder en caso de que la validación del mismo a través de uno de los métodos anteriores falle. Así que antes que nada asegúrate de que implementas SPF, DKIM (o mejor ambos) y que funcionan correctamente.

En la página de recursos de la web oficial del estándard existen varios asistentes que te ayudarán a crear un registro DMARC. Por ejemplo este, este o este otro. Como en el caso de DKIM se trata de un registro de tipo TXT que debes de publicar en el DNS de tu dominio. Si pasas de asistentes y quieres hacer tu propio registro a mano puedes echarle un vistazo a esta pequeña guía que publica Google.

A continuación puedes ver un ejemplo del registro DMARC para el dominio micorreo.net en el que se están usando SPF y DKIM como sistemas de validación. Puedes consultar el significado de cada uno de los parámetros aquí:

_dmarc.micorreo.net. IN TXT "v=DMARC1; p=none; rua=mailto:admin@miotrocorreo.net; ruf=mailto:admin@miotrocorreo.net; adkim=r; aspf=r"

El parámetro p indica la política esperada por parte del servidor receptor y el valor none indica que está funcionando en modo monitor (lo más recomendable hasta que le cojas el pulso al protocolo). quarantine y reject son los otros dos posibles valores. El parámetro sirve para indicar la versión de DMARC que usamos. Estos son los dós únicos parámetros obligatorios.

Los dos parámetros que llevan como argumento una dirección de correo electrónico (rua y ruf) sirven para indicar donde recibir, respectivamente, un informe diario (aggregate report) por parte de cada servidor que reciba nuestro correo y realice comprobaciones de los registros DMARC y un informe forense (failure report) por cada correo procedente de tu dominio y rechazado por cualquier servidor que use este método de control.

NOTA: Muy pocos proveedores soportan aún el parámetro ruf. Por ejemplo los servidores de Gmail lo ignoran. No obstante, usarlo no provoca ningún error de validación, así que no está de más incluirlo.

Por último, aspf y adkim indican si el modo de verificación que se realizará del “identifier alignment” con cada uno de estos protocolos es strict (s) o relaxed (r). No sabria como traducir el término de forma correcta (el inglés no es mi fuerte, lo siento), pero tienes una excelente explicación de ambos modos con ejemplos aquí. Para los perezosos, básicamente comprueba que, para SPF, el dominio de las cuentas de origen y de respuesta coinciden (campos From: y Return-path:) y para DKIM, deben de coincidir los dominios de los campos From: y del argumento d= de la firma DKIM.

Existen diversas formas de comprobar que has realizado una configuración correcta. La primera de ellas es, como siempre, enviar un correo a un servicio que implemente esta comprobación (como Gmail) y ver la cabecera del mensaje que recibe el destinatario:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@micorreo.net designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@micorreo.net;
       dkim=pass header.i=@micorreo.net;
       dmarc=pass (p=NONE dis=NONE) header.from=micorreo.net

La segunda opción es enviar un correo a una de las muchos servicios de verificación existente como, por ejemplo, checkmyauth@auth.returnpath.net, mailtest@unlocktheinbox.com o pythentic@had-pilot.biz (a este último con la palabra dmarc en el campo asunto del correo que envíes). Como respuesta recibirás un completo informe sobre las validaciones que tus envíos pasan de forma correcta o inválida. Algunas veces la respuesta puede tardar varias horas, así que ten paciencia. El resultado de la validación de, por ejemplo, este último servicio sería así:

2014/05/28 14:50:10 :Your DMARC record for   '_dmarc.micorreo.net'   is   'v=DMARC1; p=none; rua=mailto:josemaria.morales@gmail.com; ruf=mailto:josemaria.morales@gmail.com; adkim=r; aspf=r'  

Here are the results of the message from josemaria@micorreo.net
received on Wed May 28 14:48:25 2014 with Subject dmarc

The message was: Delivered
The SPF result was: pass
The DKIM result was: True

**********************************************************
Enter your email address and this hash stringin the Review My Results link for message header analysis of results: address=josemaria@micorreo.net  hash=YFXQ3KxaKAsWmAS0HmrN

**********************************************************
Full Record

Id[1]:  
	SPF result: pass 
	DKIM result: True 
	Alignment result: Pass 
	Feedback: RecordType 
	Delivery Result: Pass 
	Source IP: 145.255.98.239 
	User Agent: Pythentic 
	Version: 1 
	Recipient: had-pilot.biz 
	Arrival Date: Wed May 28 14:48:25 2014 
	From: josemaria@micorreo.net 
	DKIM Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=micorreo.net; s=mail;
	t=1401302897; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
	h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From;
	b=Hr4mDbw43WdxyXq93zc5y0FlCJBOuHrxXfJLch6yoYRwqL/aMMcc/YnKD+PI++PDf
	 IDdCXWrUAuNhYEM3nqggrB6gKRvl0d0xxbIhpb/THdj90fq0d2eeyA/P8N5Cj7D+ew
	 dW++rfkwyN2PqI6BKhXPtwkDDc00W1JM3/7hIvf4= 
	Subject: dmarc 
	Reported: 0 
	SPFReason: sender SPF authorized 
	DKIMReason: Good DKIM Signature. 
	DMARCReason: Policy=none; accept. 
	Message: Received: from [192.168.1.5] (125.45.219.87.dynamic.jazztel.es [87.219.45.125])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by invernalia.micorreo.net (Postfix) with ESMTPSA id 1A1A514200B
	for <pythentic@had-pilot.biz>; Wed, 28 May 2014 20:48:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=micorreo.net; s=mail;
	t=1401302897; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
	h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From;
	b=Hr4mDbw43WdxyXq93zc5y0FlCJBOuHrxXfJLch6yoYRwqL/aMMcc/YnKD+PI++PDf
	 IDdCXWrUAuNhYEM3nqggrB6gKRvl0d0xxbIhpb/THdj90fq0d2eeyA/P8N5Cj7D+ew
	 dW++rfkwyN2PqI6BKhXPtwkDDc00W1JM3/7hIvf4=
Message-ID: <53862F70.5030601@micorreo.net>
Date: Wed, 28 May 2014 20:48:16 +0200
From: =?UTF-8?B?Sm9zw6kgTWFyw61hIE1vcmFsZXMgVsOhenF1ZXo=?=
 <josemaria@micorreo.net>
Reply-To: josemaria@micorreo.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: pythentic@had-pilot.biz
Subject: dmarc
References: <5384CED8.4040701@micorreo.net>
In-Reply-To: <5384CED8.4040701@micorreo.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-dkim: d=micorreo.net,s=mail,DKIMReason=Good DKIM Signature.
X-spf: i=145.255.98.239,h=micorreo.net.,s=josemaria@micorreo.net,SPFResult=pass

Por último, existen servicios que validan directamente el registro que has introducido en el DNS dándote, además, una completa explicación de lo que implican los parámetros que has elegido y las alternativas que tienes. Este es mi favorito.

En la dirección que has indicado como valor del argumento rua recibirás un correo electrónico diario por cada servidor al que envíes correo y use la validación DMARC informándote de las validaciones y/o acciones realizadas. En estos correos recibirás un adjunto comprimido en formato zip con un xml en su interior. El contenido de dichos xml es fácil de interpretar pero, si lo deseas, tienes aquí un convertidor a “formato humano” y a continuación un ejemplo del resultado:

Informe Diario XML DMARC

Por cierto: si, como yo, usas un correo de un dominio distinto al que estás validando para recibir los correos con los informes, puede que algún servidor o servicio te de algún error. La solución está en añadir un nuevo registro en el DNS indicando esto. Este segundo registro debería de ir en el DNS del dominio correspondiente a la cuenta de correo donde quieres recibir los informes, ojo, así que deberías de tener control sobre él o, al menos, alguien que te lo permita. Aquí te lo explican muy bien y a continuación tienes el mío:

micorreo.net._report._dmarc.miotrocorreo.net. IN TXT "v=DMARC1"

Ah, y si quieres configurar tu servidor posfix para que realice la comprobación de los registros dmarc en los correos que recibe puedes usar OpenDMARC.

ACTUALIZACIÓN: Y casi se me olvida… En dmarcian tienen un servicio que te permite habilitar una suerte de panel de control para controlar el estado de SPF, DKIM y DMARC en todos los dominios que controles:
ACTUALIZACIÓN (Y II):Chema Alonso ha publicado una entrada en la que hace un repaso bastante sencillo de seguir de SPF, DKIM y DMARC

Evita que tus correos sean marcados como spam usando registros PTR, SPF y DKIM

correoInstalar y configurar un servidor de correo es algo relativamente sencillo y un tema que hemos tratado en alguna ocasión por aquí. También hemos hablado de la forma de reducir el spam que entra en nuestros buzones implementando un sistema de Greylisting. De lo que no hemos hablado aún es de las formas que tenemos de evitar que nuestros correos legítimos acaben abandonados en la carpeta de correo no deseado del destinatario. Algo que cada vez es más frecuente si tienes tu propio servidor de correo personal o de empresa y escribes habitualmente a buzones de los grandes proveedores (Gmail, Hotmail y Yahoo, por ejemplo) que hace tiempo se declararon en guerra abierta contra el spam.

Las técnicas de control de spam usadas más frecuentemente pasan por contrastar la autenticidad del remitente a través de algún tipo de comprobación contra el dominio de procedencia del correo electrónico. Lo que se persigue es que si recibo un correo procedente de una cuenta de determinado dominio, el propietario de dicho dominio debería de tener correctamente identificadas cuales son las máquinas autorizadas para enviar correo en su nombre. Recuerda que lo habitual (e indispensable) es identificar las máquinas receptoras del correo (mediante registros MX), pero muchos administradores aún continúan sin identificar de forma alguna a las emisoras a pesar de que tenemos varias opciones para hacerlo. Veamoslas.

Para ilustrar nuestro ejemplo supondremos que tenemos un servidor de correo que actúa como único emisor autorizado y que también funciona como receptor del correo. Su nombre es estafeta.micorreo.net y su IP la 145.255.98.239. Nuestro servidor es un VPS contratado a una empresa de hosting, que es la que nos proporciona la IP, usará postfix sobre una máquina con Debian 7, estará perfectamente configurado y atenderá a dos dominios diferentes (ya hemos hablado también aquí de como hacerlo) llamados midominio.com y midominio.net

La existencia de un registro PTR de resolución inversa para la IP de la máquina que entrega el correo es una de las primeras cosas que valorará de forma positiva un filtro antispam. El problema que vamos a encontrar con esto es que, habitualmente, no podremos crearlo nosotros mismos. Si la IP fija que usa nuestro servidor nos la ha proporcionado nuestro ISP tendremos que pedírle a ellos que creen este registro para nosotros. Si nuestro servidor de correo está alojado en una empresa de hosting se lo solicitaremos a ellos o, tal vez, nos proporcionarán algún mecanismo para que lo hagamos nosotros mismos a través de su panel de configuración. Si tienes la posibilidad de configurarla por ti mismo en un servidor BIND nuestros buenos amigos de systemadmin te dicen aquí como debes de hacerlo, así que no pierdo más el tiempo en ello 😉 .

Para nuestro ejemplo, pediríamos a la empresa de hosting que nos aloja el servidor (yo así lo hice a Gigas, mi empresa actual de hosting que de de alta un registro de resolución inverso para la IP 145.255.98.239 que se resuelva como estafeta.micorreo.net

Para comprobar si lo han hecho correctamente puedes usar nslookup:

nslookup -query=PTR 145.255.98.239

Los registros SPF (Sender Policy Framework o Marco Normativo de Remitentes) constituyen uno de los métodos más comunes y fáciles de implementar para identificar a las máquinas de nuestro dominio autorizadas para enviar correo electrónico. El método es tan sencillo como dar de alta un nuevo registro en la zona de tu dominio donde identifiques a los servidores que autorizas para enviar correo. Originalmente se usaba un registro TXT pero posteriormente se amplió la funcionalidad de las bases de datos DNS añadiendo un nuevo tipo de registros denominado SPF. Hoy en día es recomendable usar ambos métodos por si acaso el servidor que realiza la validación busca aún el tipo de registros antiguo.

La sintaxis de definición de un registro SPF tiene muchas alternativas y puede variar según nuestras necesidades. En esta entrada tienes la especificación completa muy bien explicada y con todo lujo de detalles. Para nuestro ejemplo (un único servidor de correo tanto para envío como para recepción y que coincide con el que aparece en el registro MX) puedes usar los siguientes registros:

@ IN MX 10 estafeta.micorreo.net.

@ IN TXT "v=spf1 mx ip4:145.255.98.239 ~all"
@ IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
ACTUALIZACIÓN: Los registros de tipo SPF han sido declarados obsoletos, así que elimina la línea número 4 del ejemplo anterior y basta con que dejes la entrada correspondiente al registro TXT para que funcione correctamente.

Puesto que el correo de ambos dominios es gestionado por el mismo servidor debemos repetir esos mismos registros exactamente iguales en las bases de datos de ambas zonas. Y, por supuesto, hacer un reload del servidor bind9 después de hacer los cambios.

Tenemos muchas formas de hacer pruebas si hemos configurado correctamente nuestros resgistros SPF. Una de ellas es usar alguno de los muchos tests online disponibles por ahí. Mis favoritos son estos:

Otra opción es enviar un correo a una cuenta de los grandes proveedores (GMail, Outlook o Yahoo, por ejemplo, comprueban la validez de los registros SPF para valorar si un correo es marcado como SPAM) y observar lo que pone en la cabecera del correo que recibe el destinatario. Ten en cuenta que la validación que hace cada uno de ellos es ligeramente diferente. Por ejemplo, si retiras la partícula ip4 de los registros anteriores Gmail y Yahoo seguirán validando correctamente pero Outlook dejará de hacerlo.

Si, por ejemplo, enviamos un correo a Gmail y no hemos definido aún registros SPF, Google insertará en la cabecera del correo una marca como esta definiéndolo como neutral. Eso quiere decir que no puede determinar si el correo es válido o es spam.

Received-SPF: neutral (google.com: 145.255.98.239 is neither permitted nor denied by best guess record for domain of josemaria@midominio.com) client-ip=145.255.98.239;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 145.255.98.239 is neither permitted nor denied by best guess record for domain of josemaria@midominio.com) smtp.mail=josemaria@midominio.com

Por el contrario, cuando contemos con unos registros SPF correctos la valoración que Google hará constar anunciará que el correo es correcto (pass):

Received-SPF: pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) client-ip=145.255.98.239;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@midominio.com

Si Google recibe un correo de un dominio que usa registros SPF pero el servidor emisor del mismo no está autorizado en estos registros lo marcará como fail o softfail. En el caso de los registros que he puesto como ejemplo lo hará como softfail gracias a la partícula ~all que he especificado (consulta la página de sintaxis que he referenciado antes para entender las diferencias entre ambos).

NOTA: Microsoft propuso hace años una variante de los SPF que denominó Sender ID y que decía corregir alguna de las carencias del protocolo original, pero su empecinamiento en mantener ciertas patentes sobre el mismo impideron que se popularizara su uso. Aquí tienes más información acerca de sus diferencias. Hoy en día lo normal es que si un servidor realiza una comprobación del Sender ID la de por buena si se encuentra un SPF correcto.

El tercer tipo de registros que veremos son los DKIM (DomainKeys Identified Mail), un sistema de identificación que usa firmas realizadas con criptografía de clave pública. El método en el que se basa también es sencillo de entender. Nuestro servidor de correo firmará todos sus mensajes salientes mediante su clave privada y esta firma se incluirá en la cabecera del mensaje en una sección llamada “DKIM-Signature”.

La clave pública deberá de estar disponible para que quien lo quiera pueda realizar la verificación de la firma. Esto se hace en un registro TXT de nuestro DNS. La implementación de este sistema en nuestros servidores es, sin embargo, bastante más complicada ya que necesitamos generar previamente la pareja de claves, configurar nuestro servidor de correo para que realice la firma de los mensajes y, por último, insertar la clave pública en el registro TXT correspondiente de nuestra zona DNS… Vamos a ver como hacerlo.

En primer lugar instalamos los paquetes necesarios:

apt-get install opendkim opendkim-tools

A continuación creamos un directorio para las claves y archivos de configuración. Podemos, por ejemplo, hacerlo en el directorio /etc. En el crearemos un subdirectorio por cada dominio de correo que usamos y tres ficheros adicionales que luego explicaremos como rellenar:

mkdir /etc/opendkim
mkdir /etc/opendkim/midominio.com
mkdir /etc/opendkim/midominio.net
touch KeyTable
touch SigningTable
touch TrustedHosts

Vamos ahora a generar las parejas de claves necesarias para que DKIM funcione. Entramos en el directorio que hemos creado para el primer dominio y ejecutamos lo siguiente:

cd /etc/opendkim/midominio.com
opendkim-genkey -s mail -d midominio.com

El parametro detrás de la -s es el llamado “selector” y el que va detrás de la -d el dominio para el que generas las claves. La instrucción anterior nos generará un par de ficheros: uno llamado mail.private con la clave privada y otro denominado mail.txt que incluye el registro que, con ligeras modificaciones, tendremos que incluir en nuestra zona DNS y que contiene la clave pública. Fíjate en el contenido en bruto de este fichero:

mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB" ; ----- DKIM key mail for midominio.com

Y ahora mira lo que yo he incluido en mi DNS:

_domainkey.midominio.com. IN TXT "o=~; r=josemaria@midominio.com"

mail._domainkey.midominio.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB" ; ----- DKIM key mail for midominio.com

Como ves, he incluido un primer registro TXT denominado _domainkey.midominio.com. (mail es el selector usado al generar la clave y midominio.com. el dominio) cuyo contenido es la política que usaremos (puedes consultar aquí que significa). El segundo registro es el contenido íntegro del fichero mail.txt al que simplemente le he añadido el dominio correspondiente al final del primer campo.

Esta primera parte ya está lista. Ahora tienes que hacer un reload de las zonas de tu servidor DNS (service bind9 reload) y, por último, podrías probar si tienes correctamente configurado estos registros con esta herramienta.

Tenemos aún que dotar de contenido a los tres ficheros que hemos creado inicialmente en el directorio /etc/opendkim. Los dos primeros sirven para seleccionar la clave privada que se usará para la firma en función del correo del remitente.

El fichero KeyTable contendrá una línea por cada pareja de claves que hemos creado. La sintaxis de cada una de estas líneas con arreglo a como hemos realizado el proceso hasta ahora sería así:

keyid dominio:selector:path_a_la_clave_privada

Nosotros usaremos como keyid el mismo nombre de dominio, así que en nuestro ejemplo quedará así:

midominio.com midominio.com:mail:/etc/opendkim/midominio.com/mail.private
midominio.net midominio.net:mail:/etc/opendkim/midominio.net/mail.private

El fichero SigningTable identifica los correos con los keyid del fichero anterior y, por tanto, con la clave privada usada para la firma. La sintaxis de cada línea es esta:

expresion_para_identificar_el_correo keyid

Y en nuestro ejemplo:

*@midominio.com midominio.com
*@midominio.net midominio.net

El último de ellos, TrustedHosts, debería de incluir a los servidores autorizados para usar opendkim. Nosotros tenemos sólo uno pero especificaremos todas sus posibles direcciones y/o identificaciones para evitar problemas:

127.0.0.1
145.255.98.239
invernalia.unlugarenelmundo.es

Muy importante: debemos de asegurarnos que el usuario opendkim y sólo él tiene acceso a estos directorios

chown opendkim:opendkim /etc/opendkim/* -R
chmod go-rwx /etc/opendkim/* -R

Configuramos ahora /etc/opendkim.conf incluyendo o modificando las siguientes líneas (échale un vistazo con detenimiento porque alguna podría aparecer con otros valores distintos a los que aquí ponemos):

Syslog yes
SyslogSuccess yes
LogWhy yes
UMask 002
OversignHeaders From

KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

SignatureAlgorithm rsa-sha256
AutoRestart yes
UserID opendkim:opendkim
Socket inet:8891@localhost

Canonicalization relaxed/simple
Mode s

En el fichero /etc/postfix/main.cf incluimos las siguientes líneas para instruir a postfix de lo que queremos hacer:

#OpenDKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
#smtpd_milters = inet:8891@localhost
non_smtpd_milters = inet:localhost:8891

Por último, reiniciamos los dos servicios en los que hemos hecho cambios:

service opendkim restart
service postfix restart

Puedes comprobar que tu servidor está firmando los mensajes salientes simplemente mirando en la cabecera de los mensajes que hayas enviado (ojo, no vale con mirar esto en la carpeta de enviados de tu cliente de correo: tienes que mirarlo en el buzón de alguién a quién hayas enviado un mensaje 😉 ). Deberías de encontrar una sección como esta:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=midominio.com;
	s=mail; t=1393841181;
	bh=WOdEGJCY/0JhPY8jx68CyFKNQxxdoD1qEPM2Bike+fA=;
	h=Date:From:Reply-To:To:Subject:From;
	b=dtHZW0UMlXcKt6c8IY6DS1IVclv7KZTo6IIK0+r/yLWdKet/G9jkvSxmp7MhTeL9t
	 p5Jh87PMKJD0GuRWIJAKx/QLSVAhf9/scXbR7GH9dRPipwxM4lRzaWwxgyCFfKafca
	 SnBJ81jsaKpQgB8sUi2CY4YWt0Y0Vdy7CKCDbpxA=

Además, también puedes mirar los logs de tu servidor postfix (en /var/log/mail.log):

Mar  3 06:22:05 estafeta opendkim[2738]: 4DA1D14206A: DKIM-Signature header added (s=mail, d=midominio.com)

Para saber que la configuración a la que has llegado es correcta, puedes envíar un correo a gmail y comprobar en la cabecera del mensaje recibido que la autenticación a través de DKIM es correcta:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@midominio.com;
       dkim=pass header.i=@midominio.com

Como con los SPF, te recomiendo que pruebes también con Yahoo, Outlook y otros proveedores para asegurarte de que has llegado a una configuración correcta.

También te pueden resultar útiles las herramientas de DKIM Core para generación o verificación de tus claves.

NOTA: Al igual que ocurría en el caso de los SPF, DKIM también tiene un hermano bastardo llamado DomainKeys que fue impulsado por yahoo! pero que ya nadie más usa… salvo ellos. Si miras en las cabeceras de un correo enviado a yahoo podrás ver que con la configuración que hemos visto aquí valida DKIM como pass y DomainKeys como neutral:

Authentication-Results: mta1040.mail.bf1.yahoo.com  from=midominio.com; domainkeys=neutral (no sig);  from=midominio.com; dkim=pass (ok)

Finalmente, tenemos un mecanismo para realizar una comprobación global de los mecanismos de identificación que nuestro correo es capaz de pasar que consiste en enviar un mail a la dirección check-auth@verifier.port25.com. Como respuesta recibiremos un resumen con los tests de autenticación que pasamos y los que no:

From: auth-results@verifier.port25.com
To: josemaria@midominio.com
Subject: Authentication Report
Message-Id: <1393852132-602016@verifier.port25.com>
Precedence: junk (auto_reply)
In-Reply-To: <53147EDC.1060808@midominio.com>

This message is an automatic response from Port25's authentication verifier
service at verifier.port25.com.  The service allows email senders to perform
a simple check of various sender authentication mechanisms.  It is provided
free of charge, in the hope that it is useful to the email community.  While
it is not officially supported, we welcome any feedback you may have at
<verifier-feedback@port25.com>.

Thank you for using the verifier,

The Port25 Solutions, Inc. team

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  estafeta.micorreo.net
Source IP:      145.255.98.239
mail-from:      josemaria@midominio.com

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass 
ID(s) verified: smtp.mailfrom=josemaria@midominio.com
DNS record(s):
    midominio.com. 86400 IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
    midominio.com. 86400 IN MX 10 estafeta.micorreo.net.
    estafeta.micorreo.net. 14400 IN A 145.255.98.239

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result:         neutral (message not signed)
ID(s) verified: header.From=josemaria@midominio.com
DNS record(s):

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: josemaria@midominio.com)
ID(s) verified: header.d=midominio.com
Canonicalized Headers:
    date:Mon,'20'03'20'Mar'20'2014'20'14:08:44'20'+0100'0D''0A'
    from:=?UTF-8?B?Sm9zw6kgTWFyw61hIE1vcmFsZXMgVsOhenF1ZXo=?='20'<josemaria@midominio.com>'0D''0A'
    reply-to:josemaria@midominio.com'0D''0A'
    to:josemaria.morales@gmail.com,'20'jmmoralesv@outlook.com,'20'jmmoralesv@yahoo.com,'20'check-auth@verifier.port25.com'0D''0A'
    subject:prueba'20'desde'20'morales-vazquez'20'a'20'dkim'0D''0A'
    dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=midominio.com;'20's=mail;'20't=1393852124;'20'bh=bTRBPsyNE9vY+br0wyWV6XaM4bHp8xfOlCzTWRPryRY=;'20'h=Date:From:Reply-To:To:Subject:From;'20'b=

Canonicalized Body:
    xxxx'0D''0A'
    '0D''0A'
    --'20''0D''0A'
    --'20'Jos'C3''A9''20'Mar'C3''AD'a'20'Morales'20'['20'josemaria@midominio.com'20']'0D''0A'
    ------------'20'Blog:'20'['20'https://blog.unlugarenelmundo.es/'20']'0D''0A'
    ------------'20'Perfil:'20''20'['20'http://cv.morales-vazquez.es/'20']'0D''0A'
    

DNS record(s):
    mail._domainkey.midominio.com. 86400 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB"

Public key used for verification: mail._domainkey.midominio.com (1024 bits)

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

----------------------------------------------------------
Sender-ID check details:
----------------------------------------------------------
Result:         pass 
ID(s) verified: header.From=josemaria@midominio.com
DNS record(s):
    midominio.com. 86400 IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
    midominio.com. 86400 IN MX 10 estafeta.micorreo.net.
    estafeta.micorreo.net. 14400 IN A 145.255.98.239

----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin v3.3.1 (2010-03-16)

Result:         ham  (-2.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
ACTUALIZACIÓN: Si has llegado hasta aquí y quieres continuar con los registros DMARC puedes dar un salto a esta otra entrada 😉

Greylisting en Postfix y Debian 7

correoNadie se acuerda de Santa Bárbara hasta que truena, que dice el refrán. Yo tenía pendiente configurar un sistema de Greylisting (listas grises) en mi servidor de correo pero no lo he visto como urgente e inmediato hasta el aumento inusitado de actividad de los bots de spam de los últimos días.

El Greylisting es, hoy por hoy, uno de los métodos más efectivos a la hora de controlar el spam y su funcionamiento es sencillo y fácil de entender. Cuando un servidor de correo recibe un mensaje anota en una lista tres datos que lo identifican (la IP desde donde viene, el correo del remitente y el del receptor) y a continuación lo rechaza indicando al emisor que lo intente de nuevo más tarde. Esto se hace con un código 45x:

-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
<- 451 4.7.1 Please try again later

Si el mensaje ha sido enviado por un servidor SMTP legítimo reconocerá el mensaje de rechazo y en un tiempo predefinido (típicamente de 300 segundos) reenviará de nuevo el correo que, en este caso, será aceptado por el servidor del destinatario. Un bot preparado para enviar spam no realizará el segundo envío. De esta forma, si el correo no es spam llegará al destinatario con 5 minutos de retraso. Salvo este detalle el emisor no se enterará de nada (todo el trabajo se hace entre los servidores de correo sin que los clientes intervengan). Si el receptor abre la cabecera del mensaje recibido verá una línea parecida a esta:

X-Greylist: delayed 300 seconds by postgrey-1.34 at invernalia; Thu, 19 Sep 2013 16:30:33 CEST

El sistema de control del spam mediante Greylisting fue originalmente ideado por Evan Harris en este whitepaper de 2003. El señor Harris mantiene, además, una lista de implementaciones de su método para diversos servidores de correo. Si quieres más información conceptual sobre esta técnica, esta página y la entrada correspondiente de la wikipedia también tienen información interesante.

Si ya tienes una Debian con un servidor de correo postfix funcionando la implementación en perl del Greylisting es muy, muy fácil de poner en marcha. Basta con instalar el paquete postgrey y añadir check_policy_service inet:127.0.0.1:10023 en la lista de restricciones del fichero main.cf de configuración de postfix en el directorio /etc/postfix:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023

Por supuesto, una vez hechas ambas cosas debemos de reiniciar el servicio postfix. La instalación nos ha creado un nuevo servicio llamado postgrey que arranca como daemon y escucha en el puerto 10023 y que responde a los argumentos habituales: start, stop, restart, reload, force-reload y status. En el directorio /etc/postgrey tenemos dos ficheros denominados whitelist_clients y whitelist_recipients donde, respectivamente, se pueden especificar las direcciones de ciertos servidores smtp o direcciones de correo que no se someteran al procedimiento de rechazo temporal de los mensajes y que se aceptaran al primer intento. Tenemos, además, un fichero donde se encuentra la configuración principal del servicio llamado /etc/default/postgrey que veremos más adelante.

Si observamos ahora el log de nuestro postfix (/var/log/mail.log) podemos estudiar el funcionamiento y si este es correcto. Cuando recibimos cualquier correo (salvo uno ya identificado como válido en las whitelist) será inmediatamente registrado y rechazado:

Al cabo de cinco minutos si el correo es legítimo el servidor remitente volverá a intentarlo y ahora el correo si será aceptado:

Puede que el servidor emisor se impaciente y antes de que transcurran esos cinco minutos vuelva a intentarlo. En ese caso el correo volverá a ser rechazado:

Como puedes observar en los mensajes del log, aparte de la razón del rechazo el servidor enviará una dirección web personalizada donde se informa detalladamente de lo que está ocurriendo:

mensaje de información de postgrey en castellano

Postgrey crea, además, una base de datos en el directorio /var/lib/postgrey donde guarda información acerca de los mensajes recibidos. Después de aceptar cinco mensajes de un servidor, este será automáticamente incluido en una whitelist de tal forma que, a partir de este momento, ya no se le volverá a exigir el trámite de los reintentos. Podemos consultar en cualquier momento los servidores de esta lista ejecutando el siguiente script:

perl /usr/share/doc/postgrey/postgrey_clients_dump

Y una ejecución de ejemplo:

Servidores incluidos en la whitelist de greylist

Tenemos aún pendiente ver el fichero de configuración principal: /etc/default/postgrey. En el podemos modificar, por ejemplo, el texto que aparecerá en el mensaje de rechazo:

POSTGREY_TEXT="Si tu sevidor funciona como debiera debería de intentar enviarme de nuevo el mensaje en 5 minutillos de nada"

También podemos enviar al demonio cualquiera de los argumentos que tenemos disponibles para modificar su funcionamiento (ver man postgrey) mediante el parámetro POSTGREY_OPTS. Por ejemplo, en la siguiente línea se dice al demonio que escuche en el puerto 60000, subimos el retraso para aceptar el mensaje a 600 segundos y le indicamos que incluya las direcciones de los clientes en la whitelist después de aceptarles 3 envíos:

POSTGREY_OPTS="--inet=60000 --delay=600 --auto-whitelist-clients=3"

Para terminar, si quieres comprobar la configuración de tu servidor de correo electrónico para ver si es vulnerable de alguna forma y puede ser usado como un Open Relay, si el correo saliente que envía puede verse bloqueado de alguna forma, etc. existen muchas herramientas en línea pero las más cómodas y completas, a mi juicio, son las de mxtoolbox y el test de allaboutspam.

Sobreviviendo a Twitter

spam mediante DM en twitter Twitter logoNo recuerdo (y tal vez no haya precedentes) la última vez que un servicio de Internet ha creado en torno suyo un ecosistema tan diverso de aplicaciones y servicios como está ocurriendo con Twitter. Existen clientes para todos los gustos y plataformas, utilidades, juegos, chorradas de todo tipo… Tal vez el repositorio más completo sea el de oneforty pero basta con que hagas una sencilla búsqueda en google para encontrarte con miles de listas de supuestas “imprescindibles”.

Twitfilter valora con un índice a nuestros followers Pero que el uso de twitter corre también el riesgo de convertirse en un verdadero coñazo es algo más que evidente. Por un lado empiezan a proliferar bots y herramientas que permiten la automatización de seguimientos y respuestas automáticas (twittermass, twollow, assetize, socialtoo, hummingbird2…) haciendo un uso “legítimo” del sistema. En segundo lugar, la seguridad no ha sido nunca una de las prioridades de este servicio (¿podríamos relacionar de forma directa el éxito de algo en este mundillo con su escaso interés por la seguridad?) y ya no es raro recibir algún mensaje de spam procedente, incluso, de la cuenta de algún conocido real y a través de mensajes directos a través de los múltiples agujeros que se le encuentran de forma periódica. En tercer lugar, pero no menos importante, contamos con la práctica común de tantos y tantos “amigos”, conocidos y otro tipo de contactos que por diversas razones queremos mantener en nuestra listas pero que no siempre atinan (atinamos) con, digamos, una adecuada frecuencia (e interés) en la actualización de sus estados.

Twitstat permite identificar a los bots en Twitter Desgraciadamente al otro lado, el que nos permitiría controlar de alguna forma esta actividad, sigue habiendo pocas cosas interesantes. Pero haberlas, haylas. Una de ellas nos la proporciona Twitstat, un sencillo cliente para móviles que dispone de una utilidad que permite identificar a los bots que nos siguen en función de sus hábitos y suscripciones. Para usarlo no necesitas crear una cuenta adicional y puedes hacer login con tu identificador y contraseña de twitter. En este mismo sentido contamos con twittfilter que hace una valoración individual de nuestros contactos y, mucho más práctico para los que cuentan con cientos de seguidores, tweetblocker que los ordena en cinco categorías (A, B, C, D y F ¿qué diablos les ocurre con la letra E?) en función de las probabilidades de que sean bots o spammers y bloquearlos a todos con unos pocos golpes de ratón.

Tweetblocker categoriza nuestros followers en twitter

En otro segmento tenemos a muuter una utilidad que nos permite “silenciar” a un contacto durante un determinado periodo de tiempo (todos nos ponemos pesaditos con algún tema de vez en cuando ¿verdad?) o filtrar todos los twitts que recibimos en función de determinadas palabras clave. Esta segunda funcionalidad está aún en fase beta y no funciona del todo correctamente, pero promete. Lo realmente bonito de muuter es que se trata de un filtro totalmente independiente y que nos va a permitir seguir usando nuestros clientes favoritos y poder disfrutar de estos filtros. Por cierto: que no se me enfade nadie que el pantallazo de aquí abajo es puramente experimental 🙂

Montaje con los dos tipos de filtros que muuter nos permite

Pero en este terreno, si hay una utilidad que brilla con luz propia es Filltr, un cliente web (prometen un futuro cliente de escritorio) que a través de una inteligente combinación de prioridades directamente aplicadas a los usuarios y filtros aplicados en base a listas blancas y listas negras te permite personalizar de forma perfecta que es lo que quieres ver (y de quién) en tu timeline de twitter.

Montaje con los filtros disponibles en Filttr, el cliente de twitter perfecto

Imagino que tendremos que ver muchas más cosas en este campo en los próximos tiempos (Stoptweet, por ejemplo, es un servicio que aún no he podido probar por estar en fase beta bajo invitación). El planteamiento del servicio es, en cualquier caso, tan frágil e inseguro que mucho me temo que en el futuro se convertirá en algo similar al correo electrónico: lo usaremos por sus ventajas a pesar de sus incontables (e irresolubles) inconvenientes…

Spam, spam, spam

icono para asuntos de spamNo, no es la evolución del IPC según Libertad Digital 😛 Es la gráfica de los mensajes de spam que han llegado a este blog durante, aproximadamente, el último mes ¿Habéis sufrido todos este incremento de los últimos días o es que yo le caigo mal a alguien?

gráfica de evolución del spam

El gráfico está editado a partir de los que genera automáticamente Defensio (si, vuelvo a probarlo después de que haya dejado atrás la fase beta y por el momento parece marchar bastante bien).

Defensio: nuevo plugin antispam para wordpress

icono de wordpress Desde hace unas horas estoy probando por aquí a Defensio, el nuevo plugin antispam para wordpress que por el momento permanece en fase de beta privada. He desactivado también los tres plugins que suelo usar de forma habitual para combatir el spam (Akismet, Trackback validator y Comment Policy) así que, si la cosa va mal, puede que temporalmente se vean por aquí mensajes poco apropiados… Ruego comprensión.

Así a primera vista tiene un aspecto bastante similar a Akismet. Defensio asigna un porcentaje de lo que el llama “Spaminess” a cada comentario recibido y guarda los mensajes que el considera spam en una página al mismo nivel que los Comentarios de tu wordpress. Además te permite a ti elegir que porcentaje (por defecto situado al 80%) se considera como spam de forma obvia y queda relegado a un segundo nivel. Mantiene, además, estadísticas no sólo con los mensajes de spam capturados sino también con los comentarios legítimos y los falsos positivos y negativos.

Ya os iré contando que tal aunque, me temo, que si el plugin no es todo lo bueno que debiera lo veréis vosotros mismos…

ACTUALIZACI?N: Fin de la “aventura”. Las estadísticas del nuevo plugin muestran un 98,43% de eficacia con 398 mensajes de spam detectados correctamente y 10 falsos positivos. Me vuelvo con Akismet.

Spam en Youtube

Desde hace unos días me ha comenzado a llegar spam al buzón de usuario de Youtube. Imagino que será inevitable que, en muy poco tiempo, comience a llegar igualmente al resto de servicios con algún tipo de mensajería o similar: comentarios en las fotos de flickr, enlaces enviados a través de las redes de del.icio.us, mensajes en last.fm… ¡Qué pesadilla!

Spam en Youtube

La coctelera está hasta arriba

Hasta arriba de spam, me refiero. Lo habeis notado ¿verdad? Los que teneis un blog allí seguro que si y los que frecuentais alguno en este popular sistema imagino que también… Lo que me extraña es que hasta hace muy, muy poco parecían tener este problema bastante controlado y sin embargo ahora está verdaderamente insoportable ¿le está afectando particularmente esta última oleada o se trata de algún cambio a peor en sus sistemas y/o filtros?

Furilo parecía el otro día bastante sorprendido y curioso con las nuevas variantes más “humanas” de spam. A lo mejor es por eso… 😉