Postfix लाई मेल रिलेमा लगाउनुहोस्, वेब प्रोक्सीमा होइन

relayhost = proxy.example.net:3128 दुवै छेउ कुरा गर्न थाल्नुअघिसम्म विश्वसनीय देखिन्छ। Postfix एउटा SMTP साथीको अपेक्षा गर्छ। 3128 मा रहेको वेब प्रोक्सी HTTP प्रोक्सी अनुरोधको अपेक्षा गर्छ। कसैले पनि आफूले पर्खेको कुराकानी पाउँदैन।

यदि नेटवर्कले स्वीकृत मेल रिले उपलब्ध गराउँछ भने त्यसको सट्टा त्यही SMTP सेवा कन्फिगर गर्नुहोस्। सामान्य रूप यो हो:

relayhost = [smtp-relay.example.net]:587

होस्टनाम र पोर्ट उदाहरण हुन्। कोष्ठकहरूले त्यो रिले नामका लागि MX खोजी दबाउँछन्। तिनीहरूले HTTP CONNECT, TLS वा प्रमाणीकरण थप्दैनन्। रिलेले आवश्यक पार्ने submission, SASL र TLS सेटिङहरू छुट्टै कन्फिगर गर्नुहोस्।

दुई खाता फरक पनि हुन सक्छन्। वेब प्रोक्सीले स्वीकार गरेको पासवर्ड स्वतः मेल submission प्रमाण होइन, र रिलेले जडान स्वीकार गरेपछि पनि प्रेषकलाई अस्वीकार गर्न सक्छ।

यदि एक मात्र स्वीकृत मार्ग सुरुङ हो भने?

HTTP प्रोक्सीले गन्तव्य र पोर्टलाई अनुमति दिँदा SMTP लाई CONNECT मार्फत बोक्न सक्छ। त्यसले कुनै पनि SMTP क्लाइन्टलाई CONNECT उत्पादन गर्न लगाउँदैन। curl जस्तो उपकरणमा स्पष्ट प्रोक्सी-सुरुङ विकल्प हुन्छ; Postfix को relayhost सेट गर्नु अर्को इन्टरफेस हो।

स्थिर SSH फर्वार्ड वा उद्देश्यका लागि बनाइएको स्थानीय यातायात एडाप्टरले एक स्वीकृत SMTP सेवालाई स्थानीय TCP अन्त्य बिन्दुका रूपमा खोल्न सक्छ। त्यो डिजाइनमा Postfix ले अन्त्य बिन्दुसँग SMTP बोल्छ र एडाप्टरले अर्को यातायात उपलब्ध गराउँछ। यसलाई सीमित राख्नुहोस् र इच्छित मेल सर्भरको TLS पहिचान जोगाउनुहोस्: जडान ठेगाना loopback मा बदल्दा नाम-आधारित प्रमाणपत्र नीति प्रभावित हुन सक्छ।

नेटवर्क अपरेटरले दिने सेवा मेल रिले भए त्यसैलाई प्राथमिकता दिनुहोस्। यसले कतार, प्रेषक नीति र डेलिभरी त्रुटिलाई SMTP बुझ्ने घर दिन्छ। केवल वेब प्रोक्सी सेटिङले यी मेल कार्यहरूमध्ये कुनै पनि दिँदैन।