Postfix, VPN và smarthost: hàng đợi không phải tường lửa

Giữ thư trong hàng đợi cho đến khi VPN lên là một bài toán lập lịch, và giải pháp thường gặp là dừng Postfix, thay main.cf rồi khởi động lại. Cách đó chạy được, và đó là hình dạng sai, vì nó trộn hai yêu cầu: khi nào nên thử gửi, và đường mạng nào được phép mang nó. Yêu cầu thứ hai là quyết định của tường lửa, và không chỉ thị nào của Postfix có thể làm điều đó. Khi tách hai thứ ra, mỗi thứ có một câu trả lời nhỏ và kiểm chứng được.

Giữ đích của relay ổn định, chặn gửi trực tiếp ở ranh giới mạng, và để hàng đợi làm việc chờ.

Hai yêu cầu mà người ta gộp thành một

Relay cho Postfix biết nơi chuyển thư; relayhost = [smtp.corp.example]:587 chỉ ra một máy chủ và cổng, với ngoặc vuông ngăn việc chọn theo MX cho bước nhảy kế tiếp. Đường đi cho nhân biết các gói được phép đi đâu. Một relayhost đúng mà không có giới hạn đường đi vẫn để Postfix tiếp cận internet trực tiếp khi bảng định tuyến tình cờ cho phép, và một tường lửa đúng với relayhost sai lại gửi thư đến nhầm chỗ. Không cái nào bao hàm cái kia.

Bảng ánh xạ vận chuyển, ghi đè theo người gửi và relay dự phòng đều đáng được đọc theo cùng cách. Một relayhost ổn định không phải bằng chứng rằng mọi tuyến gửi đã cấu hình đều dùng nó, và tuyến dự phòng vòng qua relay chính là cùng lỗi đó trong lớp ngụy trang tốt hơn.

defer_transports thực sự làm gì

defer_transports giữ lại thư cho các vận chuyển được nêu tên, nên không có lần thử gửi nào được thực hiện cho đến khi một vòng hàng đợi chạm vào chúng. Đây là điều khiển lập lịch, và việc xả hàng đợi sẽ vượt qua nó; đó là thiết kế chứ không phải lỗi. Hãy dùng tên vận chuyển thật từ master.cf, vì một vận chuyển tùy chỉnh hay một vận chuyển relay được đặt tên riêng không được bao phủ chỉ vì chương trình của nó cũng nói SMTP. Lần thử lại thông thường là cơ chế khác: với đường đi fail-closed, các lần thử gửi chỉ đơn giản thất bại và nằm lại trong hàng đợi, không có chỉ thị hoãn nào tham gia.

Lỗi vĩnh viễn không chờ một cách lịch sự. Người nhận xấu hoặc thông tin đăng nhập bị từ chối sẽ dội lại hoặc kẹt như một lỗi cứng thay vì ngồi đợi đến khi đường hầm xuất hiện, nên một hàng đợi đầy thư bị hoãn không tự động là hàng đợi an toàn.

Bắt buộc đường đi ở tầng mạng

Giới hạn thuộc về ranh giới đầu ra cục bộ hoặc bên trong một không gian tên mạng cô lập. Nó phải bao phủ địa chỉ thật của relay, vận chuyển và cổng, kể cả IPv6 nếu được bật, vì một quy tắc chặn TCP 25 không làm gì cho một relay ở cổng 587 hay 465. Giữ loopback và các đường gửi cục bộ tách biệt để bản thân hàng đợi tiếp tục hoạt động. Chính sách nên giữ ở trạng thái đóng khi tuyến đường hầm biến mất hoặc xuất hiện lại dưới một tên giao diện khác.

Sự kiện giao diện lên không chứng minh rằng relay tiếp cận được qua nó. Đó là lý do một hook kiểm tra liên kết rồi xả hàng đợi là tiện lợi chứ không phải bảo đảm: liên kết có thể thay đổi giữa lúc kiểm tra và lúc thử gửi.

Chứng minh bằng một thông điệp vô hại

Gửi một thông điệp vô hại khi VPN đang xuống, rồi xem postqueue -p để biết lý do hoãn và ID hàng đợi. Khôi phục đường đi dự định và yêu cầu một vòng hàng đợi có kiểm soát, quan sát xem thông điệp đi ra qua relay chứ không phải nơi khác. Sau đó cắt đường đi lần nữa giữa chuyến và xác nhận thông điệp quay lại hàng đợi. Xem lại maximal_queue_lifetime trước khi quyết định một sự cố có thể kéo dài bao lâu, vì giá trị bằng không nghĩa là một lần thử chứ không phải lưu giữ vô hạn.

Theo dõi tuổi hàng đợi và mức dùng đĩa. Một chính sách chờ VPN sẽ thành sự cố thư nếu không ai nhận ra hàng đợi đã tăng từ thứ Sáu.

Ghi lại relay, vận chuyển, quy tắc tường lửa và thời gian sống cùng nhau. Bốn thứ đó mô tả cách bố trí; bất kỳ thứ nào trong chúng đứng một mình chỉ mô tả một phỏng đoán.