Postfix, VPN और smarthost: कतार फ़ायरवॉल नहीं है

VPN उठने तक मेल को कतार में रखना एक शेड्यूलिंग समस्या है, और आम हल है Postfix रोकना, main.cf बदलना और उसे फिर चालू करना। यह काम करता है, और यह ग़लत आकार है, क्योंकि यह दो आवश्यकताओं को मिला देता है: डिलीवरी कब आज़माई जाए, और कौन-सा नेटवर्क रास्ता उसे ले जा सकता है। दूसरी फ़ायरवॉल का निर्णय है, और कोई Postfix निर्देश उसे नहीं ले सकता। दोनों अलग होने पर हर एक का छोटा और परखने योग्य उत्तर होता है।

रिले का गंतव्य स्थिर रखें, नेटवर्क सीमा पर सीधी डिलीवरी रोकें, और कतार को इंतज़ार करने दें।

दो आवश्यकताएँ जिन्हें लोग एक में मिला देते हैं

रिले Postfix को बताता है कि मेल कहाँ सौंपना है; relayhost = [smtp.corp.example]:587 होस्ट और पोर्ट बताता है, और कोष्ठक उस अगले हॉप के लिए MX-आधारित चयन दबा देते हैं। रास्ता कर्नेल को बताता है कि पैकेट कहाँ जा सकते हैं। रास्ते की पाबंदी के बिना सही relayhost तब भी Postfix को सीधे इंटरनेट तक पहुँचने देता है जब रूटिंग तालिका अनुमति दे, और ग़लत relayhost के साथ सही फ़ायरवॉल मेल ग़लत जगह भेजता है। कोई भी दूसरे को अनिवार्य नहीं करता।

ट्रांसपोर्ट मैप, प्रति-प्रेषक ओवरराइड और फ़ॉलबैक रिले सभी उसी पढ़ने के योग्य हैं। स्थिर relayhost इस बात का प्रमाण नहीं है कि हर कॉन्फ़िगर किया गया डिलीवरी मार्ग उसका उपयोग करता है, और रिले को बायपास करने वाला फ़ॉलबैक मार्ग वही विफलता है, बस बेहतर छद्मवेश में।

defer_transports वास्तव में क्या करता है

defer_transports नामित ट्रांसपोर्ट के लिए संदेश रोक लेता है, इसलिए कतार का कोई दौर उन्हें छूने तक कोई डिलीवरी प्रयास नहीं होता। यह शेड्यूलिंग नियंत्रण है, और कतार फ़्लश इसे ओवरराइड करता है; यह डिज़ाइन है, ख़राबी नहीं। master.cf के असली ट्रांसपोर्ट नाम इस्तेमाल करें, क्योंकि कस्टम ट्रांसपोर्ट या अलग नाम वाला रिले ट्रांसपोर्ट सिर्फ़ इसलिए शामिल नहीं हो जाता कि उसका प्रोग्राम SMTP भी बोलता है। सामान्य पुनःप्रयास दूसरी व्यवस्था है: fail-closed रास्ते के साथ डिलीवरी प्रयास बस विफल होते हैं और कतार में रहते हैं, कोई देरी निर्देश शामिल नहीं होता।

स्थायी विफलताएँ शिष्टाचार से इंतज़ार नहीं करतीं। ख़राब प्राप्तकर्ता या अस्वीकृत क्रेडेंशियल सुरंग आने तक बैठने के बजाय लौट जाता है या कठोर त्रुटि बनकर अटक जाता है, इसलिए देरी वाले मेल से भरी कतार अपने आप सुरक्षित कतार नहीं है।

नेटवर्क परत पर रास्ता लागू करें

पाबंदी स्थानीय-आउटपुट सीमा पर या अलग नेटवर्क नेमस्पेस के भीतर होनी चाहिए। इसे रिले के असली पते, ट्रांसपोर्ट और पोर्ट ढकने चाहिए, IPv6 सहित यदि सक्षम हो, क्योंकि TCP 25 रोकने वाला नियम 587 या 465 पर रिले के लिए कुछ नहीं करता। लूपबैक और स्थानीय सबमिशन मार्ग अलग रखें ताकि कतार स्वयं काम करती रहे। नीति तब बंद रहनी चाहिए जब सुरंग का रास्ता गायब हो या किसी दूसरे इंटरफ़ेस नाम के तहत फिर दिखे।

इंटरफ़ेस के ऊपर आने की घटना यह साबित नहीं करती कि रिले उसके ज़रिए पहुँच में है। इसीलिए लिंक जाँचकर फिर कतार खाली करने वाला हुक सुविधा है, गारंटी नहीं: जाँच और डिलीवरी प्रयास के बीच लिंक बदल सकता है।

एक हानिरहित संदेश से साबित करें

VPN बंद रखकर एक हानिरहित संदेश भेजें, फिर देरी के कारण और कतार ID के लिए postqueue -p देखें। इच्छित रास्ता बहाल करें और नियंत्रित कतार दौर माँगें, देखें कि संदेश रिले से निकलता है या कहीं और से। फिर उड़ान के बीच रास्ता दोबारा तोड़ें और पुष्टि करें कि संदेश कतार में लौटता है। तय करने से पहले कि रुकावट कितनी देर चल सकती है, maximal_queue_lifetime देखें, क्योंकि शून्य मान का अर्थ एक प्रयास है, असीमित प्रतिधारण नहीं।

कतार की आयु और डिस्क उपयोग पर नज़र रखें। VPN का इंतज़ार करने वाली नीति मेल रुकावट बन जाती है यदि किसी ने नहीं देखा कि शुक्रवार से कतार बढ़ रही है।

रिले, ट्रांसपोर्ट, फ़ायरवॉल नियम और आयु एक साथ दर्ज करें। ये चार व्यवस्था बताते हैं; इनमें से कोई भी अकेला अनुमान बताता है।