Postfix 3.10: actualizaciones, TLSRPT y el camino hacia la versión 3.11

Situar cronológicamente Postfix 3.10

A fecha de esta investigación, el 20 de octubre de 2026, Postfix 3.10 no es la rama de desarrollo estable actual: ese papel lo ocupa Postfix 3.11. El fabricante clasifica la versión 3.10 como Rama heredada, aunque sigue proporcionándole correcciones de errores y de seguridad. En los comunicados oficiales se menciona a Postfix 3.10.14, del 7 de septiembre de 2026, como la versión más reciente disponible de esta rama.

Esta clasificación distingue entre dos tipos de decisiones diferentes. Una actualización de mantenimiento, por ejemplo, de la versión 3.10.8 a un parche más reciente de la serie 3.10, mantiene la rama funcional seleccionada e incorpora sus correcciones. Por el contrario, una actualización a la versión 3.11 cambia la rama de desarrollo y, por lo tanto, debe someterse a pruebas para comprobar las funciones modificadas, la compatibilidad de la configuración, las ampliaciones y los procesos operativos. Pasar a una rama principal y secundaria superior no es automáticamente la medida adecuada para todos los sistemas en producción.

En el caso de los paquetes de Linux, además de la versión visible de Postfix, comprueba los metadatos del paquete, el registro de cambios y las notas de seguridad del proveedor del sistema operativo. Averigua allí qué correcciones contiene ese paquete concreto y si el proveedor documenta las adaptaciones hacia versiones anteriores. El anuncio del desarrollador original, por el contrario, describe la versión de Postfix y no refleja la política general de retroportabilidad de una distribución.

En lo que respecta a la planificación del mantenimiento, esto significa lo siguiente: en primer lugar, documenta la versión del paquete instalado, el canal del repositorio y las adaptaciones locales. A continuación, compara las correcciones que indica el proveedor del sistema operativo para este paquete. Solo esta comparación permite determinar si hay alguna Actualización de Postfix si es necesario pasar a la versión 3.10 o si una actualización prevista a la versión 3.11 aportaría algún beneficio técnico adicional. El punto 3.10.14 es, en este contexto, un punto de referencia de Upstream, no unas instrucciones de instalación para un sistema Linux concreto.

Función del MTA, puertos SMTP y limitaciones del sistema

Postfix es un Agente de transferencia de correo (MTA). Recibe correos electrónicos a través de SMTP, decide, en función de su configuración de enrutamiento y políticas, cómo procesarlos a continuación y transfiere los mensajes a otros servidores de correo o a rutas de entrega locales. De este modo, Postfix constituye la capa de transporte de un servidor de correo en Linux. Sin embargo, su configuración no determina automáticamente cómo los usuarios consultan sus buzones de correo ni cómo se evalúan los contenidos sospechosos.

Un servidor IMAP o POP3 proporciona buzones para los programas de correo electrónico y es un componente distinto del transporte SMTP. Del mismo modo, las funciones de Postfix no sustituyen a una solución completa de filtrado de spam o virus: dichos sistemas deben integrarse, mantenerse y supervisarse adecuadamente cuando sea necesario. Esta distinción es relevante desde el punto de vista práctico, ya que una prueba SMTP satisfactoria no garantiza ni la recuperación de un buzón ni la calidad de una comprobación del contenido.

El puerto 25 se utiliza habitualmente para el tráfico SMTP entre servidores de correo y, por lo tanto, para el funcionamiento público de los servidores MX. Los puertos 587 y 465, por el contrario, están destinados al envío de mensajes por parte de los clientes de correo, normalmente con autenticación y una definición de servicio propia. Postfix no solo trata estas funciones de forma diferente desde el punto de vista organizativo: hay algunos ajustes que no deben ni pueden aplicarse de forma generalizada a todos los servicios SMTP.

Antes de realizar cambios, necesitarás derechos de administrador, una copia de seguridad recuperable de la configuración de Postfix y un intervalo de mantenimiento que se adapte a la cola, los plazos de entrega y las aplicaciones conectadas. Además, debes determinar si el servidor envía mensajes salientes, recibe como MX público u ofrece entrega por parte del cliente. Esto Cese en el servicio evita que una decisión sobre protección de datos, pertinente para el envío de solicitudes, modifique por error el puerto 25, al que se puede acceder públicamente.

TLSRPT complementa el envío seguro de correos electrónicos

Postfix 3.10 ofrece compatibilidad opcional con TLSRPT en el cliente SMTP. Los dominios pueden publicar a través de DNS un destinatario para los informes TLS agregados; el RFC 8460 permite direcciones de correo electrónico y puntos finales HTTPS. Postfix solo notifica el éxito o el fracaso de los handshakes TLS, como máximo un estado final por cada conexión SMTP. No se registran los intentos fallidos de establecimiento de conexión ni las interrupciones antes o después del handshake TLS.

Sin embargo, el número de versión 3.10 por sí solo no demuestra que un paquete de Postfix instalado pueda utilizar realmente TLSRPT. Esta función requiere que Postfix se haya compilado con una biblioteca de cliente compatible con TLSRPT y la opción de compilación USE_TLSRPT se ha creado. Por lo tanto, antes de planificar la configuración, debes comprobar, basándote en la documentación del paquete, las características de compilación indicadas y los paquetes adicionales disponibles, si tu distribución incluye esta compatibilidad.

TLSRPT complementa los procedimientos que influyen realmente en la protección TLS de una entrega. STARTTLS permite negociar un cifrado de transporte. DANE utiliza entradas TLSA y requiere DNSSEC para sus supuestos de seguridad; MTA-STS publica una política sobre las características TLS esperadas. Si falla un requisito vinculante de DANE o MTA-STS, TLSRPT puede proporcionar información posterior sobre dichos errores. Sin embargo, no activa por sí mismo ni el cifrado ni la verificación de certificados.

En este contexto, hay que distinguir entre dos funciones. El dominio receptor publica un Punto final de rua y se encarga de gestionar o encargar la recepción supervisada de los mismos, así como del análisis de los informes recibidos. Por el contrario, un técnico de análisis de mensajes (MTA) que envía informes necesita un Postfix configurado y activado adecuadamente, así como una infraestructura independiente que recopile, recupere y agregue eventos, y envíe informes. Estas dos funciones pueden estar separadas desde el punto de vista organizativo; el titular de un dominio que publica informes no tiene por qué generar él mismo los informes TLSRPT en el mismo sistema.

Por lo tanto, un complemento de política TLS no forma parte, por regla general, de todas las cadenas de informes TLSRPT. Postfix es compatible con DANE por sí mismo. Un complemento adecuado cobra especial relevancia cuando el MTA remitente incluye información de política MTA-STS a través de smtp_tls_policy_maps . Postfix 3.10 amplía las respuestas de este tipo de complementos con atributos relacionados con TLSRPT; sin embargo, esto no implica que todas las instalaciones necesiten un complemento, ni que TLSRPT esté integrado en todos los paquetes de la versión 3.10.

Además, TLSRPT no es un sistema de monitorización en tiempo real. La guía de Postfix indica que, de media, transcurren unas doce horas hasta que se recibe un mensaje de error y, por lo tanto, distingue expresamente los informes de la monitorización de fallos agudos. Para los problemas de entrega en curso, siguen siendo necesarios la comprobación de las colas, el análisis de los registros y las alertas. TLSRPT ayuda sobre todo a poner de manifiesto patrones recurrentes y problemas de políticas a lo largo de numerosos intentos de entrega.

Preparar la actualización de Postfix en la rama 3.10

Una actualización dentro de Postfix 3.10 es una tarea de mantenimiento con una situación inicial clara: se actualiza una rama heredada existente al estado de parches proporcionado por tu distribución. Antes de realizar la intervención, haz una copia de seguridad de la configuración de Postfix y planifica una ventana de mantenimiento. Comprueba además si el servidor gestiona envíos salientes, tráfico MX o el servicio Submission, ya que de ello dependen el control y el plan de contingencia.

En primer lugar, averigua la versión de Postfix instalada o la que se ha consultado con el programa ejecutado y anótala explícitamente en main.cf parámetros establecidos. Los dos primeros comandos sirven para realizar un análisis inicial. postfix check Por el contrario, se trata de un comando de mantenimiento administrativo: comprueba, en particular, los derechos de propiedad y acceso a los archivos y directorios, y puede crear los directorios que falten. Por lo tanto, ejecútalo con los derechos administrativos correspondientes y no dando por sentado que el sistema de archivos no ha sufrido modificaciones.

postconf mail_version
postconf -n
postfix check

La edición de postconf mail_version indica la versión del núcleo de Postfix que se ha ejecutado. postconf -n muestra parámetros con valores explícitos name=value-Entradas en main.cf. Esto puede incluir también ajustes cuyo valor se corresponde con el valor predeterminado actualmente instalado; por lo tanto, el resultado no constituye una prueba fehaciente de una desviación real respecto al valor predeterminado. Además, tras un cambio de versión, los valores predeterminados pueden variar, mientras que una entrada establecida previamente se mantiene.

También postfix check No se trata de una validación completa de la configuración del servidor de correo. El comando puede informar de problemas con los permisos de directorios o archivos y generar directorios que faltan, pero no evalúa de forma exhaustiva la corrección técnica de todos los parámetros. Las cadenas de certificados, los mapas externos, las dependencias de DNS, los filtros, la autenticación y la integración de los servicios conectados deben comprobarse por separado.

Para actualizar el paquete, utiliza el método de actualización recomendado por tu distribución. Consulta los metadatos del paquete, el registro de cambios y las notas de seguridad para comprobar qué correcciones y posibles adaptaciones hacia versiones anteriores incluye ese paquete concreto. Compara esta información con los anuncios del desarrollador original. No deduzcas que falta un parche basándote únicamente en una cadena de versión abreviada.

La obligación específica de actualizar el proceso, documentada por Postfix, se refiere a la actualización desde una rama de desarrollo anterior a Postfix 3.10.0. Debido a un cambio en el protocolo interno del agente de entrega, a partir de entonces es necesario, como mínimo, postfix reload o es necesario realizar una parada seguida de un arranque; de lo contrario, los repartidores podrían encontrarse ante una situación inesperada smtputf8-Atributo «advertir». Este razonamiento no puede aplicarse de forma generalizada a todas las actualizaciones posteriores de la versión 3.10.

En el caso de las actualizaciones de mantenimiento dentro de la rama 3.10, comprueba en su lugar si la herramienta de paquetes ya ha recargado o reiniciado el servicio según lo establecido por la distribución y si los procesos en ejecución corresponden a la versión actualizada. Si no es así, utiliza la recarga o el reinicio previstos por la distribución y el paquete. A continuación, comprueba la cola y los registros en la ventana de mantenimiento, en lugar de dar por sentado un comando de activación concreto independientemente del comportamiento del paquete.

Planificar TLSRPT con DNS e infraestructura de informes

En TLSRPT, es necesario planificar por separado el rol del dominio receptor de los informes y el rol de un MTA informador. Un dominio que desee recibir informes sobre las entregas realizadas en su propia infraestructura publica un Punto final de rua en el DNS y garantiza que su recepción, protección, almacenamiento y análisis se gestionen de forma vinculante. De este modo, el registro TXT describe a dónde deben dirigir sus informes agregados los demás MTA emisores.

Un MTA que deba generar por sí mismo informes TLSRPT necesita, independientemente de ello, un paquete Postfix que incluya una biblioteca de cliente TLSRPT y USE_TLSRPT se compiló. La indicación «Postfix 3.10» solo confirma a partir de qué rama está disponible la integración; no indica la característica de compilación de un paquete binario concreto. Por lo tanto, consulta la documentación del paquete, la información de compilación y los paquetes adicionales disponibles en tu distribución antes de planificar el uso de la función.

En cada sistema Postfix participante se ejecuta un proceso local Coleccionista los eventos transmitidos por la biblioteca TLSRPT integrada a través de un socket de dominio Unix local. El «Fetcher», la agregación central y el generador de informes pueden funcionar de forma independiente: Recogen los datos recopilados, elaboran los resúmenes previstos y envían los informes a los destinos publicados por los dominios destinatarios. Estos componentes posteriores pueden estar centralizados en otros sistemas; sin embargo, esto no sustituye al colector local del sistema Postfix correspondiente.

A Complemento de políticas solo es necesario adicionalmente en determinados casos por parte del remitente. Si el MTA utiliza la información de la política MTA-STS a través de smtp_tls_policy_maps, el complemento utilizado para ello debe ser compatible con los atributos relacionados con TLSRPT. Postfix es compatible con DANE por sí mismo. Por lo tanto, ni la entrada DNS de un dominio receptor ni el procesamiento de informes de un MTA adecuado requieren, de forma generalizada, un complemento MTA-STS.

La siguiente entrada explica exclusivamente la sintaxis DNS para un destinatario de informes. example.invalid No es, a propósito, un dominio productivo y no debe copiarse tal cual. La etiqueta v=TLSRPTv1 caracteriza el procedimiento; rua Aquí se especifica un destino para los informes. El RFC 8460 permite, además del correo electrónico, puntos finales HTTPS.

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Para los informes TLSRPT, Postfix 3.10 describe el encabezado TLS-Required: no, para que el informe pueda rebajarse al nivel de seguridad TLS „may“ durante la transmisión. Esta excepción, estrictamente limitada, evita que un informe de error fracase incluso ante una configuración estricta de TLS. No constituye una indicación para rebajar los requisitos de TLS en el caso de los correos electrónicos habituales de la empresa o de los usuarios.

Proteger el envío de datos, evaluar de forma específica las opciones de TLS

El escenario smtpd_hide_client_session Se aplica al envío autenticado desde un cliente de correo electrónico. Si está activada, el servidor SMTP genera encabezados «Received:» sin incluir información de la sesión del cliente. Dependiendo de la sesión, esto permite ocultar del encabezado, por ejemplo, el nombre de host y la dirección IP del cliente, los datos de la sesión TLS, la información de inicio de sesión SASL y los detalles del registro SMTP.

Ordena estos Función de protección de datos una definición de servicio de envío específica para el puerto 587 o 465, en lugar de aplicarla de forma global en main.cf para activarlo. El MTA público del puerto 25 desempeña otra función en el transporte de servidor a servidor. La documentación de Postfix exige el valor por defecto en este caso, para que se sigan cumpliendo los requisitos del RFC 5321.

Por lo tanto, la decisión no solo afecta a la privacidad, sino también a la trazabilidad y a los límites del servicio. Para los clientes autenticados, la reducción de metadatos innecesarios puede resultar adecuada. Sin embargo, en un servidor MX público, esa misma configuración incumpliría las expectativas documentadas respecto a la información del campo «Received:». Por lo tanto, comprueba los servicios y los listeners por separado, así como sus respectivos parámetros, en lugar de aplicar una regla global única.

Postfix 3.10.0 incluye además una adaptación para OpenSSL 3.5 y su sintaxis de grupos para la criptografía postcuántica. Si se desea delegar deliberadamente la selección de grupos por completo a la configuración de OpenSSL gestionada de forma centralizada, es necesario tls_eecdh_auto_curves y tls_ffdhe_auto_groups Ambos deben estar vacíos. Solo con esta configuración conjunta se deja la elección en manos de OpenSSL; Postfix no reproduce por sí mismo la nueva sintaxis de OpenSSL.

Vaciar ambos parámetros automáticos es un Caso especial Para configuraciones de cifrado gestionadas de forma centralizada; no se trata de una recomendación general de refuerzo de la seguridad. Solo resulta adecuado si se conoce, se ha versionado y se ha probado la configuración efectiva de OpenSSL. Si no se lleva a cabo este control, el traspaso de la selección puede ocultar configuraciones erróneas o generar características TLS inesperadas; en ese caso, las configuraciones explícitas de Postfix resultan más transparentes.

Comprobar el estado de las actualizaciones y los errores conocidos

La indicación de versión 3.10 por sí sola no describe un estado técnico uniforme. Lo decisivo es la versión concreta del parche, la información del registro de cambios del paquete de distribución y, en su caso, las correcciones retroportadas. Postfix 3.10.14 se anunció el 7 de septiembre de 2026 como versión heredada, junto con otras ramas que siguen recibiendo mantenimiento. Esto no implica que todos los paquetes de Linux incluyan ya este estado del código original.

Un ejemplo concreto es Postfix 3.10.6: esta versión corrigió un problema relacionado con TLS obligatorio: no y el modo „wrapper“ de TLS del lado del cliente. La implementación anterior podía afectar a este tipo de conexiones; la corrección las trata con el nivel de seguridad «encrypt». Por lo tanto, quienes utilicen el modo envoltorio SMTPS deberían comprobar el estado de los parches y la vía de transmisión realmente utilizada, en lugar de deducir el mismo comportamiento a partir de «3.10».

El anuncio del 3 de octubre de 2014 menciona, entre otras cosas, correcciones y refuerzos de seguridad para una vulnerabilidad de «SMTP-Smuggling» relacionada con smtpd_proxy_filter. No se trata de una afirmación generalizada de que todos los servidores de correo se vean afectados: el parámetro está desactivado de forma predeterminada, y su relevancia depende de la configuración local, así como de la arquitectura de filtrado previa o conectada. Por lo tanto, comprueba primero si esta función se está utilizando de forma activa.

En caso de que se detecte un problema en la entrega, la resolución de errores debe seguir un orden lógico: primero comprueba las desviaciones efectivas y la validación de la configuración; a continuación, comprueba si se ha realizado la recarga tras una actualización. A continuación, revisa la cola y los registros en busca de mensajes recurrentes relacionados con TLS, la conexión o los mensajes diferidos. Una guía sistemática para Análisis de los registros de Postfix Ayuda a asignar eventos concretos a un ID de cola y a su intento de entrega.

Advertencia: Un cambio de versión no sustituye al análisis de las causas. Una recarga no soluciona ni las cadenas de certificados no válidas, ni los errores de DNS, ni las reglas de enrutamiento inadecuadas. Por el contrario, si no se realizan las recargas necesarias tras una actualización, los procesos o configuraciones modificados pueden pasar desapercibidos durante el funcionamiento. Por lo tanto, documenta conjuntamente el estado de los parches, la fuente del paquete, la fecha de activación y los mensajes de registro observados.

Cómo evaluar correctamente los informes TLSRPT durante el funcionamiento

Los informes TLSRPT tienen un retraso y no sustituyen a la supervisión en tiempo real. La documentación de Postfix indica que, de media, transcurren unas doce horas hasta que se recibe un informe de error. En Postfix, los resultados registrados se refieren a los handshakes TLS; no se incluyen los errores de establecimiento de conexión ni las interrupciones que se producen antes o después del handshake. Para incidentes graves, siguen siendo necesarios la supervisión de colas, el análisis de registros y las alertas.

La reutilización también limita el recuento: una conexión SMTP reutilizada no genera ningún nuevo protocolo de enlace TLS. En el caso de las sesiones TLS reanudadas, Postfix 3.10 omite el registro de forma predeterminada; para ello es determinante el parámetro smtp_tlsrpt_skip_reused_handshakes. Por lo tanto, los datos agregados de los informes no constituyen ni un recuento completo de todas las conexiones SMTP ni una tasa de mensajes o de entrega. Evalúa los tipos de error, los dominios de los destinatarios, los periodos de tiempo y los patrones recurrentes junto con los registros del servidor.

El envío técnico de un informe no aporta por sí solo ningún beneficio. Establece de antemano quién se encarga del destinatario de RUA, quién recibe y almacena los informes y durante cuánto tiempo se conservan los datos. Dado que los informes pueden contener información sobre sesiones TLS, el plan operativo debe incluir derechos de acceso, normas de protección de datos y un procedimiento de eliminación. También debe existir una norma de escalación para los errores recurrentes.

Por lo tanto, el análisis combina dos niveles: TLSRPT muestra tendencias resumidas a lo largo de un periodo de tiempo, mientras que los registros del servidor de correo proporcionan el historial concreto de cada intento de entrega. Para la supervisión continua, el Guía práctica para la supervisión de los registros de Postfix los informes sobre métodos para clasificar los mensajes de error y las colas. Las alarmas automáticas deberían reaccionar ante datos operativos en tiempo real, y no esperar a recibir los agregados TLSRPT.

Si no se ha previsto un destinatario responsable, un repositorio seguro ni un análisis periódico, la publicación en TLSRPT debería planificarse primero, en lugar de activarse precipitadamente. Responsabilidad en la elaboración de informes forma parte de la función de seguridad: solo la asignación de un error a la entidad competente permite dar una respuesta trazable, por ejemplo, ante una política MTA-STS caducada o ante problemas con los datos TLSA.

Actualizar la versión 3.10 o cambiar a la 3.11

La elección entre mantener los parches o cambiar de rama depende de la situación inicial y del objetivo operativo. En el momento de la investigación, Postfix 3.10 sigue siendo una rama heredada que sigue recibiendo mantenimiento, mientras que 3.11 es la rama de desarrollo estable. Por lo tanto, las correcciones periódicas dentro de la versión 3.10 resultan útiles para las instalaciones existentes; sin embargo, no equivalen a una actualización funcional a la versión 3.11.

La actualización a la versión 3.11 está justificada, sobre todo, cuando se necesitan sus funciones o el estado objetivo a largo plazo. Las salidas REQUIRETLS y JSON de determinadas herramientas de administración están documentadas como características de la rama más reciente y no deben planificarse como características de Postfix 3.10. Antes de cambiar de rama, hay que comprobar la compatibilidad de los parámetros de configuración, los filtros conectados, la autenticación y la automatización.

Para un sistema 3.10 estable que no requiera nuevas funcionalidades, es actualización continua de parches la medida más adecuada en cada caso. No obstante, requiere un proceso controlado que incluya copias de seguridad, comprobación de paquetes, validación, verificación de la activación del proceso y supervisión. Por el contrario, un cambio de rama requiere un motivo técnico y una ventana de mantenimiento planificada; el mero hecho de que el número de versión sea más alto no constituye un criterio de decisión suficiente.