Postfix, VPN ve bir smarthost: kuyruk firewall değildir

VPN yükselene kadar postayı kuyrukta tutmak bir zamanlama sorunudur ve olağan çözüm Postfix'i durdurmak, main.cf'i değiştirmek ve yeniden başlatmaktır. Bu işe yarar ve yanlış biçimdir, çünkü iki gereksinimi karıştırır: teslimatın ne zaman denenmesi gerektiği ve hangi ağ yolunun onu taşıyabileceği. İkincisi bir firewall kararıdır ve hiçbir Postfix direktifi onu veremez. İkisi ayrıldığında her birinin küçük ve test edilebilir bir yanıtı olur.

Relay hedefini sabit tutun, doğrudan teslimatı ağ sınırında engelleyin ve beklemeyi kuyruk yapsın.

İnsanların tek bir şeyde birleştirdiği iki gereksinim

Relay, Postfix'e postanın nereye verileceğini söyler; relayhost = [smtp.corp.example]:587 bir ana bilgisayar ve bağlantı noktası belirtir, köşeli parantezler o sonraki sıçrama için MX tabanlı seçimi bastırır. Yol, çekirdeğe paketlerin nereye gidebileceğini söyler. Yol kısıtlaması olmayan doğru bir relayhost, yönlendirme tablosu izin verdiğinde Postfix'in doğrudan internete ulaşmasına yine izin verir ve yanlış relayhost'lu doğru bir firewall postayı yanlış yere gönderir. Hiçbiri diğerini gerektirmez.

Taşıma haritaları, gönderici başına geçersiz kılmalar ve yedek relay'ler her biri aynı okumayı hak eder. Sabit bir relayhost, yapılandırılmış her teslimat yolunun onu kullandığının kanıtı değildir ve relay'i atlayan yedek bir yol, daha iyi kamuflajdaki aynı hatadır.

defer_transports gerçekte ne yapar

defer_transports adı verilen taşımalar için mesajları tutar, böylece bir kuyruk turu onlara dokunana kadar hiçbir teslimat denemesi yapılmaz. Bu bir zamanlama denetimidir ve bir kuyruk boşaltma onu geçersiz kılar; bu tasarımdır, kusur değildir. master.cf içindeki gerçek taşıma adlarını kullanın, çünkü özel bir taşıma veya ayrı adlandırılmış bir relay taşıması yalnızca programı SMTP de konuştuğu için kapsanmaz. Olağan yeniden deneme başka bir mekanizmadır: fail-closed bir yolda teslimat denemeleri yalnızca başarısız olur ve kuyrukta kalır, hiçbir erteleme direktifi devreye girmez.

Kalıcı hatalar kibarca beklemez. Kötü bir alıcı veya reddedilen bir kimlik bilgisi, tünel görünene kadar oturmak yerine geri döner veya sabit hata olarak takılır, bu yüzden ertelenmiş postayla dolu bir kuyruk otomatik olarak güvenli bir kuyruk değildir.

Yolu ağ katmanında zorunlu kılın

Kısıtlama yerel çıkış sınırına veya yalıtılmış bir ağ ad alanının içine aittir. Relay'in gerçek adreslerini, taşımayı ve bağlantı noktasını kapsamalıdır, etkinse IPv6 da dahil, çünkü TCP 25'i engelleyen bir kural 587 veya 465 üzerindeki bir relay için hiçbir şey yapmaz. Loopback ve yerel gönderim yollarını ayrı tutun ki kuyruk kendisi çalışmaya devam etsin. Tünel yolu kaybolduğunda veya başka bir arabirim adı altında yeniden göründüğünde politika kapalı kalmalıdır.

Arabirimin yükselmesi olayı, relay'e onun üzerinden ulaşılabildiğini kanıtlamaz. Bu yüzden bağlantıyı denetleyip sonra kuyruğu boşaltan bir kanca bir kolaylıktır, garanti değildir: bağlantı denetim ile teslimat denemesi arasında değişebilir.

Tek bir zararsız mesajla kanıtlayın

VPN kapalıyken tek bir zararsız mesaj gönderin, ardından erteleme nedenini ve kuyruk ID'sini görmek için postqueue -p çıktısını inceleyin. Amaçlanan yolu geri yükleyin ve denetimli bir kuyruk turu isteyin, mesajın başka bir yere değil relay üzerinden çıktığını izleyin. Sonra yolu uçuş ortasında yeniden kesin ve mesajın kuyruğa döndüğünü doğrulayın. Bir kesintinin ne kadar sürebileceğine karar vermeden önce maximal_queue_lifetime değerini gözden geçirin, çünkü sıfır değeri sınırsız saklama değil tek bir deneme anlamına gelir.

Kuyruğun yaşını ve disk kullanımını izleyin. VPN'i bekleyen bir politika, kimse kuyruğun cuma gününden beri büyüdüğünü fark etmezse bir posta kesintisine dönüşür.

Relay'i, taşımayı, firewall kuralını ve ömrü birlikte kaydedin. Bu dördü düzeni tanımlar; herhangi biri tek başına bir tahmini tanımlar.