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 समजणारे घर देते. केवळ वेब प्रॉक्सी सेटिंग या मेल कार्यांपैकी काहीही देत नाही.

संबंधित लेख