Postfix کو میل ریلے کی طرف موڑیں، ویب پراکسی کی طرف نہیں

relayhost = proxy.example.net:3128 اس وقت تک معقول لگتا ہے جب تک دونوں سرے بات کرنا شروع نہ کریں۔ Postfix ایک SMTP ساتھی کی توقع کرتا ہے۔ 3128 پر ویب پراکسی HTTP پراکسی درخواست کی توقع کرتی ہے۔ کسی کو وہ گفتگو نہیں ملتی جس کی اسے توقع تھی۔

اگر نیٹ ورک کوئی منظور شدہ میل ریلے فراہم کرتا ہے تو اس کے بجائے وہی SMTP سروس ترتیب دیں۔ عام شکل یہ ہے:

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

ہوسٹ نام اور پورٹ مثالیں ہیں۔ بریکٹ اس ریلے نام کے لیے MX تلاش کو دبا دیتے ہیں۔ وہ HTTP CONNECT، TLS یا توثیق شامل نہیں کرتے۔ ریلے کی مطلوبہ submission، SASL اور TLS ترتیبات الگ سے مقرر کریں۔

دونوں اکاؤنٹس مختلف بھی ہو سکتے ہیں۔ ویب پراکسی کا قبول کردہ پاس ورڈ خود بخود میل بھیجنے کی سند نہیں ہوتا، اور ریلے کنکشن قبول کرنے کے بعد بھی بھیجنے والے کو مسترد کر سکتا ہے۔

اگر واحد منظور شدہ راستہ کوئی سرنگ ہو تو؟

HTTP پراکسی SMTP کو CONNECT کے ذریعے لے جا سکتی ہے جب وہ منزل اور پورٹ کی اجازت دیتی ہے۔ اس سے کوئی بھی SMTP کلائنٹ CONNECT نہیں بناتا۔ curl جیسے آلے میں واضح پراکسی سرنگ کا اختیار ہوتا ہے؛ Postfix کا relayhost مقرر کرنا الگ انٹرفیس ہے۔

ایک مستقل SSH فارورڈ یا مقصد کے لیے بنایا گیا مقامی نقل و حمل اڈاپٹر ایک منظور شدہ SMTP سروس کو مقامی TCP اختتامی نقطہ کے طور پر ظاہر کر سکتا ہے۔ اس ڈیزائن میں Postfix اختتامی نقطہ سے SMTP بولتا ہے اور اڈاپٹر دوسری نقل و حمل فراہم کرتا ہے۔ اسے محدود رکھیں اور مطلوبہ میل سرور کی TLS شناخت محفوظ رکھیں: کنکشن پتہ loopback میں بدلنے سے نام پر مبنی سرٹیفکیٹ پالیسی متاثر ہو سکتی ہے۔

جب نیٹ ورک آپریٹر کی فراہم کردہ سروس میل ریلے ہو تو اسی کو ترجیح دیں۔ یہ قطار، بھیجنے والے کی پالیسی اور ترسیل کی خرابیوں کو SMTP سمجھنے والا گھر دیتا ہے۔ صرف ویب پراکسی ترتیب ان میل افعال میں سے کوئی نہیں دیتی۔