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-বোঝে এমন ঠিকানা দেয়। শুধু ওয়েব প্রক্সি সেটিং এই মেইল কার্যাবলির কোনোটিই দেয় না।

সম্পর্কিত নিবন্ধ