Postfix 3.10: Atualizações, TLSRPT e o caminho para a versão 3.11

Situar cronologicamente o Postfix 3.10

À data da pesquisa, 20 de outubro de 2026, o Postfix 3.10 não é o ramo de desenvolvimento estável atual: essa função cabe ao Postfix 3.11. O fabricante lista a versão 3.10 como Ramo Legacy, mas continua a fornecer-lhe correções de erros e de segurança. Nos comunicados oficiais, o Postfix 3.10.14, de 7 de setembro de 2026, é referido como a versão mais recente disponível para esta ramificação.

Esta classificação distingue duas decisões diferentes. Uma atualização de manutenção, por exemplo, da versão 3.10.8 para um patch mais recente da série 3.10, mantém o ramo funcional selecionado e incorpora as respetivas correções. Por outro lado, uma atualização para a versão 3.11 muda o ramo de desenvolvimento e, por isso, deve ser verificada quanto a alterações nas funcionalidades, compatibilidade de configuração, extensões e procedimentos operacionais. Um ramo principal e secundário superior não é, automaticamente, a medida adequada para todos os sistemas produtivos.

No caso dos pacotes Linux, além da versão visível do Postfix, verifica os metadados do pacote, o registo de alterações e as notas de segurança do fornecedor do sistema operativo. Verifica aí quais as correções que este pacote específico contém e se o fornecedor documenta os backports. Por outro lado, o anúncio do upstream descreve o lançamento do Postfix e não comprova a existência de uma política geral de backports de uma distribuição.

No que diz respeito ao planeamento da manutenção, isto significa: documente, em primeiro lugar, a versão do pacote instalado, o canal do repositório e as adaptações locais. Em seguida, compare as correções que o fornecedor do sistema operativo indica para este pacote. Só esta comparação revela se existe uma atualização pendente Atualização do Postfix se é necessário atualizar para a versão 3.10 ou se uma atualização planeada para a versão 3.11 traria algum benefício técnico adicional. O ponto 3.10.14 constitui, neste contexto, um ponto de referência a montante, não sendo um manual de instalação para um sistema Linux específico.

Função do MTA, portas SMTP e limites do sistema

O Postfix é um Agente de Transferência de Correio (MTA). Recebe e-mails através do SMTP, decide, com base na sua configuração de encaminhamento e políticas, como proceder ao seu processamento e encaminha as mensagens para outros servidores de e-mail ou para percursos de entrega locais. Assim, o Postfix constitui a camada de transporte de um servidor de e-mail no Linux. No entanto, a sua configuração não determina automaticamente como os utilizadores consultam as suas caixas de correio nem como os conteúdos suspeitos são avaliados.

Um servidor IMAP ou POP3 disponibiliza caixas de correio para programas de e-mail e é um componente distinto do transporte SMTP. Da mesma forma, as funcionalidades do Postfix não substituem uma solução completa de filtragem de spam ou vírus: esses sistemas devem ser devidamente integrados, mantidos e monitorizados, conforme necessário. Esta separação é relevante na prática, porque um teste SMTP bem-sucedido não comprova nem a consulta de uma caixa de correio nem a qualidade de uma verificação de conteúdo.

A porta 25 é normalmente utilizada para o tráfego SMTP entre servidores de e-mail e, por conseguinte, para o funcionamento público do MX. Por outro lado, as portas 587 e 465 destinam-se ao envio de mensagens por clientes de e-mail, na maioria das vezes com autenticação e uma definição de serviço própria. O Postfix não trata estas funções apenas de forma diferente do ponto de vista organizacional: algumas definições não podem, nem devem, ser aplicadas de forma generalizada a todos os serviços SMTP.

Antes de efetuar alterações, precisas de direitos administrativos, uma cópia de segurança recuperável da configuração do Postfix e uma janela de manutenção que se adapte à fila, aos prazos de entrega e às aplicações associadas. Além disso, verifica se o servidor envia mensagens, recebe como MX público ou oferece o serviço de entrega por cliente. Isto Cessação de funções impede que uma decisão de proteção de dados, que faz sentido no contexto da submissão, altere inadvertidamente a porta 25, que é acessível ao público.

O TLSRPT complementa a entrega segura de e-mails

O Postfix 3.10 oferece suporte opcional ao TLSRPT no cliente SMTP. Os domínios podem publicar, através do DNS, um destinatário para relatórios TLS agregados; a RFC 8460 permite endereços de e-mail e pontos finais HTTPS. O Postfix apenas notifica o sucesso ou o fracasso dos handshakes TLS, no máximo um estado final por ligação SMTP. As tentativas falhadas de estabelecimento de ligação e as interrupções antes ou após o handshake TLS não são registadas.

No entanto, o número de versão 3.10, por si só, não comprova que um pacote Postfix instalado possa, de facto, utilizar o TLSRPT. Esta funcionalidade pressupõe que o Postfix seja compilado com uma biblioteca cliente TLSRPT compatível e com a opção de compilação USE_TLSRPT foi criada. Por isso, antes de planear a configuração, deves verificar, com base na documentação do pacote, nas características de compilação indicadas e nos pacotes adicionais disponíveis, se a tua distribuição inclui esse suporte.

O TLSRPT complementa os procedimentos que influenciam efetivamente a proteção TLS de uma entrega. O STARTTLS permite a negociação de uma encriptação de transporte. O DANE utiliza registos TLSA e pressupõe o DNSSEC para as suas premissas de segurança; o MTA-STS publica uma política relativa às características TLS esperadas. Caso uma especificação DANE ou MTA-STS de aplicação obrigatória falhe, o TLSRPT pode fornecer notificações posteriores sobre tais erros. No entanto, não ativa nem a encriptação nem a verificação de certificados por si próprio.

Neste contexto, é necessário distinguir duas funções. O domínio destinatário publica um Ponto final da rua e gere ou encarrega alguém de assegurar a receção supervisionada e a análise dos relatórios recebidos. Por outro lado, um MTA relator necessita de um Postfix devidamente configurado e ativado, bem como de uma infraestrutura separada que recolha, recupere, agregue eventos e envie relatórios. Estas duas perspetivas podem estar separadas do ponto de vista organizacional; um titular de domínio que publique relatórios não tem de gerar ele próprio os relatórios TLSRPT no mesmo sistema.

Por isso, um plugin de política TLS não faz parte, de forma geral, de todas as cadeias de relatórios TLSRPT. O Postfix suporta o DANE por si próprio. Um plugin adequado torna-se particularmente relevante quando o MTA remetente fornece informações de política MTA-STS através de smtp_tls_policy_maps . O Postfix 3.10 amplia as respostas desse tipo de plugin com atributos relacionados com o TLSRPT; no entanto, isso não significa que todas as instalações necessitem de um plugin, nem que o TLSRPT esteja integrado em todos os pacotes 3.10.

Além disso, o TLSRPT não é um sistema de monitorização em tempo real. O manual do Postfix indica que, em média, demoram cerca de doze horas até à chegada de uma mensagem de erro e, por isso, distingue expressamente os relatórios da monitorização de falhas agudas. Para problemas de entrega em curso, continuam a ser necessárias a verificação da fila, a análise dos registos e o envio de alertas. O TLSRPT ajuda, sobretudo, a identificar padrões recorrentes e problemas de política ao longo de várias tentativas de entrega.

Preparar a atualização do Postfix no ramo 3.10

Uma atualização no Postfix 3.10 é uma tarefa de manutenção com um ponto de partida claro: atualizas um ramo legado existente para o nível de patches disponibilizado pela tua distribuição. Antes de procederes, faz uma cópia de segurança da configuração do Postfix e planeia uma janela de manutenção. Verifique também se o servidor fornece envios de saída, tráfego MX ou o serviço Submission, pois disso dependem o controlo e o plano de contingência.

Em primeiro lugar, determine a versão do Postfix instalada ou a versão solicitada pelo programa executado e registe-a explicitamente em main.cf parâmetros definidos. Os dois primeiros comandos servem para fazer um balanço da situação. postfix check Por outro lado, trata-se de um comando de manutenção administrativa: controla, nomeadamente, os direitos de propriedade e de acesso a ficheiros e diretórios e pode criar diretórios em falta. Por isso, execute-o com os direitos administrativos previstos e não partindo do princípio de que o sistema de ficheiros está garantidamente inalterado.

postconf mail_version
postconf -n
postfix check

A edição de postconf mail_version indica a versão do núcleo do Postfix que foi iniciado. postconf -n mostra parâmetros com valores explícitos name=value-entradas em main.cf. Isso pode incluir também configurações cujo valor corresponde ao padrão atualmente instalado; por conseguinte, o resultado apresentado não constitui uma prova segura de um desvio efetivo em relação ao valor por defeito. Além disso, após uma atualização de versão, os valores por defeito podem alterar-se, enquanto uma configuração definida anteriormente permanece inalterada.

Também postfix check não constitui uma validação completa da configuração do servidor de e-mail. O comando pode indicar problemas com direitos de diretório ou de ficheiro e gerar diretórios em falta, mas não avalia de forma abrangente a correção técnica de todos os parâmetros. As cadeias de certificados, os mapas externos, as dependências de DNS, os filtros, a autenticação e a integração de serviços ligados devem ser verificados separadamente.

Para atualizar o pacote, utiliza o método de atualização suportado pela tua distribuição. Verifica nos metadados do pacote, no registo de alterações e nas notas de segurança quais as correções e eventuais backports que esse pacote específico apresenta. Compare estas informações com os anúncios do desenvolvedor original. Não conclua que falta um patch apenas com base numa sequência de versão abreviada.

A obrigação específica, documentada pelo Postfix, de atualizar o processo diz respeito à atualização de um ramo de desenvolvimento mais antigo para o Postfix 3.10.0. Devido a uma alteração no protocolo interno do agente de entrega, a partir daí é necessário, no mínimo, postfix reload ou é necessária uma paragem seguida de um arranque; caso contrário, os agentes de entrega podem, perante uma situação inesperada, smtputf8-Atributo «avisar». Esta justificação não pode ser aplicada de forma generalizada a todas as atualizações de patch posteriores no âmbito da versão 3.10.

No caso de atualizações de manutenção na ramificação 3.10, verifica, em vez disso, se a ferramenta de pacotes já recarregou ou reiniciou o serviço de acordo com a distribuição e se os processos em execução correspondem à versão atualizada. Se não for esse o caso, utiliza o recarregamento ou o reinício previstos pela distribuição e pelo pacote. Em seguida, verifica a fila e os registos na janela de manutenção, em vez de pressupor um comando de ativação específico, independentemente do comportamento do pacote.

Planear o TLSRPT com o DNS e a infraestrutura de relatórios

No TLSRPT, a função do domínio destinatário dos relatórios e a função de um MTA emissor de relatórios têm de ser definidas separadamente. Um domínio que pretenda receber relatórios sobre entregas na sua própria infraestrutura publica um Ponto final da rua no DNS e garante que a sua receção, proteção, armazenamento e análise sejam geridos de forma vinculativa. O registo TXT descreve, assim, para onde os outros MTAs remetentes devem enviar os seus relatórios agregados.

Um MTA que deva gerar ele próprio relatórios TLSRPT necessita, independentemente disso, de um pacote Postfix que inclua uma biblioteca cliente TLSRPT e USE_TLSRPT foi compilado. A indicação «Postfix 3.10» apenas confirma a partir de que ramo a integração está disponível; não indica a característica de compilação de um pacote binário específico. Por isso, verifica a documentação do pacote, as informações de compilação e os pacotes adicionais disponíveis na tua distribuição antes de planear a utilização da função.

Em cada sistema Postfix envolvido, existe um Colecionador os eventos transmitidos pela biblioteca TLSRPT integrada através de um socket de domínio Unix local. Independentemente disso, o Fetcher, a agregação central e o gerador de relatórios podem ser operados: Estes recuperam os dados recolhidos, criam os resumos previstos e enviam relatórios para os destinos publicados pelos domínios destinatários. Estes componentes a jusante podem estar centralizados noutros sistemas; no entanto, o coletor local no respetivo sistema Postfix não pode ser substituído por eles.

A Plugin de políticas só é necessário em determinados cenários do lado do remetente. Se o MTA utilizar informações da política MTA-STS através de smtp_tls_policy_maps, o plugin utilizado para o efeito tem de suportar os atributos relacionados com o TLSRPT. O DANE é suportado pelo próprio Postfix. Por conseguinte, nem o registo DNS de um domínio destinatário nem o processamento de relatórios de um MTA devidamente configurado exigem, de forma generalizada, um plugin MTA-STS.

A entrada seguinte explica exclusivamente a sintaxe DNS para um destinatário de relatório. example.invalid não é, intencionalmente, um domínio produtivo e não deve ser copiado tal como está. A etiqueta v=TLSRPTv1 caracteriza o procedimento; rua indica aqui um destino para os relatórios. A RFC 8460 permite, além do e-mail, também pontos finais HTTPS.

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

Para relatórios TLSRPT, o Postfix 3.10 define o cabeçalho TLS-Required: no, para que o relatório possa recuar para o nível de segurança TLS „may“ durante a transmissão. Esta exceção estritamente limitada evita que um relatório de erro falhe devido a uma especificação TLS rigorosa. Não se trata de uma instrução para reduzir os requisitos TLS para e-mails comerciais ou de utilizadores normais.

Proteger o envio de dados, avaliar as opções TLS de forma específica

A definição smtpd_hide_client_session Destina-se ao envio autenticado por cliente de e-mail. Se estiver ativada, o servidor SMTP gera cabeçalhos «Received:» sem informações da sessão do cliente. Dependendo da sessão, isso permite ocultar do cabeçalho, por exemplo, o nome de host e o endereço IP do cliente, os dados da sessão TLS, as informações de início de sessão SASL, bem como os detalhes do registo SMTP.

Ordena estes Funcionalidade de proteção de dados através de uma definição de serviço de submissão dedicada para a porta 587 ou 465, em vez de o fazer de forma global e genérica em main.cf para ativar. O MTA público da porta 25 desempenha um papel diferente no transporte de servidor para servidor. A documentação do Postfix exige, nesse caso, o valor padrão, para que os requisitos da RFC 5321 continuem a ser cumpridos.

A decisão diz, portanto, respeito não só à privacidade, mas também à rastreabilidade e aos limites do serviço. Para clientes autenticados, a redução de metadados desnecessários pode ser adequada. Num MX público, no entanto, essa mesma configuração violaria a expectativa documentada relativamente às informações «Received:». Por isso, verifica serviços separados, ouvintes e os seus respetivos parâmetros, em vez de uma regra global única.

O Postfix 3.10.0 inclui ainda uma adaptação ao OpenSSL 3.5 e à sua sintaxe de grupos para a criptografia pós-quântica. Caso se pretenda delegar totalmente a seleção de grupos à configuração do OpenSSL gerida centralmente, é necessário tls_eecdh_auto_curves e tls_ffdhe_auto_groups ambos devem estar vazios. Só com esta configuração comum é que o OpenSSL fica encarregado da seleção; o Postfix não reproduz por si próprio a nova sintaxe do OpenSSL.

Esvaziar ambos os parâmetros automáticos é um Caso especial para configurações de criptografia geridas centralmente; não se trata de uma recomendação geral de reforço de segurança. Só é adequado se a configuração efetiva do OpenSSL for conhecida, identificada por versão e testada. Na ausência deste controlo, a transferência da seleção pode ocultar configurações incorretas ou gerar comportamentos TLS inesperados; nesse caso, as definições explícitas do Postfix continuam a ser mais fáceis de rastrear.

Verificar o estado das atualizações e os erros conhecidos

A indicação da versão 3.10, por si só, não descreve um estado técnico uniforme. São determinantes a versão específica do patch, as informações do registo de alterações do pacote de distribuição e, se for o caso, as correções retroportadas. O Postfix 3.10.14 foi anunciado a 7 de setembro de 2026 como uma versão legada, juntamente com outras ramificações mantidas. Isso não significa que todos os pacotes Linux já incluam esta versão do upstream.

Um exemplo concreto é o Postfix 3.10.6: esta versão corrigiu um problema relacionado com TLS obrigatório: não e o modo „wrapper“ TLS do lado do cliente. A implementação anterior podia afetar essas ligações; a correção trata-as com o nível de segurança «encrypt». Quem utilizar o modo wrapper SMTPS deve, por isso, verificar as versões atualizadas e o canal de transmissão efetivamente utilizado, em vez de deduzir o mesmo comportamento com base na versão «3.10».

O anúncio de 3 de outubro de 2014 menciona, entre outras coisas, correções e reforços de segurança para um cenário de «SMTP smuggling» envolvendo o smtpd_proxy_filter. Isto não significa, de forma generalizada, que todos os servidores de e-mail estejam afetados: o parâmetro está desativado por predefinição e a relevância depende da configuração local, bem como da arquitetura de filtragem a montante ou integrada. Por isso, verifica primeiro se esta função está, de facto, a ser utilizada ativamente.

No caso de uma entrega anómala, a procura de erros deve seguir uma sequência lógica: primeiro, verifica os desvios efetivos e a validação da configuração; depois, verifica se a recarga foi efetuada após uma atualização. Em seguida, analisa a fila e os registos para detetar mensagens recorrentes relacionadas com TLS, ligações ou mensagens diferidas. Um guia sistemático para a Análise dos registos do Postfix ajuda a associar eventos individuais a um ID de fila e à respetiva tentativa de entrega.

Aviso: Uma atualização de versão não substitui uma análise das causas. Uma recarga não resolve nem cadeias de certificados inválidas, nem erros de DNS, nem regras de encaminhamento inadequadas. Por outro lado, a falta de recargas após uma atualização pode ocultar processos ou configurações alteradas em produção. Por isso, documente em conjunto o estado das correções, a origem do pacote, a data e hora da ativação e as mensagens de registo observadas.

Avaliar corretamente os relatórios TLSRPT durante o funcionamento

Os relatórios TLSRPT são diferidos e não substituem a monitorização em tempo real. A documentação do Postfix indica que, em média, demoram cerca de doze horas até à chegada de um relatório de erro. No Postfix, os resultados registados referem-se aos handshakes TLS; não são incluídos os erros de estabelecimento de ligação nem as interrupções antes ou depois do handshake. Para incidentes graves, continuam a ser necessários a monitorização da fila, a análise dos registos e o sistema de alertas.

A reutilização também limita a contagem: uma ligação SMTP reutilizada não gera mais nenhum handshake TLS. No caso de sessões TLS retomadas, o Postfix 3.10 ignora o registo por predefinição; para tal, é determinante a opção smtp_tlsrpt_skip_reused_handshakes. Os agregados de relatórios não representam, portanto, nem o número total de todas as ligações SMTP, nem uma taxa de mensagens ou de entrega. Analise os tipos de erros, os domínios dos destinatários, os períodos de tempo e os padrões recorrentes em conjunto com os registos do servidor.

A entrega técnica de um relatório, por si só, ainda não traz qualquer benefício. Defina antecipadamente quem é responsável pelo destinatário do RUA, quem recebe e arquiva os relatórios e por quanto tempo os dados serão conservados. Uma vez que os relatórios podem conter informações sobre sessões TLS, os direitos de acesso, as normas de proteção de dados e um procedimento de eliminação devem fazer parte do plano operacional. Deve também existir uma regra de escalamento para erros recorrentes.

A análise combina, portanto, dois níveis: o TLSRPT apresenta tendências sintetizadas ao longo de um período, enquanto os registos do servidor de e-mail fornecem o histórico concreto de cada tentativa de entrega. Para a monitorização contínua, o Guia prático para a monitorização dos registos do Postfix os relatórios sobre métodos de classificação de mensagens de erro e filas de espera. Os alarmes automáticos devem reagir a dados operacionais em tempo real, e não apenas aos agregados TLSRPT recebidos.

Se não estiver previsto um destinatário responsável, um repositório seguro nem uma análise regular, a publicação no TLSRPT deve ser, em primeiro lugar, planeada, em vez de ser ativada precipitadamente. Responsabilidade pela elaboração do relatório faz parte da função de segurança: só a atribuição de uma falha a uma entidade responsável permite uma reação rastreável, por exemplo, a uma política MTA-STS caducada ou a problemas com dados TLSA.

Manter a versão 3.10 ou atualizar para a versão 3.11

A escolha entre a manutenção de patches e a mudança de ramo depende da situação inicial e dos objetivos operacionais. O Postfix 3.10 continua a ser um ramo legado com suporte, à data desta pesquisa, enquanto o 3.11 é o ramo de desenvolvimento estável. Por isso, as correções regulares na versão 3.10 fazem sentido para as instalações existentes; no entanto, não devem ser equiparadas a uma atualização funcional para a versão 3.11.

A atualização para a versão 3.11 justifica-se, sobretudo, quando as suas funcionalidades ou os objetivos a longo prazo forem necessários. As saídas REQUIRETLS e JSON de determinadas ferramentas de gestão estão documentadas como características do ramo mais recente e não devem ser consideradas funcionalidades do Postfix 3.10. Antes de uma mudança de ramo, é necessário verificar a compatibilidade dos parâmetros de configuração, dos filtros associados, da autenticação e da automatização.

Para um sistema 3.10 estável, sem necessidade de novas funcionalidades, é atualização contínua de patches a medida mais adequada no momento. No entanto, esta exige um processo controlado que inclua cópias de segurança, verificação de pacotes, validação, verificação da ativação do processo e monitorização. Por outro lado, uma mudança de ramo requer um motivo técnico e uma janela de manutenção planeada; o simples facto de o número da versão ser superior não constitui, por si só, um critério de decisão suficiente.