Postfix, VPN, smarthost: 대기열은 방화벽이 아니다

VPN이 올라올 때까지 메일을 대기열에 두는 것은 일정 관리 문제이며, 흔한 해결책은 Postfix를 멈추고 main.cf를 바꾼 뒤 다시 시작하는 것입니다. 그것은 동작하지만, 전달을 언제 시도할지와 어떤 네트워크 경로가 그것을 운반할 수 있는지라는 두 요구를 섞기 때문에 잘못된 형태입니다. 두 번째는 방화벽의 결정이며 어떤 Postfix 지시문도 대신할 수 없습니다. 둘을 분리하면 각각 작고 검증 가능한 답이 있습니다.

릴레이 목적지를 안정적으로 유지하고, 네트워크 경계에서 직접 전달을 차단하고, 기다림은 대기열에 맡기십시오.

사람들이 하나로 합치는 두 가지 요구

릴레이는 Postfix에 메일을 어디로 넘길지 알려주고, relayhost = [smtp.corp.example]:587은 호스트와 포트를 지정하며 대괄호는 그 다음 홉에 대해 MX 기반 선택을 억제합니다. 경로는 커널에 패킷이 갈 수 있는 곳을 알려줍니다. 경로 제한이 없는 올바른 relayhost도 라우팅 테이블이 허용하면 Postfix가 인터넷에 직접 도달하게 두며, 잘못된 relayhost와 올바른 방화벽은 메일을 잘못된 곳으로 보냅니다. 어느 것도 다른 것을 함의하지 않습니다.

전송 맵, 발신자별 재정의, 대체 릴레이는 모두 같은 방식으로 읽어야 합니다. 안정적인 relayhost는 설정된 모든 전달 경로가 그것을 쓴다는 증거가 아니며, 릴레이를 우회하는 대체 경로는 더 나은 위장을 한 같은 고장입니다.

defer_transports가 실제로 하는 일

defer_transports는 지정된 전송의 메시지를 붙잡아 두어 대기열 실행이 그것들을 건드릴 때까지 전달 시도가 이루어지지 않습니다. 이것은 일정 제어이며, 대기열 플러시가 그것을 덮어쓰는 것은 설계이지 결함이 아닙니다. 사용자 지정 전송이나 별도 이름의 릴레이 전송은 그 프로그램이 SMTP도 말한다는 이유만으로 포함되지 않으므로, master.cf의 실제 전송 이름을 사용하십시오. 일반 재시도는 다른 메커니즘이며, fail-closed 경로에서는 전달 시도가 그냥 실패해 대기열에 남고 지연 지시문은 관여하지 않습니다.

영구적인 실패는 예의를 갖춰 기다리지 않습니다. 잘못된 수신자나 거부된 자격 증명은 터널이 나타날 때까지 앉아 있는 대신 반송되거나 하드 오류로 남으므로, 지연된 메일로 가득한 대기열이 자동으로 안전한 대기열은 아닙니다.

네트워크 계층에서 경로를 강제하라

제한은 로컬 출력 경계나 격리된 네트워크 이름 공간 안에 두어야 합니다. TCP 25를 막는 규칙은 587이나 465의 릴레이에는 아무 효과가 없으므로, 릴레이의 실제 주소와 전송, 포트를 포함해야 하며, 활성화된 경우 IPv6도 포함해야 합니다. 루프백과 로컬 제출 경로를 분리해 대기열 자체가 계속 동작하게 하십시오. 터널 경로가 사라지거나 다른 인터페이스 이름으로 다시 나타날 때 정책은 닫힌 상태로 유지되어야 합니다.

인터페이스가 올라왔다는 사건은 그를 통해 릴레이에 도달할 수 있음을 증명하지 않습니다. 확인과 전달 시도 사이에 링크가 바뀔 수 있으므로, 링크를 확인한 뒤 플러시하는 훅은 보장이 아니라 편의입니다.

무해한 메시지 하나로 증명하라

VPN을 내린 상태에서 무해한 메시지를 하나 보내고, 지연 이유와 대기열 ID를 postqueue -p로 확인하십시오. 의도한 경로를 복구하고 통제된 대기열 실행을 요청하며, 메시지가 다른 곳이 아니라 릴레이를 통해 나가는지 지켜보십시오. 그런 다음 비행 중에 경로를 다시 끊고 메시지가 대기열로 돌아오는지 확인하십시오. 값이 영이면 무제한 보존이 아니라 한 번의 시도를 뜻하므로, 장애가 얼마나 지속될 수 있는지 정하기 전에 maximal_queue_lifetime을 검토하십시오.

대기열의 나이와 디스크 사용량을 감시하십시오. VPN을 기다리는 정책은 금요일부터 대기열이 커지고 있다는 것을 아무도 알아차리지 못하면 메일 장애가 됩니다.

릴레이, 전송, 방화벽 규칙, 수명을 함께 기록하십시오. 그 넷이 배치를 설명하며, 그중 하나만으로는 추측을 설명합니다.