Como evitar que usen tu dominio para hacer phishing

Quizá tengas un dominio que no estés utilizando, que lo tengas en parking, redirigido o simplemente a la espera. En ese caso, puede ser una buena idea bloquear que nadie lo pueda utilizar para enviar emails en tu nombre.

¿Has oído hablar del phishing? Aunque no hayas oído hablar de él, lo que es seguro es que lo has sufrido. Esos correos que parecen que son de tu banco, de una ONG, de tu compañía eléctrica o de telefonía y que te envían a un sitio web donde debes introducir tu usuario y contraseña o tu tarjeta de crédito. Eso es el phishing: correos que suplantan a las verdaderas entidades para engañarte conseguir información (normalmente datos bancarios o contraseñas).

¿Sabrías reconocer el phishing?

Google ha creado un pequeño test en el que te explica cómo puedes detectar si un correo es real o es un intento de phishing.

Está disponible en: https://phishingquiz.withgoogle.com/

Vamos a suponer ahora que no solo eres el receptor de esos correos sino que esos mardito roedore están utilizando alguno de tus dominios para hacer el mal. La buena noticia es que tiene solución.

Si no estás utilizando tu dominio para el envío de correo (p.ej. puede que sea un dominio paraguas para redirigir a tu dominio principal), puedes forzar a que se deniegue todo intento de envío de correo en nombre de ese dominio, que cualquiera que reciba un email de ese dominio sepa que no está autorizado. Para eso utilizaremos SPF y DMARC.

SPF (Sender Policy Framework) es la forma más sencilla de otorgar o denegar permiso a terceros para utilizar. Para lo que nos interesa a nosotros ahora, lo que vamos a hacer es prohibir cualquier envío en nombre de nuestro dominio. Para ello, vamos a suponer que el dominio que no queremos que permita envíos se llama sasa.eh (existe la extensión .eh, por cierto, y se corresponde con el Sáhara Occidental). Usando SPF añadiremos la siguiente entrada DNS de tipo TXT en el dominio:

@  IN  TXT  "v=spf1 -all"

Con esto ya estamos impidiendo enviar emails utilizando nuestro nombre de dominio.

SPF es sencillo, pero no es perfecto. Una vuelta de tuerca adicional vino con DKIM. DKIM te permite cifrar los envíos de forma que el destinatario puede comprobar si la clave que recibe fue realmente emitida por el dominio en nombre del que se realiza el envío. Esto ya requiere un esfuerzo adicional por parte de los servidores de correo y es menos sencillo de implementar que el SPF. Para nuestro caso de uso, esto nos da igual, pero es importante saber que existe DKIM.

Cómo funciona DMARC (de Valimail)

DMARC, se apoya en SPF y DKIM para otorgar autenticidad al remitente del envío. Aquí también se trata de añadir entradas DNS en el dominio de forma que indiquen cómo debe comportarse en caso de que se pase la validación SPF o DKIM. Como nosotros lo que queremos es no permitir ningún envío desde sasa.eh, vamos a ser totalmente restrictivos y añadiremos esta entrada DNS de tipo TXT:

_dmarc  IN  TXT  "v=DMARC1; p=reject"

Con estas dos entradas DNS, estamos bloqueando que utilicen nuestro dominio para realizar envíos no autorizados.

El presente del email

Al igual que el correo estándar, parece que el email está aquí para quedarse. Parece mentira, pero un servicio con más de 45 años de antigüedad en informática (la protohistoria…) se utiliza a diario prácticamente como servicio principal.

Francamente, el servicio está aquí para quedarse, como digo (echad un ojo al artículo Email Will Last Forever). Hay muchas opciones de mejora, pero tal y como están los estándares hoy en día es complicado lograr el consenso que tiene ahora el email.

¿Os imagináis que todos los servicios de mensajería fueran compatibles entre si? Pues más o menos eso es lo que tenemos con el correo electrónico.
Las capas que añadamos al correo, serán siempre bienvenidas para conseguir una funcionalidad y experiencia más acorde a lo que buscamos en cada momento (comunicación inmediata, segura, trabajo en grupo…).

En los últimos 2-3 años, hay muchas iniciativas para reinventar el correo o, al menos, para potenciar características a las que, hasta ahora, no se las había prestado demasiada atención.

Alguna de las preocupaciones más habituales que podemos observar:

  • Seguridad y privacidad. Posiblemente la preocupación nº 1 a día de hoy. Gracias a la NSA nos damos cuenta, que GMail lee nuestros correos, o que cualquiera puede acceder a todas nuestras comunicaciones con muy poco esfuerzo.
    Un servicio de correo (o almacenamiento de datos… que lo mismo da) con conocimiento cero de nuestro contenido y comunicaciones es una funcionalidad cada vez más valorada.
    Podéis echar un ojo a OpenMailbox o, en general y para cualquier tema relacionado con la seguridad y privacidad, podéis echar un ojo a Prism Break
  • Ubicuidad e integración. Enviar recibir mails desde cualquier sitio y dispositivo es algo fundamental y a lo que nos hemos acostumbrado hace tiempo. No solo leer/recibir correos, sino también compartir contenido a través del correo desde cualquier sitio igual que hacemos con las redes sociales o enviar y almacenar el contenido en cualquier sitio.
  • Control de las conversaciones. ¿Se ha recibido el correo? ¿Lo han leído? ¿Cómo sigo las conversaciones? ¿Ha llegado a la inbox? Algunas funcionalidades propias de soluciones de envíos masivos son golosas de trabajar.
  • Trabajo en grupo/usabilidad/…. Aquí es donde surgen los nuevos interfaces, las nuevas formas de hacer, integraciones con otros servicios, etc. Por ejemplo, el caso de AOL, el de Mailpile.is, Hiri (solo para Office365) o «nuevas» funciones como propone por ejemplo Mailtime.

Tomando como base el correo hay todavía mucho por recorrer: tiene un presente y un futuro esperanzador este viejo conocido.