Postfix, VPN และ smarthost: คิวไม่ใช่ไฟร์วอลล์

การเก็บอีเมลไว้ในคิวจนกว่า VPN จะขึ้นเป็นปัญหาการจัดตาราง และวิธีแก้ทั่วไปคือหยุด Postfix สลับ main.cf แล้วเริ่มใหม่ วิธีนั้นได้ผล แต่มันเป็นรูปแบบที่ผิด เพราะมันรวมข้อกำหนดสองอย่างเข้าด้วยกัน คือเมื่อใดควรลองส่ง และ เส้นทางเครือข่ายใดที่อาจขนส่งมันได้ อย่างที่สองเป็นการตัดสินใจของไฟร์วอลล์ และไม่มีคำสั่งใดของ Postfix ทำได้ เมื่อแยกสองอย่างนี้ออก แต่ละอย่างก็มีคำตอบเล็ก ๆ ที่ทดสอบได้

รักษาปลายทางของรีเลย์ให้เสถียร บล็อกการส่งโดยตรงที่ขอบเครือข่าย และปล่อยให้คิวทำหน้าที่รอ

ข้อกำหนดสองอย่างที่คนหลอมรวมเป็นหนึ่ง

รีเลย์บอก Postfix ว่าจะมอบอีเมลที่ไหน relayhost = [smtp.corp.example]:587 ระบุโฮสต์และพอร์ต โดยวงเล็บเหลี่ยมระงับการเลือกตาม MX สำหรับฮ็อปถัดไปนั้น เส้นทางบอกเคอร์เนลว่าแพ็กเก็ตไปได้ที่ไหน relayhost ที่ถูกต้องโดยไม่มีข้อจำกัดเส้นทางยังคงปล่อยให้ Postfix เข้าถึงอินเทอร์เน็ตโดยตรงเมื่อตารางเส้นทางอนุญาต และไฟร์วอลล์ที่ถูกต้องกับ relayhost ที่ผิดก็ส่งอีเมลไปผิดที่ ไม่มีอย่างใดบ่งบอกถึงอีกอย่าง

แมปการขนส่ง การแทนที่รายผู้ส่ง และรีเลย์สำรอง ต่างก็สมควรได้รับการอ่านแบบเดียวกัน relayhost ที่เสถียรไม่ใช่หลักฐานว่าทุกเส้นทางส่งที่กำหนดค่าไว้ใช้มัน และเส้นทางสำรองที่ข้ามรีเลย์ก็คือความล้มเหลวเดียวกันใน camouflage ที่ดีกว่า

defer_transports ทำอะไรจริง ๆ

defer_transports กักข้อความไว้สำหรับการขนส่งที่ระบุไว้ ดังนั้นจะไม่มีการพยายามส่งจนกว่าการวนคิวหนึ่งครั้งจะแตะต้องมัน มันคือการควบคุมการจัดตาราง และการ flush คิวก็เอาชนะมันได้ นั่นคือการออกแบบ ไม่ใช่ข้อบกพร่อง ใช้ชื่อการขนส่งจริงจาก master.cf เพราะการขนส่งแบบกำหนดเองหรือการขนส่งรีเลย์ที่ตั้งชื่อแยกไม่ได้ถูกครอบคลุมเพียงเพราะโปรแกรมของมันพูด SMTP ได้ด้วย การลองใหม่ตามปกติเป็นกลไกอื่น เมื่อมีเส้นทางแบบ fail-closed การพยายามส่งก็ล้มเหลวและอยู่ในคิวต่อไป โดยไม่มีคำสั่งเลื่อนออกไปเข้ามาเกี่ยวข้อง

ความล้มเหลวถาวรไม่รออย่างสุภาพ ผู้รับที่ไม่ดีหรือข้อมูลรับรองที่ถูกปฏิเสธจะตีกลับหรือค้างเป็นข้อผิดพลาดแบบแข็งแทนที่จะรอจนอุโมงค์ปรากฏ ดังนั้นคิวที่เต็มไปด้วยอีเมลที่เลื่อนออกไปจึงไม่ใช่คิวที่ปลอดภัยโดยอัตโนมัติ

บังคับเส้นทางที่ชั้นเครือข่าย

ข้อจำกัดอยู่ที่ขอบเอาต์พุตภายในหรือภายในเนมสเปซเครือข่ายที่แยกออก มันต้องครอบคลุมที่อยู่จริงของรีเลย์ การขนส่ง และพอร์ต รวมถึง IPv6 หากเปิดใช้ เพราะกฎที่บล็อก TCP 25 ไม่มีผลใด ๆ กับรีเลย์บน 587 หรือ 465 แยก loopback และเส้นทางการส่งภายในออกจากกันเพื่อให้คิวเองยังทำงานได้ นโยบายควรคงปิดไว้เมื่อเส้นทางอุโมงค์หายไปหรือกลับมาภายใต้ชื่ออินเทอร์เฟซอื่น

เหตุการณ์ที่อินเทอร์เฟซขึ้นไม่ได้พิสูจน์ว่าอุโมงค์เข้าถึงรีเลย์ได้ นั่นคือเหตุผลที่ฮุกซึ่งตรวจสอบลิงก์แล้ว flush เป็นความสะดวกไม่ใช่การรับประกัน ลิงก์อาจเปลี่ยนระหว่างการตรวจสอบกับการพยายามส่ง

พิสูจน์ด้วยข้อความที่ไม่เป็นอันตราย

ส่งข้อความที่ไม่เป็นอันตรายหนึ่งข้อความขณะ VPN ลง แล้วตรวจสอบ postqueue -p เพื่อดูเหตุผลการเลื่อนและ ID ของคิว จากนั้นคืนเส้นทางที่ต้องการและขอให้วนคิวอย่างควบคุม ดูว่าข้อความออกผ่านรีเลย์ไม่ใช่ที่อื่น จากนั้นตัดเส้นทางอีกครั้งกลางเที่ยวบินและยืนยันว่าข้อความกลับเข้าคิว ตรวจดู maximal_queue_lifetime ก่อนตัดสินว่าเหตุขัดข้องจะยาวได้เท่าใด เพราะค่าเป็นศูนย์หมายถึงการลองครั้งเดียว ไม่ใช่การเก็บไว้ไม่จำกัด

เฝ้าดูอายุของคิวและการใช้ดิสก์ นโยบายที่รอ VPN จะกลายเป็นเหตุอีเมลขัดข้องหากไม่มีใครสังเกตว่าคิวโตขึ้นตั้งแต่วันศุกร์

บันทึกรีเลย์ การขนส่ง กฎไฟร์วอลล์ และอายุการใช้งานไว้ด้วยกัน สี่อย่างนี้อธิบายการจัดวาง ส่วนอย่างใดอย่างหนึ่งเพียงลำพังอธิบายการเดา