Postfix, VPN, dan smarthost: antrean bukan firewall

Menahan surat di antrean sampai VPN naik adalah masalah penjadwalan, dan solusi biasanya menghentikan Postfix, menukar main.cf, lalu menjalankannya lagi. Itu berhasil, dan itu bentuk yang salah, karena mencampur dua kebutuhan: kapan pengiriman harus dicoba, dan jalur jaringan mana yang boleh membawanya. Yang kedua adalah keputusan firewall, dan tidak ada direktif Postfix yang bisa mengambilnya. Setelah keduanya dipisahkan, masing-masing punya jawaban kecil dan bisa diuji.

Jaga tujuan relay tetap stabil, blokir pengiriman langsung di batas jaringan, dan biarkan antrean melakukan penantian.

Dua kebutuhan yang orang gabungkan jadi satu

Relay memberi tahu Postfix ke mana surat harus diserahkan; relayhost = [smtp.corp.example]:587 menyebut host dan port, dengan tanda kurung yang menekan pemilihan berbasis MX untuk hop berikutnya. Jalur memberi tahu kernel ke mana paket boleh pergi. relayhost yang benar tanpa batasan jalur tetap membiarkan Postfix mencapai internet langsung ketika tabel routing kebetulan mengizinkannya, dan firewall yang benar dengan relayhost salah mengirim surat ke tempat yang salah. Tidak satu pun menyiratkan yang lain.

Peta transport, penggantian per pengirim, dan relay cadangan masing-masing layak dibaca dengan cara yang sama. relayhost yang stabil bukan bukti bahwa setiap rute pengiriman yang dikonfigurasi memakainya, dan rute cadangan yang melewati relay adalah kegagalan yang sama dengan kamuflase lebih baik.

Apa yang sebenarnya dilakukan defer_transports

defer_transports menahan pesan untuk transport yang disebutkan sehingga tidak ada upaya pengiriman sampai satu putaran antrean menyentuhnya. Itu kendali penjadwalan, dan pengosongan antrean mengalahkannya; itu memang desainnya, bukan cacat. Gunakan nama transport sebenarnya dari master.cf, karena transport khusus atau transport relay yang dinamai terpisah tidak tercakup hanya karena programnya juga berbicara SMTP. Percobaan ulang biasa adalah mekanisme lain: dengan jalur fail-closed, upaya pengiriman langsung gagal dan tetap di antrean, tanpa direktif penundaan.

Kegagalan permanen tidak menunggu dengan sopan. Penerima buruk atau kredensial yang ditolak memantul atau tersangkut sebagai kesalahan keras alih-alih duduk sampai terowongan muncul, jadi antrean penuh surat tertunda tidak otomatis antrean yang aman.

Tegakkan jalur di lapisan jaringan

Pembatasan itu tempatnya di batas keluaran lokal atau di dalam namespace jaringan terisolasi. Itu harus mencakup alamat asli relay, transport, dan port, termasuk IPv6 jika diaktifkan, karena aturan yang memblokir TCP 25 tidak melakukan apa pun untuk relay pada 587 atau 465. Jaga loopback dan jalur pengiriman lokal tetap terpisah agar antrean itu sendiri terus bekerja. Kebijakan harus tetap tertutup ketika rute terowongan hilang atau muncul lagi dengan nama antarmuka lain.

Peristiwa antarmuka naik tidak membuktikan relay dapat dijangkau melaluinya. Karena itu hook yang memeriksa tautan lalu mengosongkan antrean adalah kemudahan, bukan jaminan: tautan bisa berubah antara pemeriksaan dan upaya pengiriman.

Buktikan dengan satu pesan tak berbahaya

Kirim satu pesan tak berbahaya saat VPN mati, lalu periksa postqueue -p untuk alasan penundaan dan ID antrean. Pulihkan jalur yang dimaksud dan minta putaran antrean terkendali, sambil mengamati apakah pesan keluar lewat relay dan bukan ke tempat lain. Lalu putuskan jalur lagi di tengah penerbangan dan pastikan pesan kembali ke antrean. Tinjau maximal_queue_lifetime sebelum memutuskan berapa lama gangguan boleh berlangsung, karena nilai nol berarti satu percobaan, bukan penyimpanan tanpa batas.

Pantau usia antrean dan pemakaian disk. Kebijakan yang menunggu VPN berubah menjadi gangguan surat jika tidak ada yang menyadari antrean bertambah sejak Jumat.

Catat relay, transport, aturan firewall, dan masa hidup bersama-sama. Keempatnya menggambarkan tatanan; salah satu saja hanya menggambarkan dugaan.