VPN দিয়ে পাঠানো ইমেইল: উত্তরটি আসলে কোথায় যায়

আপনি টানেলের মধ্য দিয়ে একটি বার্তা পাঠান, সংযোগ বিচ্ছিন্ন করেন, আর পরদিন সকালে উত্তর এসে পৌঁছায়। এর জন্য পুরোনো VPN ঠিকানার দরকার নেই, আর এতে কিছুই ভাঙে না। ইমেইল উত্তরগুলোকে সেই ঠিকানায় পাঠায় না যেখান থেকে বার্তা পাঠানো হয়েছিল; এটি সেগুলোকে পাঠায় একটি মেইলবক্সে। এখানে তিনটি পথ একটি প্রশ্নে মিলিয়ে ফেলা হয়, আর সেগুলো আলাদা করলে উদ্বেগের বেশিরভাগই উত্তর পায়।

তিনটি পথ যা মানুষ একটিতে মিলিয়ে ফেলে

জমা দেওয়া, বিতরণ এবং পড়া তিনটি আলাদা সংযোগ, আর এর মধ্যে কেবল দুটিতেই আপনার ডিভাইস জড়িত।

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPN প্রথম ও তৃতীয়টিকে প্রভাবিত করতে পারে, কারণ এগুলো আপনার ডিভাইসের তৈরি সংযোগ। এটি দ্বিতীয়টিকে প্রভাবিত করতে পারে না, কারণ সেই পথটি আপনার নিয়ন্ত্রণে না থাকা দুটি মেইল সার্ভারের মধ্যে চলে। উত্তর হলো আপনি যে ঠিকানা থেকে পাঠিয়েছেন সেখানে ফিরে আসা প্যাকেট নয়। এটি একটি নতুন বার্তা, যা অন্য পক্ষের মেইল পরিষেবা আপনার মেইলবক্স পরিষেবায় বিতরণ করে।

এই তিনটিকে আলাদা করে ধরলে উত্তরটি আপনাকে খুঁজে পাবে কি না, সেই প্রশ্ন আর রহস্যময় থাকে না।

Reply-To ফিল্ড একটি ঠিকানা, কোনো পথ নয়

RFC 5322 অনুযায়ী Reply-To হলো সেই মেইলবক্স বা মেইলবক্সগুলো যেখানে উত্তর পাঠাতে হবে। এটি না থাকলে স্বাভাবিক ডিফল্ট হলো From মেইলবক্স, যদি না উত্তরদাতা অন্য কিছু লেখেন। দুটোই হেডারে বসে থাকা মেইল ঠিকানা। কোনোটিই মূল বার্তা জমা দেওয়া নেটওয়ার্ক সংযোগটি আবার খোলার নির্দেশ নয়।

এই কারণেই VPN এক্সিট ঠিকানা কখনো উত্তরপথে দেখা যায় না। জমা দেওয়ার সার্ভার যদি সেই এক্সিট ঠিকানা কোথাও লিখেও রাখে, উত্তরটি যায় একটি মেইলবক্সে, আর পাঠানোর সার্ভার আপনার পুরোনো সকেট নয়, ডোমেইনের মেইল এক্সচেঞ্জার খোঁজে।

উত্তর যদি অপ্রত্যাশিত কোথাও যায়, টানেলকে সন্দেহ করার আগে Reply-To এবং প্রেরকের নিজের ক্লায়েন্ট সেটিংস পড়ুন।

ট্রেস হেডারগুলো আসলে কী লিপিবদ্ধ করে

প্রতিটি SMTP হপ একটি Received হেডার যোগ করে যা তার হ্যান্ডেল করা সংযোগের বর্ণনা দেয়, আর সবচেয়ে উপরেরটি বিতরণের আগের শেষ হপ। তাই জমা দেওয়া বার্তায় পর্যালোচনার যোগ্য নেটওয়ার্ক বিবরণ থাকতে পারে, আর সেই বিবরণ সার্ভার লেখে, আপনি বাছাই করেন না। এতে কী থাকে তা নির্ভর করে প্রদানকারীর জমা দেওয়ার স্থাপত্য ও হেডার প্রক্রিয়াকরণের উপর।

অনুমান না করে সংরক্ষিত বার্তা থেকে সেগুলো পড়ুন:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

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

পরে মেইল পড়া একটি নতুন সংযোগ

আপনি উত্তরটি খোলার সময় আপনার ক্লায়েন্ট এখন আপনি যে নেটওয়ার্কে আছেন সেটির মধ্য দিয়ে আপনার মেইলবক্স পরিষেবায় সংযোগ করে। এটি নিজস্ব উৎস ঠিকানাসহ একটি নতুন সংযোগ, গতকালের জমা দেওয়ার সকেটের ধারাবাহিকতা নয়। এটি সেই মুহূর্তে আপনি যে নেটওয়ার্ক ব্যবহার করছেন তার চলমান নীতি অনুসরণ করে।

রিমোট কনটেন্ট আবার তৃতীয় একটি বিষয়। যে মেইল ক্লায়েন্ট একটি দূরবর্তী ছবি লোড করে বা লিঙ্ক অনুসরণ করে, সে তার চলমান সেটিংসে আলাদা অনুরোধ করে, আর সেই অনুরোধে বার্তায় এমবেড করা যেকোনো শনাক্তকারী থাকতে পারে। এটি পুরোনো ঠিকানায় আসা SMTP উত্তর নয়, আর এটিকে তা ভাবলে প্রকৃত ঝুঁকি ঢাকা পড়ে।

আপনি বার্তাটি খুলেছেন, এটি ঘোষণা না করেই পড়তে চাইলে রিমোট কনটেন্ট বন্ধ করুন।

এটিকে লিক বলার আগে কী যাচাই করবেন

মূল বার্তার ভিউ এবং Reply-To ফিল্ড দিয়ে শুরু করুন। তারপর আপনার উদ্বেগ তৈরি করা Received এন্ট্রিগুলো কোন পরিষেবা যোগ করেছে তা শনাক্ত করুন, আর সেটি পুরোনো ফোরামের উত্তরের বদলে প্রদানকারীর চলমান নথির সঙ্গে মিলিয়ে দেখুন।

সবশেষে প্রশ্নগুলো আলাদা করুন: জমা দেওয়ার সার্ভার কী পর্যবেক্ষণ করেছে, বিতরণ শৃঙ্খল কী যোগ করেছে, আর আপনি বার্তাটি খোলার সময় আপনার ক্লায়েন্ট কী অনুরোধ করেছে?

এই তিনটির আলাদা উত্তর দেওয়া একটি IP পৃষ্ঠা দেখার চেয়ে বেশি কাজ, আর এটিই একমাত্র পথ যা এমন সিদ্ধান্ত দেয় যা আপনি সমর্থন করতে পারেন। একটি ইমেইল ঠিকানায় উত্তর দিলে আপনার বাড়ির ঠিকানা প্রকাশ পায় না, আর এতে পুরোনো টানেল চালু রাখার দরকার হয় না।