Aunque no de mi agrado, reconozco que es una solución muy buena. DKIM y SPF, se ha vuelto hoy en día un mecanismo para mitigar el SPAM en el correo electrónico.
Esto no quita, que un spammer puede hacerse con un buen esquema de DKIM para sus dominos de porquería; lo cual sería un estupendo negocio, teniendo en cuenta que un servidor puede tener tantos dominios como quiera. Si conoce a algún spammer que quiera tener DKIM y SPF en su negocio, por favor, mándele mi tarjeta.
Me imagino que a los usuarios de nauta, les duela bajar un mensaje que aparentemente tiene dos lineas, pagando por uno que realmente tiene más de 20 líneas de pura mierda que no les incumbe. Espero que etecsa se digne a retirar encabezados innecesarios como esos (para el cliente).
Por otra parte, mucha gente tiene antivirus que modifican el correo o son fanáticos a instalar mil gangarreas (mailscanner, clamav, etc…) que también modifican el correo. Con esto, DKIM y SPF se van a la mierda.
Le diré que hice con un postfix que ya estaba instalado en un debian8 para ponerle DKIM y SPF.
Instalamos los jueguetes requeridos ante todo:
1
|
|
y establecemos los permisos adecuados, ojo con esto, ya que dkim es muy riguroso con el tema de los permisos
1
|
|
SPF
Ahora procedemos a crear el registro DNS. Como hay muchos DNS y cada quién tiene sus preferencias, me reduciré a describir de manera abstracta los registros. Usted, aterrize la idea en su DNS.
Esto tiene DOS formas de hacerse:
La primera:
Declarar que TODOS los MX del dominio, pueden mandar correo (lo cual inspira desconfianza) en este caso, registra un puntero del tipo TXT con el siguiente valor
v=spf1 mx -all
Por ejemplo, bind9
1
|
|
La segunda:
Declarar que un host, que tiene un registro A, está autorizado a enviar correos (esta me gusta más, si tienes un solo servidor de correo) Si fueran varios, por ejemplo 3. Podrías declarar un A para cada uno y de manera individual, ellos generarían su SPF apuntándose a si mismo.
v=spf1 a:mx1.tudominio.cu -all
Como ya sabemos, un puntero MX siempre deberá apuntar a un rgistro A, ya que no se recomienda apuntar a un CNAME…
Nota para los apurados: “Si declaras ambos registros, no pincha, LEE!!”
Otra cosa, puedes declarar -all o ~all El primero le dirá al receptor que si el correo no viene del dominio que dice enviarlo (el puntero A o los MX), lo rechace porque es falso (muy radical) y el segundo, que empieza por ~ le indica al receptor, que puede recibir el mensaje y si no pude verificarlo que lo marque como spam, pero que por favor, no lo rechaze.
Esto nos lleva a una:
Situación peligrosa
Cuba, un descerebrado configuró verificación de DKIM, porque está de moda. PERO! Está detrás de un smarthost (pasarela) o simplemente, su configuración de DNS no vale un quilo (por culpa del proveedor)
Metedura de pata - A:
Ese servidor de correo, que se cree Oggun con machete en mano; descartará todo correo con -all debido a su incapacidad de realizar un lookup decente.
Metedura de pata - B:
Uno más descerebrado todavía, vio que DKIM estaba de moda y sin importar que no tiene control de su DNS, lo hizo todo, saltándose el paso del DNS. Su servidor le estará gritando a toda voz al mundo entero, que está falseando el dominio
Su ignorancia le costará caer de cabeza en las listas negras…
Y es que:
Generalmente, los servidores que entregan a través de un smarthost, carecen de DNS real. También hay una pila de gente que administran servidores sin tener control de su DNS.
Seguimos…
Ya que tenemos el SPF pinchando, podemos añadirle chequeo de SPF a nuestro postfix que tiene bien configurado el DNS y entrega de cara a internet sin smarthost
En el fichero /etc/postfix/master.cf le agregamos esto:
1 2 |
|
y a los posftfix cubanos, le decimos que sea paciente con el proceso de verificación, incrementando el tiempo que tiene que esperar por el policyd, ya que dicha verificación puede tardar (dns lookup, cpu a tope, etc..) Añadimos esto a /etc/postfix/main.cf
1
|
|
Ahora viene una parte complicada, pues no hay manera de que pueda reflejarla como para copiar y pegar.
Deberás modificar tus reglas de postfix, de forma que antepongas el chequeo SPF, como una más de tus restricciones de recibo. Para mi caso, está bien la última linea.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Reinicia postfix y chequea el /var/log/mail.log para que veas SPF pinchando.
DKIM
Me parece que la configuración de DKIM en debian está buena, pero por si las moscas. Copias esta que pongo aquí y métela en tu /etc/opendkim.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
De ahí puede que quizás te interese la variables SubDomains, sobre todo si eres proveedor de correo.
Como ya te dije, los permisos son sumamente importantes en este caso
1
|
|
Ahora creamos el directorio donde vamos a meter todo el zoológico requerido para que DKIM pinche. Hay quién prefiere meterlo en /var, para mi en /etc/opendkim es un buen lugar.
1 2 3 4 |
|
La Firma
Ahora vamos a crear la tabla de rúbricas (se aceptan contribuciones para traducir). Ahí, ponemos una linea por cada dominio que tengas. Creas el fichero /etc/opendkim/signing.table y está recomendado que le pongas lo siguiente:
1
|
|
Nota para los imbéciles: No olvide remplazar tudominio.cu por el nombre del dominio suyo.
Con eso, casamos todos los correos que parezcan a tu dominio, con el DKIM que llamamos “tudominio”, si quiere atrás le puede poner “pepe”. Lo que debe quedarte claro, es que todos los correos que macheen a la expresión regular de alante, pasarán por el filtro llamado tudominio (o “pepe” si lo cambiaste) ¿Se entendió?
Por ejemplo, si tu dominio fuera *@cacocum.hlg.sld.cu podrías ponerle detrás “midkim” para que todos los correos de ese dominio, se firmen con la firma que será configurada bajo el nombre “midkim” Quedaría así:
*@cacocum.hlg.sld.cu midkim
Resumen:
El primero campo, es una expresión regular que mache las direcciones de correo y el segundo el nombre de la firma que se usará. Para mayor confusión, se recomienda que se hagan nombres parecidos. Finalmente nos quedó así:
1
|
|
La clave
Ahora creamos el fichero, donde le diremos a “midkim” donde va a encontrar su parafernalia cifradora. Crea el fichero /etc/opendkim/key.table y ponle dentro esto:
1
|
|
IMPORTANTE
Remplaza YYYYMM por el año y el número de mes en el que estamos.
SI NO, NO PINCHA
A mi me quedó así:
1
|
|
Ya que estamos en el año 2016 y el mes 06 no el 6 (lleva cero delante).
Ojo aquí, ya que si tienes más dominios, es complicado. Nota que debes reflejar a localhost con sus pertinentes ip, además, tu nombre de host, tu dominio y el nombre del host conjugado con el dominio. Siendo entonces fulanito el nombre del host, quedaría así en el fichero /etc/opendkim/trusted.hosts
1 2 3 4 5 6 |
|
Los permisos, ya tu sabes:
1 2 |
|
FINALMENTE! Vamos a generar la clave para el dominio:
1 2 |
|
Las claves se generan en base a la fecha, pero luego se colocan en base al dominio. Esto se hace porque hay que renovarlos pero si configuramos opendkim para que apunte a un fichero cuyo nombre sea la fecha, tendríamos que cambiar la configuración cada vez que renovamos.
1 2 |
|
Si tu clave se llamase “pepe” o “midkim”, ya sabes que esos ficheros se llamarían “pepe.private” o “tudkim.txt” ¿Entiendes ahora? Seguimos…
El argumento -b indica la longitud de clave en Bit. En otros tiempo 1024 era la tisa, pero ahora, se recomienda usar 2048 porque las máquinas son más potentes. Quizás dentro de un par de años, sea 4096.
Bueno, ya sabes, la ceremonia de los permisos:
1 2 |
|
Arranca opendkim y asegúrate mirando los; log que esté pinchando.
1 2 |
|
El DNS
El patico feo de internet, el DNS. El remedio que se inventó pa ir tirando y acabó quedándose con su pésimo diseño y su horrible arquitectura que hasta el sol de hoy, pretende llamarse “distribuida”
Agregamos le registro TXT con la clave. Te cuento que el fichero “.txt” contiene el tabaco base64 que usualmente vemos en el encabezado DKIM-Signature, pues proviene de este registro TXT que estamos creando.
Añade un registro del tipo TXT que apunte a un hostname llamado 201606._domainkey dentro de tu domino. Pero ahora viene la parte difícil:
Copia el texto que contiene el fichero tudominio.txt dentro de la primera comilla hasta la última, pero sin tomar las comillas.
¿Se entendió?
O sea, dentro del fichero tiene esto:
1
|
|
Al extraer la parte que nos interesa, no quedamos con esto (sin las comillas)
1
|
|
OJO Tiene más comillas en el medio!!!!
Auxíliate de un editor de texto decente. Deshabilita el wrap y busca la comilla como cadena de texto.
Ese texto, será el valor del puntero TXT
A mi me quedó así:
1
|
|
Completo! Vamos a probarlo a ver que pasa:
1
|
|
Si sale silentemente sin mostrar algo. Es que todo está bien.
opendkim y postfix
Finalmente, nuestro postfix tendrá el privilegio de firmar los correos usando el aparataje recién configurado. Vamos a crearle un cuartico de dkim en la casa de postfix
1 2 |
|
y habilitamos el socket de opendkim, editando el fichero /etc/default/opendkim
1 2 3 4 5 6 7 8 9 10 |
|
Note como retiramos el comentario de la línea 7
Ahora declaramos en postfix que debe usar a opendkim como demonio de preprocesamiento en el típico /etc/postfix/main.cf
1 2 3 4 5 6 |
|
Finalmente, reinicia opendkim y postfix
1
|
|
COMPLETO!!!
Con eso hemos terminado. Para probarlo, puede enviar un correo a check-auth@verifier.port25.com
Esa dirección le hará una prueba al DKIM+SPF de tu correo. No solo eso, le hará una prueba del Pi al Pa a tu correo y te dirá todo lo que necesitas.
Si quieres ponerle la guinda al pastel, puede añadirle ADSP (Author Domain Signing Practices) a tu esquema. Esto indica que todos los correos que salgan de tu dominio deben estar firmados con DKIM, proveiendo aún más confianza al receptor.
Crea un registro TXT para el hostname adsp.domainkey y el valor del TXT será dkim=all. A mi me quedó así:
1
|
|
Con eso, tus correos no caerán más en la bandeja SPAM de gmail.
Otra cosa importante, asegúrate de tener el reverse lookup de tu MX bien puesto.