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 पर्खने नीति, शुक्रबारदेखि लाइन बढ्दै छ भन्ने कसैले नदेखेमा मेल अवरोधमा परिणत हुन्छ।

रिले, ट्रान्सपोर्ट, फायरवाल नियम र आयु एकैसाथ लेख्नुहोस्। ती चारले व्यवस्था वर्णन गर्छन्; तीमध्ये कुनै एकले मात्र अनुमान वर्णन गर्छ।