Spam (o phishing) para PPeros

Josemaría | 29 de mayo de 2014 | 1 comentario

icono para asuntos de spam No tengo claro si catalogar esto que acabo de recibir como spam o como phishing, pero aquí lo dejo por si pasa algún carguito del PP despistado y no sabe aún como hacer lo que manda la moda 😉

Spam para gente con pelas

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

Josemaría | 28 de mayo de 2014 | 3 comentarios

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:

blackhat Si tienes un servidor con presencia en Internet, usas (como deberías) algún sistema para bloquear los intentos de acceso no autorizados como fail2ban o denyhosts y analizas de vez en cuando los logs, no voy a decirte nada nuevo: en los últimos meses hemos experimentado un aumento inusitado de intentos de intrusión desde direcciones IP procedentes de China. En mi caso, en los últimos tres meses el 83% de los intentos irregulares de entrada a través de ssh que he observado proceden de este país. Concretando aún más, el 50% del total de estos intentos procede de la subred 116.10.191.0/24 y el 25% de la subred 61.174.51.0/24. Así que ya sabes: si eres de los que prefieres los métodos preventivos ya tardas en banear ambas subredes en tus cortafuegos. (6 comentarios)

Chuletillas (y XXXIX) – Instalar VirtualBox en Manjaro (u otro derivado de ArchLinux)

Josemaría | 8 de abril de 2014 | 5 comentarios

chuleta Los derivados de ArchLinux (Manjaro, Chakra, etc.) suelen ser bastante más fáciles de manejar que la distribución matriz, pero aún así no es nada anormal que la instalación de ciertos paquetes sea ligeramente más dificultosa de lo que estamos acostumbrados en un Linux de escritorio y que requieran de nosotros alguna que otra intervención manual más allá de un simple pacman -S. Virtualbox es uno de estos casos y, aunque todas las posibles situaciones están perfectamente explicadas en esta página de la wiki de ArchLinux, vamos a dejar aquí una chuleta que debería de funcionar en la gran mayoría de los casos.

7 enlaces 7 (y LVII)

Josemaría | 7 de abril de 2014 | 1 comentario

enlaces rápidos

Categorías: enlaces rápidos, tecnología
Etiquetas:

Series, series y más series… (y II)

Josemaría | 4 de abril de 2014 | 1 comentario

icono televisiónSegunda entrega del “coleccionable” que empezamos por aquí dedicado a recomendar o a desaconsejar series para adictos al género o papás y mamás sin más de 45 minutos al día. Recordad la única norma: sólo valen series que lleven por el momento una única temporada. ¡Y empezamos!

Almost HumanAlmost Human. La pareja protagonista son un poli chulazo y bruto pero con buenos sentimientos y un remilgado y obsoleto androide que le han asignado como pareja. Así dicho no resulta demasiado atractivo, ya, pero los casos a los que se enfrentan suelen ser interesantes, el futuro que describen inquietante y al final la serie funciona. No he terminado aún la primera temporada pero por el momento no me aburro…

Under the DomeUnder the dome. Un buen día en un (aparentemente) aburrido y tranquilo pueblito de la america rural aparece una especie de burbuja transparente e infranqueable que lo rodea por completo y para la que nadie, ni dentro ni fuera de ella, parece tener explicación. A partir de ahí empezamos a ver que el pueblito no es tan aburrido como parece y que todos allí tiene un pasado. Algunos hasta media docena. Aburrida hasta límites insospechados, con unos personajes tan poco bien perfilados que casi resultan cómicos y una trama tan ridícula que al final ya te da igual de donde haya salido la maldita cúpula y si se mueren todos de lo que sea. Por increíble que parezca han aprobado una segunda temporada… Evitadla, please.

Orphan BlackOrphan Black. Una huérfana canalla y barriobajera se encuentra por casualidad en un metro de New York con la que parece ser su gemela justo en el momento en que se tira bajo las ruedas de un tren. Roba sus pertenencias, la suplanta, y descubre que se trata de una acomodada poli… y que hay bastantes más gemelas iguales a ellas dos. De lo más interesante que vi el año pasado, la verdad. Y si te das prisa aún estás a tiempo de pillar la segunda temporada (que empieza el próximo 19 de abril) desde el principio.

NashvilleNashville. Los personajes recuerdan bastantea a los de series míticas de los años 80 como Dallas o Dinastía y eso la hace divertida. La música, además, es bastante buena si te gusta el country y el bluegrass… Al final, en cualquier caso, decidí suscribirme a las listas de temas de Spotify (aquí y aquí) y abandonarla…

NOTA: La segunda temporada está ahora mismo a medias pero cuando yo la probé cumplía con la norma ¿eh?


The Michael J. Fox ShowThe Michael J. Fox Show.
Serie cancelada antes de terminar su primera temporada, así que no os hagáis mucha ilusión con ella. El título ya recuerda a series de otros tiempos, al estilo de el show de Bill Cosby y similares. Más moderna, claro y con un punto de irreverencia que huele a falsa a grandes distancias… pero aún así siento mucho que el retorno del señor Fox haya sido tan terriblemente malo. A la próxima.


Agents of SHIELDAgents of SHIELD.
Sin ser nada del otro mundo, ha mejorado bastante desde unos primeros capítulos ñoños que hacían temer algo enfocado a adolescentes parecido a Smallville o Arrow a… algo un poco menos ñoño 😛 . Lo mejor: ese episodio donde un desertor asgardiano vive oculto como profesor en la Universidad de Sevilla (con exteriores reales rodados en esta ciudad). Doy fé de que si fuese real podría pasar totalmente inadvertido 😀

The BlacklistThe Blacklist. Predecible en casi todo, pero violenta y sin concesiones y eso (y poco más) hace que sea entretenida de seguir. Aún así, hay algo que funciona y me estoy tragando la primera temporada completita…


True DetectiveTrue Detective.
Se han dicho tantas cosas de esta serie (algunas tan extremadamente ridículas que la elevan casi a lo mejor que se ha hecho en toda la historia de la televisión) que yo paso de hacer juicios que luego me llueven piedras. Es buena y tiene personajes fabulosos, bien construidos y mejor interpretados. Sobra, quizás, un poco de misticismo cristiano y se agradecen las incontables referencias que hacen a toda la mitología creada por el círculo de Lovecraft y la recreación de esa América profunda irracionalmente religiosa que tanto morbo nos provoca a algunos. Hay que verla, si, pero sin volvernos locos ¿eh?

House of Cards BBC 1990House of Cards (1990). Si te está gustando la nueva versión de la serie de igual nombre producida por Netflix, merece la pena que le eches un vistazo a esta miniserie de cuatro episodios de la BBC en la que está inspirada. Es bastante más inocente y menos agresiva que su remake. También tiene un aire bastante más cómico a ratos y se nota mucho más viejúna como es lógico, pero la he disfrutado bastante.

Believe Believe. La serie va de una niña con poderes paranormales que está siendo perseguida por dos grupos diferentes: uno con contactos gubernamentales que la quiere para experimentar con ella con fines armamentísticos y otro que pretende protegerla de los primeros. A pesar de lo visto y simple del planteamiento, llegaba apadrinada por Alfonso Cuarón, así que parecía que había que darle una oportunidad… Y se la he dado, conste, pero apenas he podido resistir los tres primeros episodios de rigor. Es ñoña y boba hasta decir basta. Pasa de largo.

Resurrection Resurrection. Esta otra, sin embargo, venía precedida por la etiqueta de ser el nuevo Lost y eso era ya suficiente motivo para evitarla… y sin embargo he picado con los tres primeros capítulos y diría que más que Lost me parece un sucedáneo de Under the Dome. E igual de mala que ella. Vamos que me planto aquí y me trae sin cuidado para que y de donde vienen estos muertitos tan tristes…

Dracula Drácula.
Ni cuatro episodios he aguantado a este vampiro megalómano y empeñado en invertir en la invención de una especie de fuente energética inalámbrica. ¿Puede haber algo más ridículo que una criatura de la oscuridad que promueve la invención de una fuente de energía para proporcionar luz artificial? Pues así toda…

Cosmos 2014 Cosmos: A Space-Time Odyssey. No se si se puede considerarse como una serie (imagino que si, aunque sea una serie documental y no de ficción ¿verdad?), pero aún así la dejo por aquí por si no te has enterado de que se está emitiendo una nueva versión de los clásicos documentales que hicieron mundialmente popular a Carl Sagan en los años 80 y que merece la pena verlos.

SERIES DE ?LTIMA HORA: The Red Road, una más de Montescos y Capuletos en una comunidad india estadounidense con líos de droga de por medio, y Soufthcliffe, una miniserie británica con muy buena pinta de la que se tan poco como aparece en su ficha de IMDB, son dos recomendaciones de última hora que aún no he podido empezar a ver. Ya os contaré en otra entrega…
Categorías: culturales, televisión
Etiquetas: ,

Inspeccionando la cola de correos sin entregar en Postfix

Josemaría | 25 de marzo de 2014 | 6 comentarios

correo No suele ser habitual que postfix encole y/o retrase la entrega de correos electrónicos. Pero a veces ocurre. Por ejemplo por problemas de time-out con el servidor al que tiene que hacer la entrega. Si monitorizamos las colas de nuestro servidor (por ejemplo con munin) podemos observar cuando pasa y con que frecuencia:

Cola de mensajes retrasados (deferred) en postfix

Por defecto se reintenta la entrega de los correos cada 5 minutos y se descartan (generando un correo de advertencia al remitente) si no ha podido hacerse transcurridos cinco días del envío. Podemos variar estos valores introduciendo los siguientes parámetros en el fichero de configuración principal (/etc/postfix/main.cf):

queue_run_delay = 600
maximal_queue_lifetime = 1d

Existen más parámetros relacionados con esta directiva en este enlace del manual de postfix.

Podemos inspeccionar la cola de postfix para ver que mensajes no ha podido entregar y la causa de ello en cualquier momento usando los comandos mailq o postqueue -p (ambos son equivalentes y proporcionan la misma salida aunque mailq es un comando mucho más flexible y potente con más opciones. Consulta el manual 😉 )

Viendo el contenido de la cola de mensajes retrasados (deferred) en postfix

¿Ves el código alfanumérico de 10 caracteres con que empieza cada entrada de la cola? Es el identificador del mensaje que nos permite ver mucha más información acerca del mismo, su estado y su contenido usando el comando postcat -vq seguido de dicho identificador. Por ejemplo, para inspeccionar el primer mensaje de la cola de aquí arriba:

postcat -vq A3C3486137

También podemos decirle en cualquier momento a postfix que reprocese esos mensajes mediante los comandos postqueue -f o postfix flush. O podemos pedirle que reintente sólo uno de los mensajes de la cola usando el identificador que ya conocemos así:

postqueue -i A3C3486137

Por último, para eliminar todos los mensajes en espera de entrega que están en la cola podemos usar el siguiente comando:

postsuper -d ALL deferred

Ten en cuenta que, en este caso, los mensajes serán eliminados sin que el remitente reciba ningún tipo de notificación de que no ha podido realizarse la entrega.

Optimizar la velocidad de carga de WordPress (para tener contento a Google)

Josemaría | 20 de marzo de 2014 | 5 comentarios

icono de wordpress Desde hace ya algunos años, uno de los factores que Google valora a la hora de establecer el ranking de una web es la velocidad de carga de sus páginas. Este es el anuncio oficial que hicieron en el 2010 justificándo esta decisión y esta la página de información y recursos que proporcionan en la actualidad donde tenemos una herramienta que mide los tiempos de descarga de nuestra página y hace recomendaciones para mejorarlos

Existen multitud de buenos recursos en la web sobre este tema. A mi me gustaría destacar dos: las páginas de Exceptional Performance de Yahoo! (un clásico) y esta otra guía más reciente y mucho más centrada en satisfacer las exigencias de Google.

Yo, sinceramente, nunca me he preocupado mucho de estas cosas. Entendedme: me gusta que mis webs se carguen tan rápido como sea posible, pero no hasta el extremo de querer rebajar 100 milisegundos arañando tiempos de aquí y de allá. No obstante, hace unas semanas y más por “deporte” que por otra cosa me propuse jugar un poco con estas recomendaciones y pasé de una valoración de setenta y pocos puntos al 98/100 que veis bajo estas líneas. Os cuento como lo hice y os doy algunas recomendaciones por si os apetece jugar a lo mismo 😉

Resultados obtenidos con Google Page Speed Insights

Lo primero que tienes que hacer es conocer bien como carga tu wordpress, ver como se distribuyen los tiempos y cuales son los principales cuellos de botella. En los enlaces anteriores ya hay referencias a algunas herramientas útiles para esto. Si queréis más, podéis probar con las siguientes:

Estas herramientas nos servirán, además, para verificar que lo estamos haciendo bien y que los cambios que hacemos no son contraproducentes.

El primer punto a vigilar es el tema y los plugins que usas en tu wordpress. Un tema limpio, sin errores y que no esté sobrecargado de estilos, imágenes y javascript mejora notablemente la velocidad de carga. Haz la prueba, si no, cambiando del tuyo a alguno de los más simples que WordPress trae por defecto. Idem con los plugins. Hay algunos que son verdaderos parásitos. Desactívalos todos, comprueba los tiempos que obtienes y, luego, ve activándolos uno a uno probando de nuevo para ver cuales son los más problemáticos. Valora si puedes vivir sin estos o busca sustituirlos por otros equivalentes pero más eficientes.

Piensa, además, que el contenido que incluyas también cuenta. Todos los objetos que incrustes (Youtube, Vimeo, etc.) van a ser valorados en la carga de tu página. En estos momentos, por ejemplo, la valoración que hace Google de mi portada baja del 98 que veis arriba a un 92 por culpa del objeto de Scribd que he incrustado un par de posts más abajo. Las imágenes también cuentan bastante. Usar miniaturas (thumbnails) que requieran de un click para verlas en alta calidad es una buena práctica. Si, como a mi, no te agrada, puedes usar alguna herramienta para optimizarlas antes de subirlas a tu servidor web. Mis favoritas son optipng y jpegoptim. Si, si, para Linux y en línea de comando. Si buscas otra cosa no se que haces por estas páginas 😉 Usa la opción --strip-all con jpegoptim.

Vamos ahora a cargar nuestro blog con una de las herramientas que hemos visto antes y a observar lo que ocurre. Por ejemplo usando Web Page Test:

Resultados obtenidos con Web Page Test

Como puedes ver, uno de los grandes devoradores de tiempo en las páginas de wordpress (y en general con todas las que usan PHP) es el llamado Time to First Byte o TTFB. Se trata del tiempo que transcurre entre que el servidor web recibe la petición de un cliente y el navegador de este recibe el primer byte y, básicamente, se consume sobre todo en procesar el código PHP. La mejor forma de reducirlo al máximo es usar alguna de las muchas cachés para wordpress que convierten tus páginas PHP a contenido estático. Yo uso W3TC habilitando sólo las opciones de caché de páginas y de objetos (para el resto de optimizaciones uso otros plugins) y sólo con esto podrás comprobar que los resultados mejoran sorprendentemente.

Resultados obtenidos con Web Page Test

Utilizar una caché para las consultas a la base de datos también ayuda un poco. W3TC incluye también esta característica, pero yo prefiero usar otro: DB Cache Reloaded Fix.

Incluye cabeceras de expiración para informar a los navegadores de por cuanto tiempo pueden cachear los contenidos estáticos de tu página (imágenes, css, etc.). Para ello lo primero que tienes que hacer es asegurarte que tu apache tiene activado el modulo mod_expires. Luego, en el fichero de definición del Virtual Host o, en su defecto, en el fichero .htaccess tienes que escribir las directivas correspondientes que pueden ser generales o específicas por tipo de archivo. En el anterior enlace a las páginas de apache tienes instrucciones de como hacerlo. Te copio aquí las mías:

ExpiresActive On
ExpiresByType image/gif "access plus 6 months"
ExpiresByType image/jpg "access plus 6 months"
ExpiresByType image/jpeg "access plus 6 months"
ExpiresByType image/png "access plus 6 months"
ExpiresByType image/x-icon "access plus 6 months"
ExpiresByType image/ico "access plus 6 months"
ExpiresByType application/javascript "now plus 1 month"
ExpiresByType application/x-javascript "now plus 1 month"
ExpiresByType text/javascript "now plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresDefault "access plus 1 month"

Optimiza y minimiza el tamaño de los archivos HTML, CSS y Javascript. De nuevo, si lo prefieres puedes activar estas características en el plugin de W3TC pero yo uso otro para esto: Autoptimize. El “truco” consiste en eliminar de estos ficheros cualquier espacio, salto de línea o comentario superfluo y combinarlos en un único archivo, de tal forma que reducimos el número de “requests” al servidor y el tamaño de las mismas.

Estos son los factores más generales a tener en cuenta, pero existen muchos otros particulares de cada caso que tendrás que estudiar usando las herramientas que te recomiendo por aquí y observando cuales son los cuellos de botella de tu instalación particular. Suerte con ello 😉

7 enlaces 7 (y LVI)

Josemaría | 7 de marzo de 2014 | 2 comentarios

enlaces rápidos

Categorías: enlaces rápidos, tecnología
Etiquetas:

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

Josemaría | 3 de marzo de 2014 | 16 comentarios

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'http://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 😉