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 समझने वाला घर देता है। केवल वेब प्रॉक्सी सेटिंग इनमें से कोई मेल कार्य प्रदान नहीं करती।