… que hay que implementar cuando se quiere utilizar el proyecto para obtener certificados digitales para nuestros servicios.
… que hay que implementar cuando se quiere utilizar el proyecto para obtener certificados digitales para nuestros servicios.
… en Debian, ya que estoy pensando en crear una impresora virtual para obtener versiones HTML de los listados de la empresa.
… y para que no se me olvide en el futuro.
… valiosas para escribir otros programas y crear paquetes Debian ya puestos.
… me importo más de sesenta entradas nuevas procedentes de mi blog en Tumblr llamado pequeñeces. Así, sin anestesia.
… en una página especial que he añadido al menú principal, el que aparece en la cabecera del blog.
… me encuentro con que faltan imágenes en la base de medios, concretamente desde febrero del año 2015.
… no hay tanto camino como uno pudiera creer.
Aunque el servidor no vaya a gestionar buzones de correo electrónico considero que es valioso que sea capaz de enviar y recibir mensajes sin necesitar una pasarela con sus credenciales.
Esto es especialmente cierto ya que suelo centralizar la cuenta del administrador para todas mis máquinas en una cuenta externa, y me gusta que no tengan problemas a la hora de enviarme avisos. Es un rollo tener que consultar varios buzones locales para saber qué ha ocurrido.
Así pues, quiero que cada máquina pueda enviar correo al exterior y necesito reducir las posibilidades de que le ignoren (marcándolo como spam) o directamente le denieguen el acceso.
Para ello el servidor tiene que cumplir una serie de requisitos:
Steve Kemp tiene varios artículos al respecto. Como resumen podemos afirmar que todos requieren cambios en el DNS y la implicación del servicio de correo.
Ya hay excelentes explicaciones de cómo funciona el invento así que no me voy a extender en ello. Si escribo ésto es para anotar detalles técnicos a los que tendré que recurrir una y otra vez en el futuro.
En este dominio el registro SPF queda así:
v=spf1 mx a ip4:46.101.91.82/32 -all
donde indico que sólo los servidores definidos en el registro MX pueden enviar correo en su nombre, concretamente señalo la dirección IP, e indico que los correos tienen que rechazarse si no cumplen alguna de éstas condiciones (-all). Se puede consultar la síntaxis aquí.
Una vez tengamos la definición es recomendable crear dos registro en el DNS del dominio: uno de tipo SPF y otro de tipo TXT. Por lo visto no todos los clientes consultan el primero y es algo que no cuesta.
Respecto a exim4 sólo tenemos que preocuparnos de la recepción del correo y para ello vamos a indicar que emplee SPF
Si el registro SPF hubiese contenido una política de fallo blando (~all)los mensajes recibidos serían aceptados pero se incluiría un aviso en forma de cabecera especial
Received-SPF: softfail client-ip=...
que podría ser utilizada por posteriores filtros de spam. En este caso concreto prefiero que dichos correos sean rechazados durante la conexión (parámetro -all) como el fragmento de conexión que muestro a continuación:
MAIL FROM:<root@esferas.org> 250 OK RCPT TO:<root@esferas.org> ** 550-[SPF] 79.148.243.240 is not allowed to send mail from esferas.org. Please ** 550 see http://www.openspf.org/Why?scope=mfrom;identity=root@esferas.org;ip=79.148.243.240
Este mecanismo consiste en emplear un par de claves criptográficas, una pública y otra privada, y publicar la primera, la pública, en el registro DNS. El servidor de correo firmará con la clave privada los mensajes salientes y el receptor del mismo podrá, tras consultar el registro DNS correspondiente, verificar la autenticidad del mismo.
Los pasos a seguir son los siguientes: