Postfix, VPN ও smarthost: সারি কোনো ফায়ারওয়াল নয়

VPN ওঠা পর্যন্ত মেইল সারিতে রাখা একটি সময়সূচির সমস্যা, আর সাধারণ সমাধান হলো Postfix বন্ধ করা, main.cf বদলানো এবং আবার চালু করা। এটি কাজ করে, কিন্তু ভুল গঠন, কারণ এটি দুটি দাবি মেশায়: কখন ডেলিভারির চেষ্টা করা উচিত, এবং কোন নেটওয়ার্ক পথ এটি বহন করতে পারে। দ্বিতীয়টি ফায়ারওয়ালের সিদ্ধান্ত, এবং কোনো Postfix নির্দেশ এটি নিতে পারে না। দুটিকে আলাদা করলে প্রতিটির একটি ছোট ও পরীক্ষাযোগ্য উত্তর থাকে।

রিলের গন্তব্য স্থির রাখুন, নেটওয়ার্ক সীমানায় সরাসরি ডেলিভারি আটকান, এবং অপেক্ষা সারিকেই করতে দিন।

মানুষ যে দুটি দাবিকে এক করে ফেলে

রিলে Postfix-কে বলে মেইল কোথায় হস্তান্তর করতে হবে; relayhost = [smtp.corp.example]:587 একটি হোস্ট ও পোর্ট নির্দেশ করে, আর বন্ধনী ওই পরবর্তী হপের জন্য MX-ভিত্তিক নির্বাচন বন্ধ রাখে। পথ কার্নেলকে বলে প্যাকেট কোথায় যেতে পারে। পথ-সীমা ছাড়া সঠিক relayhost তখনও Postfix-কে সরাসরি ইন্টারনেটে পৌঁছাতে দেয় যখন রাউটিং টেবিল তা অনুমতি দেয়, আর ভুল relayhost সহ সঠিক ফায়ারওয়াল মেইল ভুল জায়গায় পাঠায়। একটিও অন্যটিকে বাধ্য করে না।

ট্রান্সপোর্ট ম্যাপ, প্রতি-প্রেরকের ওভাররাইড এবং ফলব্যাক রিলে, প্রত্যেকটির একই পাঠ দরকার। স্থির relayhost এই প্রমাণ নয় যে প্রতিটি কনফিগার করা ডেলিভারি পথ এটি ব্যবহার করে, আর রিলে এড়িয়ে যাওয়া ফলব্যাক একই ব্যর্থতা, শুধু ভালো ছদ্মবেশে।

defer_transports আসলে কী করে

defer_transports নাম দেওয়া ট্রান্সপোর্টগুলোর জন্য বার্তা ধরে রাখে, ফলে সারির একটি দौড় তাদের স্পর্শ না করা পর্যন্ত কোনো ডেলিভারি চেষ্টা হয় না। এটি সময়সূচির নিয়ন্ত্রণ, এবং সারি ফ্লাশ এটি অতিক্রম করে; এটি নকশা, ত্রুটি নয়। master.cf থেকে প্রকৃত ট্রান্সপোর্ট নাম ব্যবহার করুন, কারণ কাস্টম ট্রান্সপোর্ট বা আলাদা নামের রিলে ট্রান্সপোর্ট কেবল তার প্রোগ্রামও SMTP বলতে পারে বলে আওতাভুক্ত হয় না। সাধারণ পুনঃচেষ্টা অন্য ব্যবস্থা: fail-closed পথে ডেলিভারি চেষ্টা কেবল ব্যর্থ হয় ও সারিতে থাকে, কোনো বিলম্ব নির্দেশ জড়িত থাকে না।

স্থায়ী ব্যর্থতা ভদ্রভাবে অপেক্ষা করে না। খারাপ প্রাপক বা প্রত্যাখ্যাত শংসাপত্র টানেল আসার আগে বসে থাকার বদলে ফিরে যায় বা কঠিন ত্রুটি হিসেবে আটকে থাকে, তাই বিলম্বিত মেইলে ভরা সারি স্বয়ংক্রিয়ভাবে নিরাপদ সারি নয়।

নেটওয়ার্ক স্তরে পথ প্রয়োগ করুন

সীমাবদ্ধতা স্থানীয়-আউটপুট সীমানায় বা বিচ্ছিন্ন নেটওয়ার্ক নেমস্পেসের ভিতরে থাকা উচিত। এটি রিলের প্রকৃত ঠিকানা, ট্রান্সপোর্ট ও পোর্ট ঢাকতে হবে, সক্রিয় থাকলে IPv6 সহ, কারণ TCP 25 আটকানো নিয়ম 587 বা 465-এ থাকা রিলের জন্য কিছুই করে না। লুপব্যাক ও স্থানীয় সাবমিশন পথ আলাদা রাখুন যাতে সারি নিজেই কাজ করতে থাকে। টানেল পথ হারিয়ে গেলে বা ভিন্ন ইন্টারফেস নামে আবার দেখা দিলে নীতি বন্ধ থাকা উচিত।

ইন্টারফেস ওঠার ঘটনা প্রমাণ করে না যে রিলে সেটির মধ্য দিয়ে পৌঁছানো যায়। এজন্য লিঙ্ক পরীক্ষা করে তারপর ফ্লাশ করা হুক একটি সুবিধা, নিশ্চয়তা নয়: পরীক্ষা ও ডেলিভারি চেষ্টার মধ্যে লিঙ্ক বদলাতে পারে।

একটি নিরীহ বার্তা দিয়ে প্রমাণ করুন

VPN বন্ধ রেখে একটি নিরীহ বার্তা পাঠান, তারপর বিলম্বের কারণ ও সারি আইডির জন্য postqueue -p দেখুন। উদ্দিষ্ট পথ পুনরুদ্ধার করুন এবং নিয়ন্ত্রিত সারি রান চান, দেখুন বার্তাটি অন্য কোথাও নয় বরং রিলে দিয়ে বেরোয় কি না। তারপর মাঝপথে আবার পথ ভাঙুন এবং নিশ্চিত করুন বার্তাটি সারিতে ফিরে আসে। কতক্ষণ বিভ্রাট চলতে পারে তা ঠিক করার আগে maximal_queue_lifetime দেখুন, কারণ শূন্য মানে সীমাহীন ধারণ নয়, একবার চেষ্টা।

সারির বয়স ও ডিস্ক ব্যবহার পর্যবেক্ষণ করুন। VPN-এর অপেক্ষা করা নীতি মেইল বিভ্রাটে পরিণত হয় যদি কেউ খেয়াল না করে যে শুক্রবার থেকে সারি বাড়ছে।

রিলে, ট্রান্সপোর্ট, ফায়ারওয়াল নিয়ম ও জীবনকাল একসাথে লিখে রাখুন। এই চারটি ব্যবস্থাটি বর্ণনা করে; এগুলোর যেকোনো একটি একা কেবল একটি অনুমান বর্ণনা করে।