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 ची वाट पाहणारे धोरण, शुक्रवारपासून रांग वाढत आहे हे कोणाच्या लक्षात न आल्यास मेल व्यत्यय होतो।

रिले, ट्रान्सपोर्ट, फायरवॉल नियम आणि आयुष्य एकत्र नोंदवा। ते चार मांडणी वर्णन करतात; त्यापैकी कोणतेही एकटे अंदाज वर्णन करते।