Postfix، VPN اور smarthost: قطار firewall نہیں ہے

VPN کے اٹھنے تک میل کو قطار میں رکھنا شیڈولنگ کا مسئلہ ہے، اور عام حل یہ ہے کہ Postfix روکیں، main.cf بدلیں اور دوبارہ شروع کریں۔ یہ کام کرتا ہے، اور یہ غلط شکل ہے، کیونکہ یہ دو تقاضے ملا دیتا ہے: ترسیل کب آزمائی جائے، اور کون سا نیٹ ورک راستہ اسے لے جا سکتا ہے۔ دوسرا firewall کا فیصلہ ہے، اور کوئی Postfix ہدایت اسے نہیں لے سکتی۔ دونوں الگ ہونے پر ہر ایک کا چھوٹا اور قابلِ جانچ جواب ہوتا ہے۔

ریلے کا منزل مستحکم رکھیں، نیٹ ورک سرحد پر براہِ راست ترسیل روکیں، اور انتظار قطار کو کرنے دیں۔

دو تقاضے جنہیں لوگ ایک میں ملا دیتے ہیں

ریلے Postfix کو بتاتا ہے کہ میل کہاں سونپنا ہے؛ relayhost = [smtp.corp.example]:587 میزبان اور پورٹ بتاتا ہے، اور بریکٹ اس اگلی چھلانگ کے لیے MX پر مبنی انتخاب دبا دیتے ہیں۔ راستہ کرنل کو بتاتا ہے کہ پیکٹ کہاں جا سکتے ہیں۔ راستے کی پابندی کے بغیر درست relayhost پھر بھی Postfix کو سیدھا انٹرنیٹ تک پہنچنے دیتا ہے جب روٹنگ جدول اجازت دے، اور غلط relayhost کے ساتھ درست firewall میل کو غلط جگہ بھیجتا ہے۔ کوئی ایک دوسرے کو لازم نہیں کرتا۔

ٹرانسپورٹ نقشے، فی بھیجنے والا تبدیلیاں اور بیک اپ ریلے سب اسی پڑھائی کے مستحق ہیں۔ مستحکم relayhost اس بات کا ثبوت نہیں کہ ہر مرتب شدہ ترسیل راستہ اسے استعمال کرتا ہے، اور ریلے کو نظرانداز کرنے والا بیک اپ راستہ بہتر بھیس میں وہی ناکامی ہے۔

defer_transports دراصل کیا کرتا ہے

defer_transports نامزد ٹرانسپورٹ کے لیے پیغام روکے رکھتا ہے، لہٰذا کوئی ترسیل کی کوشش نہیں ہوتی جب تک قطار کا ایک چکر انہیں نہ چھوئے۔ یہ شیڈولنگ کا کنٹرول ہے، اور قطار کا فلش اسے زیر کرتا ہے؛ یہ ڈیزائن ہے، خرابی نہیں۔ master.cf سے اصلی ٹرانسپورٹ نام استعمال کریں، کیونکہ حسبِ ضرورت ٹرانسپورٹ یا الگ نام والا ریلے ٹرانسپورٹ صرف اس لیے شامل نہیں ہوتا کہ اس کا پروگرام SMTP بھی بولتا ہے۔ عام دوبارہ کوشش دوسرا طریقہ ہے: fail-closed راستے کے ساتھ ترسیل کی کوششیں بس ناکام ہو کر قطار میں رہتی ہیں، کوئی تاخیری ہدایت شامل نہیں ہوتی۔

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

نیٹ ورک پرت پر راستہ نافذ کریں

پابندی مقامی آؤٹ پٹ سرحد پر یا الگ نیٹ ورک نام فضا کے اندر آتی ہے۔ اسے ریلے کے اصل پتے، ٹرانسپورٹ اور پورٹ ڈھانپنے چاہئیں، IPv6 بھی اگر فعال ہو، کیونکہ TCP 25 روکنے والا قاعدہ 587 یا 465 پر ریلے کے لیے کچھ نہیں کرتا۔ loopback اور مقامی جمع کرانے کے راستے الگ رکھیں تاکہ قطار خود کام کرتی رہے۔ سرنگ کا راستہ غائب ہونے یا کسی دوسرے انٹرفیس نام کے تحت دوبارہ نمودار ہونے پر پالیسی بند رہنی چاہیے۔

انٹرفیس کے اوپر آنے کا واقعہ ثابت نہیں کرتا کہ ریلے اس کے ذریعے قابلِ رسائی ہے۔ اسی لیے لنک جانچ کر پھر قطار خالی کرنے والا ہک سہولت ہے، ضمانت نہیں: جانچ اور ترسیل کی کوشش کے درمیان لنک بدل سکتا ہے۔

ایک بے ضرر پیغام سے ثابت کریں

VPN نیچے ہونے پر ایک بے ضرر پیغام بھیجیں، پھر تاخیر کی وجہ اور قطار ID کے لیے postqueue -p دیکھیں۔ مطلوبہ راستہ بحال کریں اور زیرِ نگرانی قطار چکر کی درخواست کریں، دیکھیں کہ پیغام کہیں اور سے نہیں بلکہ ریلے سے نکلتا ہے۔ پھر پرواز کے وسط میں راستہ دوبارہ توڑیں اور تصدیق کریں کہ پیغام قطار میں واپس آتا ہے۔ یہ طے کرنے سے پہلے کہ خلل کتنا طویل ہو سکتا ہے maximal_queue_lifetime دیکھیں، کیونکہ صفر قدر کا مطلب ایک کوشش ہے، غیر محدود نگہداشت نہیں۔

قطار کی عمر اور ڈسک کے استعمال پر نظر رکھیں۔ VPN کا انتظار کرنے والی پالیسی میل خلل بن جاتی ہے اگر کسی نے نہ دیکھا کہ جمعہ سے قطار بڑھ رہی ہے۔

ریلے، ٹرانسپورٹ، firewall قاعدہ اور عمر ایک ساتھ درج کریں۔ وہ چار ترتیب بیان کرتے ہیں؛ ان میں سے کوئی بھی اکیلا اندازہ بیان کرتا ہے۔