ইমেল বুঝুন: পर्दার পিছনে কীভাবে কাজ করে

প্রথমে, আপনি একটি মেইল ইউজার এজেন্ট, বা MUA ব্যবহার করেন আপনার ডিভাইস থেকে ইমেল পড়তে এবং পাঠাতে (যেমন Gmail, বা Apple ডিভাইসের মেইল অ্যাপ)। এই প্রোগ্রামগুলো শুধু তখন এক্টিভ থাকে যখন আপনি সেগুলো ব্যবহার করছেন।

সাধারণত, সেগুলো একটি মেইল ট্রান্সফার এজেন্ট, বা MTA (একেও মেইল সার্ভার, MX হোস্ট, এবং মেইল এক্সচেঞ্জার বলা হয়) এর সাথে যোগাযোগ করে, যা আপনার ইমেল রিসিভ এবং স্টোর করার জন্য দায়িত্ববদ্ধ।

ইমেলগুলো রিমোটলি সংরক্ষিত থাকে যতক্ষণ না আপনি আপনার MUA খুলেন আপনার ইমেল চেক করার জন্য। ইমেলগুলো মেইল ডেলিভারি এজেন্ট (MDA) দ্বারা ডেলিভার করা হয়, যা সাধারণত MTA-এর সাথে প্যাকেজড থাকে।

পূর্বে মেইল SMTP, বা Simple Mail Transfer Protocol ব্যবহার করে একটি মেইল সার্ভারে পাঠানো হতো। SMTP ইমেলের জন্য একটি কমিউনিকেশন প্রোটোকল।

এখনও, যখন অনেক প্রপ্রায়েটারি সিস্টেম যেমন Microsoft Exchange এবং Gmail-এর মতো ওয়েবমেইল প্রোগ্রাম তাদের নিজস্ব প্রোটোকল ব্যবহার করে ইন্টারন্যালি, তারা SMTP ব্যবহার করে মেসেজ আউটসাইড তাদের সিস্টেমে ট্রান্সফার করতে (উদাহরণস্বরূপ, যদি একজন Gmail ইউজার একটি Outlook ক্লায়েন্টকে ইমেল পাঠাতে চায়)।

তারপর মেইল সার্ভার থেকে Post Office Protocol (POP3) ব্যবহার করে ডাউনলোড করা হতো। POP3 একটি অ্যাপ্লিকেশন-লেয়ার প্রোটোকল যা একটি ইন্টারনেট প্রোটোকল (IP) নেটওয়ার্কের মাধ্যমে একটি ইউজার অ্যাপ্লিকেশনকে একটি মেইল সার্ভারে মেইলবক্সের সাথে যোগাযোগ করার অ্যাক্সেস দেয়। এটি কানেক্ট করতে পারে, মেসেজ রিট্রিভ করতে পারে, সেগুলো ক্লায়েন্টের কম্পিউটারে স্টোর করতে পারে, এবং সার্ভারে সেগুলো ডিলিট বা রিটেইন করতে পারে।

এটি টেম্পোরারি ইন্টারনেট কানেকশন ম্যানেজ করার জন্য ডিজাইন করা হয়েছিল, যেমন ডায়াল-আপ (তাই এটি কানেক্ট হতো এবং কানেক্টেড থাকার সময় ইমেল রিট্রিভ করতো, এবং আপনাকে অফলাইনে মেসেজগুলো দেখতে দিতো)। এটি অধিক জনপ্রিয় ছিল যখন ডায়াল-আপ এক্সেস বেশি ব্যাপক ছিল।

এখন, IMAP, Internet Message Access Protocol, অধিকাংশই POP3-কে রিপ্লেস করেছে। IMAP একাধিক ক্লায়েন্টকে একই মেইলবক্স ম্যানেজ করতে দেয় (তাই আপনি আপনার ডেস্কটপ, ল্যাপটপ, এবং ফোন থেকে ইমেল পড়তে পারেন, ইত্যাদি এবং আপনার সকল মেসেজ সেখানে থাকবে, একইভাবে অর্গানাইজড)।

শেষে, ওয়েবমেইল উভয়কে রিপ্লেস করল। ওয়েবমেইল আপনাকে একটি ওয়েবসাইটে লগইন করে যেকোনো জায়গা বা যেকোনো ডিভাইস থেকে মেসেজ রিসিভ করতে দেয় (যে!), তবে আপনাকে এটি ব্যবহার করার সময় ইন্টারনেটের সাথে কানেক্টেড থাকতে হয়। যদি ওয়েবসাইট (যেমন Gmail) আপনার MUA হয়, তবে আপনাকে SMTP বা IMAP সার্ভার সেটিংস জানার প্রয়োজন নেই।

ইমেল কীভাবে সিকিউর করা হয়?

দুর্ভাগ্যক্রমে, সিকিউরিটি মেইল প্রোটোকলগুলোর শুরু থেকে বিল্ট-ইন ছিল না (প্রায় সকল শুরুতেই ইন্টারনেট প্রোটোকলগুলোর মতো)। সার্ভারগুলো শুধু এক্সপেক্ট করতো যে কেউ যেকোনো মেসেজ পাঠাবে এবং সেটি যেকোনো অন্য সার্ভারে পাস করবে যা মেসেজটিকে এর চূড়ান্ত গন্তব্যে (to: ফিল্ডের রিসিপিয়েন্ট) রুট করতে সাহায্য করতে পারে।

অনুমান অনুযায়ী, এটি একটি সমস্যা হয়ে উঠলো যখন ইন্টারনেট কয়েকটি সরকারি এবং গবেষণা গ্রুপ থেকে বিস্তৃত হয়ে বিশ্বব্যাপী এমন কিছুতে পরিণত হয় যা আমরা অ্যাসেনশিয়ালি সব কিছু করতে ব্যবহার করি। খুব দ্রুত স্প্যাম এবং ফিশিং ইমেল সবার জন্য একটি বিশাল সমস্যা बनিয়ে উঠল (এবং থাকছে)।

প্রতিক্রিয়ায়, আমরা সমবেতভাবে কিছু মেজার ইমপ্লিমেন্ট করার চেষ্টা করেছি যা মানুষকে অন্যের মেসেজ পড়া থেকে রোধ করে (এনক্রিপশন) এবং যাচাই করে যে মেসেজগুলো আসলে PURPORTED সেন্ডার থেকে এসেছে কিনা (অথেনটিকেশন)।  

আধিকাংশ জায়গা TLS (Transport Layer Security, SSL বা Secure Sockets Layer-এর রিপ্লেসমেন্ট) ব্যবহার করে, একটি ক্রিপ্টোগ্রাফিক প্রোটোকল যা ট্রানজিট-এ এনক্রিপশন প্রদান করে। এটি তখন প্রোটেকশন দেয় যখন মেসেজ ট্রান্সমিট হচ্ছে, কিন্তু ডেটা Ат রেস্ট (উদাহরণস্বরূপ, আপনার কম্পিউটারে স্টোরড) থাকার সময় নয়।

এটি নিশ্চিত করে যে মেসেজ ট্রানজিটের সময় আল্টার বা স্নুপড হয় না MTA থেকে MTA-এ যাওয়ার সময়। তবে, এটি যাচাই করে না যে মেসেজ ট্রিপের সময় মডিফাই হয়নি।

উদাহরণস্বরূপ, যদি ইমেল একাধিক মেইল সার্ভারের মাধ্যমে গিয়ে এর চূড়ান্ত গন্তব্যে পৌঁছায়, TLS ব্যবহার করলে নিশ্চিত হবে যে সার্ভারগুলোর মধ্যে এনক্রিপশন আছে, কিন্তু প্রতিটি সার্ভার মেসেজ কন্টেন্ট আল্টার করতে পারে। এটিকে সমাধান করার জন্য, আমরা SPF, DKIM, এবং DMARC তৈরি করেছি।

SPF (Sender Policy Framework)

SPF একটি ডোমেনের মালিককে (যেমন google.com) এর DNS-এ একটি TXT রেকর্ড সেট করতে দেয় যেটি বলে কোন সার্ভারগুলো সেটি ডোমেন থেকে মেইল পাঠাতে অনুমোদিত (বিভিন্ন হোস্টিং প্রোভাইডারের জন্য কীভাবে করবেন তার ইনস্ট্রাকশন এই সাইটে চেক আউট করুন)।

এটি কীভাবে কাজ করে?

এই রেকর্ডটি ডিভাইসগুলো লিস্ট করে (সাধারণত IP দিয়ে) যেগুলো অনুমোদিত এবং নিচের অপশনগুলোর একটি দিয়ে শেষ হতে পারে:

-all = যদি চেক ফেল করে (ইমেলের সোর্স লিস্ট করা ডিভাইসগুলোর মধ্যে একটা নয়) তবে রেজাল্ট হলো HardFail। অধিকাংশ মেইল সিস্টেম এই মেসেজগুলোকে স্প্যাম হিসেবে মার্ক করে।

?all = = যদি চেক ফেল করে (ইমেলের সোর্স লিস্ট করা ডিভাইসগুলোর মধ্যে একটা নয়) তবে রেজাল্ট হলো নিউট্রাল। এটি সাধারণত টেস্টিংয়ের জন্য ব্যবহৃত হয়, প্রোডাকশন ডোমেনের জন্য নয়।

~all =  যদি চেক ফেল করে (ইমেলের সোর্স লিস্ট করা ডিভাইসগুলোর মধ্যে একটা নয়) তবে রেজাল্ট হলো SoftFail। এর মানে এই মেসেজ সাস্পিশিয়াস, কিন্তু অপরিহার্যভাবে একটি পরিচিত ব্যাড নয়। কিছু মেইল সিস্টেম এই মেসেজগুলোকে স্প্যাম হিসেবে মার্ক করে, কিন্তু অধিকাংশ করছে না।

SPF হেডারগুলো সার্ভারগুলোর জন্যও হেল্পফুল হতে পারে, যেন তারা মেসেজ প্রসেস করছে। উদাহরণস্বরূপ যদি একটি সার্ভার একটি নেটওয়ার্কের এজে থাকে, এটি জানে যে এটি যেসব মেসেজ রিসিভ করছে সেগুলো সেন্ডারের SPF রেকর্ডের সার্ভারগুলো থেকে আসা উচিত। এটি সার্ভারগুলোক স্প্যাম দ্রুত উijdens করতে সাহায্য করে। যদিও এটি শুনতে ভালো লাগে, দুর্ভাগ্যক্রমে, SPF-এ কয়েকটি বড় সমস্যা রয়েছে।

1. SPF একটি মেইল সার্ভারকে বলে না মেসেজটির সাথে কী করতে হবে - অর্থাৎ একটি মেসেজ SPF চেক ফেল করলেও ডেলিভার হয়ে যেতে পারে।
2. একটি SPF রেকর্ড সেটি 'from' অ্যাড্রেসকে দেখে না যা ইউজারটি দেখে, এটি 'return-path'-কে দেখে। এটি মূলত একটি চিঠিতে আপনি যে রিটার্ন অ্যাড্রেস লিখেন তার সমতুল্য। এটি মেইল সার্ভারকে বলে চিঠিটি কোথায় রিটার্ন করতে হবে (এবং এটি ইমেল হেডারগুলোর মধ্যে স্টোর থাকে — এসেনশিয়ালি টেকনিক্যাল ইনফরমেশন যা সার্ভাররা ইমেল প্রসেস করতে ব্যবহার করে)।
   এর মানে আমি from: অ্যাড্রেসে যা খুশি তাই দিতে পারি এবং এটিএ SPF চেককে প্রভাবিত করবে না। ফ্যাক্টulton, উভয় ইমেল অ্যাড্রেসই রিলেটিভলি স্পুফ করা যায় একটি হ্যাকারের 의해। কারণ কোনো এনক্রিপশন ইনভলভড নেই, SPF হেডারগুলো ফুলি ট্রাস্ট করা যায় না।
3. SPF রেকর্ডগুলো باستمرار আপ টু ডেট রাখতে হয় যা বড়, সর্বদা পরিবর্তনশীল সংস্থাগুলোর জন্য কঠিন হতে পারে।
4. ফরওয়ার্ডিং SPF-কে ভাঙে। কারণ যদি google.com-এ থেকে একটি ইমেল bob@bobsburgers.com দ্বারা ফরওয়ার্ড করা হয়, এনভেলপ সেন্ডার অপরিবর্তিত থাকে (from অ্যাড্রেস এখনও google.com বলে)। রিসিভিং মেইল সার্ভার চিন্তা করে এটি google.com থেকে আসছে দাবি করছে, কিন্তু আসছে bobsburgers.com থেকে, তাই SPF চেক ফেল করে (যদিও মেইল আসলে google.com থেকে আসছে)।

SPF-র ওপর আরও পড়তে চাইলে এই আর্টিকেলগুলো চেক আউট করুন। আপনি একটি নির্দিষ্ট ডোমেনে SPF এবং DMARC রেকর্ড কনফিগারড আছে কিনা এখানে চেক করতে পারেন।

DKIM (DomainKeys Identified Mail)

DKIM SPF-এর মতো। এটি সেন্ডিং ডোমেনের DNS-এ TXT রেকর্ডও ব্যবহার করে, এবং এটি মেসেজটির কিছু অথেনটিকেশন প্রদান করে। এটি চেষ্টা করে যাচাই করতে যে মেসেজ ট্রানজিট-এ আল্টার হয়নি।

এটি কীভাবে কাজ করে?

সেন্ডিং ডোমেন একটি পাবলিক/প্রাইভেট কী পেয়ার জেনারেট করে এবং পাবলিক কীটি ডোমেনের DNS TXT রেকর্ডে রাখে (আপনি যদি না জানেন পাবলিক/প্রাইভেট কী পেয়ার কী, ক্রিপ্টোগ্রাফি সম্পর্কে এই আর্টিকেল চেক আউট করুন)।

তারপর, ডোমেনের মেইল সার্ভারগুলো (আউটার বাউন্ডারি — যেসব সার্ভার ডোমেনের বাইরে মেইল পাঠাচ্ছে (উদাহরণস্বরূপ gmail.com থেকে outlook.com-এ)) প্রাইভেট কী ব্যবহার করে পুরো মেসেজ বডির একটি সিগনেচার জেনারেট করে, হেডারসহ।

সিগনেচার জেনারেট করা সাধারণত টেক্সটকে হ্যাশ এবং এনক্রিপ্ট করতে হয় (এই প্রসেসের আরও ডিটেইলসের জন্য এই আর্টিকেল চেক আউট করুন)।

রিসিভিং মেইল সার্ভাররা DNS TXT রেকর্ডের পাবলিক কী ব্যবহার করে সিগনেচার ডিক্রিপ্ট করে এবং তারপর মেসেজ এবং প্রাসঙ্গিক হেডারগুলো হ্যাশ করে (যেকোনো হেডার যা সেন্ডারের ইনফ্রাস্ট্রাকচারের ভিতরে তৈরি হয়েছিল — উদাহরণস্বরূপ যদি একাধিক Gmail সার্ভার ইমেল প্রসেস করে outlook.com-এ এক্সটার্নালি পাঠানোর আগে)।

সার্ভারটি তখন চেক করে দুটি হ্যাশ ম্যাচ করে কিনা। যদি ম্যাচ করে, তবে মেসেজ সম্ভবত আল্টারড নয় (যদি কেউ সেন্ডারের প্রাইভেট কী কমপ্রোমাইজ না করে) এবং PURPORTED সেন্ডার থেকে আসছে। যদি হ্যাশগুলো ম্যাচ না করে, তবে মেসেজ PURPORTED সেন্ডার থেকে আসেনি, অথবা ট্রানজিট-এ কোনো অন্য সার্ভার দ্বারা আল্টার করা হয়েছে, অথবা উভয়।

DKIM একটি খুব স্পেসিফিক টাস্ক খুব ভালো করে — প্রশ্নের जवাব দেয় 'এই ইমেল কি ট্রানজিট-এ আল্টার হয়েছিল বা PURPORTED সেন্ডার থেকে আসেনি?'। তবে, এটি সেটিই করে। এটি আপনাকে বলে না কীভাবে ডিল করবেন ইমেল যেগুলো এই টেস্ট ফেল করেছে, কোন সার্ভার মেসেজটি আল্টার করল, বা কী আল্টারেশন করা হয়েছিল।  

DKIM কিছু ISP (Internet Service Providers) দ্বারা আপনার ডোমেনের রেপুটেশন নির্ধারণের জন্যও ব্যবহার হয় (আপনি কি অনেক স্প্যাম পাঠাচ্ছেন? আপনার এনগেজমেন্ট কম? আপনার ইমেলগুলো কতবার বাউন্স করে?)।

DKIM-র ওপর আরও পড়তে চাইলে এই আর্টিকেল চেক আউট করুন। আপনি একটি DKIM রেকর্ড এখানে ভ্যালিডেট করতে পারেন।

DMARC (Domain-Based Message Authentication, Reporting, and Conformance)

DMARC এসেনশিয়ালি মেইল সার্ভারদের জন্য ইনস্ট্রাকশন যেগুলো SPF এবং DKIM রেকর্ডগুলো কীভাবে হ্যান্ডেল করতে হবে। এটি নিজে কোনো টেস্ট পারফর্ম করে না, কিন্তু এটি মেইল সার্ভারকে বলে SPF এবং DKIM যেসব চেক পারফর্ম করে সেগুলো কীভাবে হ্যান্ডেল করতে হবে।

পার্টিসিপেটিং ISPরা পাবলিশড DMARC রেকর্ডগুলো দেখে এবং সেগুলো ব্যবহার করে DKIM বা SPF ফেইলচারের সাথে কীভাবে ডিল করবেন সেটি নির্ধারণ করে। তাই উদাহরণস্বরূপ, একটি কমনলি স্পুফড ব্র্যান্ড একটি DMARC রেকর্ড পাবলিশ করতে পারে যেটি বলে যদি DKIM বা SPF ফেল করে, মেসেজটি ড্রপ করো।

প্রায়ই ISPরা আপনার ডোমেনের এক্টিভিটির রিপোর্টও পাঠায় আপনার কাছে ইমেলের সোর্স এবং DKIM/SPF পাস/ফেল ছিল কিনা সেটি সহ। এর মানে আপনি দেখতে পাবেন কখন লোকেরা আপনার ডোমেন স্পুফ করছে (আপনার ডোমেন থেকে পাঠানো হয়েছে বলে দাবি করছে) বা আপনার মেসেজগুলো আল্টার করছে।

DMARC ইমপ্লিমেন্ট করতে, আপনাকে একটি DMARC রেকর্ড তৈরি করতে হবে, আপনার 니ডসের উপর ভিত্তি করে (আপনার ইমেল ট্রাফিক মনিটর করতে থেকে আপনার সকল ইমেল সোর্স বের করতে, অ্যাকশন নেওয়ার অনুরোধ করা পর্যন্ত, যেন DKIM বা SPF-এ ফেল করা যেকোনো ইমেল রিজেক্ট হয়)। আপনি এ সম্পর্কে আরও জানতে পারেন এখানে এবং এখানে।

DMARC-র ওপর আরও পড়তে চাইলে এই আর্টিকেল চেক আউট করুন। আপনি একটি নির্দিষ্ট ডোমেনে SPF এবং DMARC রেকর্ড কনফিগারড আছে কিনা এখানে চেক করতে পারেন।

র‍্যাপ আপ

এই সিকিউরিটি মেজারগুলোর কেউই পারফেক্ট নয়, কিন্তু একসাথে, তারা বিশ্বব্যাপী ইমেল সিস্টেমের সিকিউরিটি উন্নত করতে একটি ভালো কাজ করে।

যিতनी বেশি সংস্থা এই মেজারগুলো অ্যাডপ্ট করবে (চাহে ওপেন সোর্স ইমপ্লিমেন্টেশন দিয়ে চাহে প্রোডাক্টের জন্য পে করে) ততनी সবার জন্য ভালো হবে। একটি প্রোটোকল বা প্রোডাক্ট ডেভেলপ হওয়ার পর সিকিউরিটি যোগ করা সাধারণত ডেভেলপমেন্টের সময় সিকিউরিটি বিল্ট-ইন করার চেয়ে বেশি খরচবহুল, কম ইফেক্টিভ, এবং হার্ডার টু ইমপ্লিমেন্ট।

তবে, বর্তমান ইন্টারনেট যেসব প্রোটোকলের ওপর নির্ভর করে সেগুলো আরাম্বিক ইন্টারনেটের জন্য ডিজাইন করা হয়েছিল — একজন ছোট গ্রুপ এন্থুসিয়াস্ট, সায়েন্টিস্ট, এবং সরকারি অফিসারদের জন্য — একটি বিশ্বব্যাপী নেটওয়ার্কের জন্য নয় যার ওপর আমরা বিল্ডিং, স্মার্ট ডিভাইস, পাবলিক ট্রানজিট, নিউক্লিয়ার প্ল্যান্ট(!), এবং আরও অনেক কিছু রান করি।

অতএব, ইন্টারনেট যতটা বিস্তৃত হচ্ছে, আমাদের আমাদের নির্ভরশীল সিস্টেমগুলো সিকিউর করার নতুন উপায় উপاয় করতে হবে এবং ডেভেলপ করতে হবে।