VPN সংযুক্ত, কিন্তু IMAP সিঙ্ক হচ্ছে না? এই তিনটি স্তর দেখুন
মেইল সার্ভারে পৌঁছানো, TLS হ্যান্ডশেক শেষ করা, প্রমাণীকরণ করা এবং একটি মেইলবক্স নির্বাচন করা আলাদা ঘটনা। কোন স্তরটি ব্যর্থ হয়েছে তা খুঁজুন।
অফিস VPN-এ সংযোগ করুন, মেইল ক্লায়েন্ট খুলুন এবং দেখুন ইনবক্স রিফ্রেশ করতে অস্বীকার করছে যখন ওয়েবমেইল স্বাভাবিকভাবে লোড হচ্ছে। স্বাভাবিক রোগনির্ণয় হলো VPN ট্রাফিক পার করছে কিন্তু মেইল আটকাচ্ছে, অথবা অ্যাকাউন্টের পাসওয়ার্ড বদলে গেছে। দুটি অনুমানই IMAP ক্লায়েন্ট কী করে তার গঠন এড়িয়ে যায়। হোস্টে পৌঁছানো, TLS শেষ করা, প্রমাণীকরণ করা এবং মেইলবক্স নির্বাচন করা চারটি আলাদা ঘটনা, এবং VPN শুধুমাত্র প্রথমটির মালিক।
মিথ: একটি সংযোগ মানে একটি লগইন
বিশ্বাস হলো, টানেল চালু হয়ে মেইল সার্ভার সাড়া দিলেই মেইলবক্স কার্যত খোলা থাকে। তা নয়। VPN সেবার পথ দেয়; এটি আপনাকে সাইন ইন করায় না এবং ফোল্ডার নির্বাচন করে না। একটি ক্লায়েন্ট পুরোপুরি কাজ করা টানেল এবং বৈধ পাসওয়ার্ড নিয়ে সেই ধাপগুলোর চতুর্থটিতে বসে থাকতে পারে।
এই ফাঁকেই বেশিরভাগ “VPN-এর উপর দিয়ে IMAP কাজ করছে না” প্রতিবেদন আসলে বাস করে।
তিনটি IMAP অবস্থা, এবং ক্লায়েন্টরা কোথায় আটকে যায়
IMAP একটি অনুমোদনহীন অবস্থা, একটি অনুমোদিত অবস্থা এবং একটি নির্বাচিত অবস্থা সংজ্ঞায়িত করে, এবং কমান্ড কেবল সেই অবস্থাতেই বৈধ যেখানে সেগুলো অনুমোদিত। সার্ভার পূর্ব-প্রমাণীকরণ দিলে সংযোগ আগে থেকেই অনুমোদিত অবস্থায় শুরু হতে পারে, তাই পাসওয়ার্ড জিজ্ঞাসার অনুপস্থিতি কিছুই প্রমাণ করে না। মেইলবক্স নির্বাচন সেশনটিকে অনুমোদিত থেকে নির্বাচিত অবস্থায় নিয়ে যায়, এবং কেবল তখনই বার্তার উপর কাজ করা কমান্ডগুলোর লক্ষ্য থাকে।
যে ক্লায়েন্ট সফলভাবে প্রমাণীকরণ করে তারপর কনফিগার করা ফোল্ডার নির্বাচন করতে ব্যর্থ হয়, সার্ভার সঠিকভাবে আচরণ করলেও তা সিঙ্ক ব্যর্থতার মতো দেখাবে। নাম বদলানো ফোল্ডার, ভিন্নভাবে “ইনবক্স” ম্যাপ করা প্রদানকারী, বা অনুপস্থিত অ্যাক্সেস অধিকার—সবই এখানে পড়ে। সার্ভারের ট্যাগযুক্ত NO প্রতিক্রিয়াই প্রমাণ, এবং এটি প্রত্যাখ্যাত পাসওয়ার্ডের প্রতিক্রিয়ার মতো নয়।
TLS আসে IMAP কথোপকথনের আগে
পোর্ট 993-এ অন্তর্নিহিত TLS-এর সাথে, কোনো IMAP কমান্ড পাঠানোর আগেই TLS হ্যান্ডশেক সম্পন্ন হয়, তাই একটি সার্টিফিকেট সমস্যা এমন ত্রুটি দেয় যা মেইলের বদলে বিশ্বাসের কথা বলে। মেইল হোস্টনামকে সার্টিফিকেটের সাথে যাচাই করতে হবে ঠিক যেমন ওয়েব হোস্টনাম করতে হয়; ট্রাফিক সংরক্ষণকারী টানেল অবৈধ সার্টিফিকেটকে বৈধ করে না।
ত্রুটির পাঠ ক্ষেত্রগুলো আলাদা করে। সংযোগ টাইমআউট মানে SYN কখনো সম্পন্ন হয়নি। TLS ত্রুটি মানে TCP সংযোগ কাজ করেছে এবং হ্যান্ডশেক করেনি। IMAP NO বা BAD প্রতিক্রিয়া মানে দুটিই সফল হয়েছে এবং প্রোটোকল স্তর কিছু প্রত্যাখ্যান করেছে। কোনো সেটিং পরিবর্তনের আগে আপনি কোনটি দেখেছেন তা লিপিবদ্ধ করুন।
ক্যাশ করা মেইল কোনো কিছুর প্রমাণ নয়
একটি মেইল ক্লায়েন্ট আগে ডাউনলোড করা বার্তা দেখায় আজ সার্ভারে পৌঁছাতে পারুক বা না পারুক, তাই যে ইনবক্স দেখা যায় তা কেবল বলে স্থানীয় সঞ্চয় কাজ করছে। যেকোনো প্রকৃত পরীক্ষায় সার্ভার অপারেশন বাধ্য করতে হবে: একটি ফোল্ডার রিফ্রেশ করুন, কখনো ডাউনলোড হয়নি এমন বার্তা আনুন, বা এমন কমান্ড পাঠান যা ক্লায়েন্ট মেইলবক্স নির্বাচনের পরেই দিত।
অবিনাশী পরীক্ষা ব্যবহার করুন। একটি ফোল্ডার রিফ্রেশ করা এবং অ্যাকাউন্টের ত্রুটি লগ পড়া অ্যাকাউন্ট মুছে আবার যোগ করার চেয়ে ভালো, যা মূলত প্রমাণ করে কনফিগ স্ক্রিন এখনো কাজ করে।
পাঠানো এবং ওয়েবমেইল ভিন্ন প্রোটোকল
মেইল পাঠানো হলো জমা দেওয়া, IMAP নয়। এটি আলাদা সেবা এবং সাধারণত আলাদা পোর্ট ব্যবহার করে যার নিজস্ব TLS মোড ও নিজস্ব প্রমাণীকরণ আছে, তাই কাজ করা আউটবক্স প্রমাণ করে না IMAP মেইলবক্স নির্বাচিত হয়েছে, এবং নষ্ট আউটবক্স IMAP-কে দোষারোপ করে না।
ওয়েবমেইল আবার আলাদা। এটি একই VPN-এর উপর সফল হতে পারে কারণ এটি একটি ওয়েব ফ্রন্টএন্ডের বিরুদ্ধে HTTPS সেশন, যা ডেস্কটপ ক্লায়েন্টের IMAP হোস্ট, পোর্ট বা TLS মোড সম্পর্কে কিছু বলে না।
হস্তান্তরের জন্য চারটি ফলাফল আলাদাভাবে লিপিবদ্ধ করুন: VPN পথ, মেইল এন্ডপয়েন্ট ও TLS ফলাফল, অ্যাকাউন্ট প্রমাণীকরণের ফলাফল, এবং মেইলবক্স নির্বাচনের ফলাফল। নোটের বাইরে শংসাপত্র ও বার্তার বিষয়বস্তু রাখুন। এই রেকর্ড পরবর্তী ব্যক্তিকে বলে সমাধানটি নেটওয়ার্ক, সার্টিফিকেট, অ্যাকাউন্ট নাকি ফোল্ডার কনফিগারেশনের, কোনো সুরক্ষা স্তর দুর্বল না করেই।