Postfix, VPN e um smarthost: a fila não é um firewall

Manter o correio em fila até a VPN subir é um problema de agendamento, e a solução habitual é parar o Postfix, trocar o main.cf e iniciá-lo de novo. Isso funciona e é a forma errada, porque mistura dois requisitos: quando se deve tentar a entrega e qual caminho de rede pode carregá-la. O segundo é uma decisão do firewall, e nenhuma diretiva do Postfix pode tomá-la. Uma vez separados, cada um tem uma resposta pequena e verificável.

Mantenha estável o destino do relay, bloqueie a entrega direta na fronteira da rede e deixe a fila fazer a espera.

Dois requisitos que as pessoas fundem em um

O relay diz ao Postfix onde entregar o correio; relayhost = [smtp.corp.example]:587 nomeia um host e uma porta, com colchetes que suprimem a seleção por MX para esse próximo salto. O caminho diz ao kernel onde os pacotes podem ir. Um relayhost correto sem restrição de caminho ainda deixa o Postfix chegar à internet diretamente quando a tabela de rotas permite, e um firewall correto com relayhost errado envia o correio para o lugar errado. Nenhum implica o outro.

Os mapas de transporte, as exceções por remetente e os relays de reserva merecem a mesma leitura. Um relayhost estável não é prova de que toda rota de entrega configurada o use, e uma rota de reserva que contorna o relay é a mesma falha com melhor camuflagem.

O que defer_transports realmente faz

defer_transports retém as mensagens para os transportes nomeados, de modo que nenhuma tentativa de entrega é feita até uma passagem da fila tocar nelas. É um controle de agendamento, e um esvaziamento da fila o anula; isso é o projeto e não um defeito. Use os nomes reais de transporte do master.cf, porque um transporte personalizado ou um transporte de relay com outro nome não fica coberto só porque o programa dele também fala SMTP. A nova tentativa comum é outro mecanismo: com um caminho fail-closed, as tentativas de entrega simplesmente falham e ficam na fila, sem qualquer diretiva de adiamento.

As falhas permanentes não esperam com educação. Um destinatário ruim ou uma credencial rejeitada devolve ou fica preso como erro duro em vez de aguardar o túnel aparecer, então uma fila cheia de correio adiado não é automaticamente uma fila segura.

Imponha o caminho na camada de rede

A restrição pertence à fronteira da saída local ou ao interior de um espaço de nomes de rede isolado. Deve cobrir os endereços reais do relay, o transporte e a porta, incluindo IPv6 se estiver ativo, porque uma regra que bloqueia TCP 25 não faz nada para um relay na 587 ou na 465. Mantenha separados o loopback e os caminhos de envio local para que a própria fila continue funcionando. A política deveria permanecer fechada quando a rota do túnel desaparece ou reaparece sob outro nome de interface.

Um evento de interface ativa não prova que o relay seja alcançável através dela. Por isso um hook que verifica o link e depois esvazia a fila é uma comodidade e não uma garantia: o link pode mudar entre a verificação e a tentativa de entrega.

Prove com uma só mensagem inofensiva

Envie uma mensagem inofensiva com a VPN desligada e depois inspecione postqueue -p para o motivo do adiamento e o ID da fila. Restaure o caminho previsto e peça uma passagem de fila controlada, observando se a mensagem sai pelo relay e não por outro lugar. Depois interrompa o caminho de novo em pleno voo e confirme que a mensagem volta para a fila. Reveja maximal_queue_lifetime antes de decidir quanto tempo uma interrupção pode durar, porque um valor zero significa uma tentativa e não uma retenção ilimitada.

Monitore a idade da fila e o uso de disco. Uma política que espera a VPN vira interrupção de correio se ninguém perceber que a fila cresce desde sexta-feira.

Registre o relay, o transporte, a regra do firewall e a vida útil juntos. Esses quatro descrevem o arranjo; qualquer um deles sozinho descreve uma conjectura.