ইমেইল কিভাবে কাজ করে?

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

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

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

SMTP বা সাধারণ মেল ট্রান্সফার প্রোটোকল ব্যবহার করে একটি মেল সার্ভারে মেল পাঠানো হতো। SMTP ইমেইলের জন্য একটি যোগাযোগ প্রোটোকল।

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

পোস্ট অফিস প্রোটোকল (POP3) ব্যবহার করে সার্ভার থেকে মেল ডাউনলোড করা হবে। এটি সংযোগ করতে পারে, বার্তাগুলি পুনরুদ্ধার করতে পারে, সেগুলিকে ক্লায়েন্টের কম্পিউটারে সঞ্চয় করতে পারে এবং সার্ভারে মুছে ফেলতে বা ধরে রাখতে পারে৷

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

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

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

ইমেল কিভাবে সুরক্ষিত হয়?

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

আশ্চর্যজনকভাবে, এটি একটি সমস্যা হয়ে ওঠে যখন ইন্টারনেট কিছু সরকারী এবং গবেষণা গোষ্ঠী থেকে এমন কিছুতে প্রসারিত হয় যা বিশ্বের বেশিরভাগই মূলত সবকিছু করতে ব্যবহার করে। খুব শীঘ্রই স্প্যাম এবং ফিশিং ইমেলগুলি প্রত্যেকের জন্য একটি বিশাল সমস্যা হয়ে ওঠে (এবং থেকে যায়)৷

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

বেশিরভাগ জায়গায় TLS (ট্রান্সপোর্ট লেয়ার সিকিউরিটি, SSL এর প্রতিস্থাপন, সুরক্ষিত সকেট লেয়ার), একটি ক্রিপ্টোগ্রাফিক প্রোটোকল ব্যবহার করে যা ট্রানজিটে এনক্রিপশন প্রদান করে। এটি কখন বার্তা প্রেরণ করা হচ্ছে তার জন্য সুরক্ষা প্রদান করে, তবে ডেটা যখন বিশ্রামে থাকে (উদাহরণস্বরূপ, আপনার কম্পিউটারে সংরক্ষণ করা হয়) তখন নয়।

এটি নিশ্চিত করে যে একটি বার্তা MTA থেকে MTA তে যাওয়ার সময় পরিবর্তন বা স্নুপ করা হয় না। যাইহোক, এটি যাচাই করে না যে ভ্রমণের সময় বার্তাটি পরিবর্তন করা হয়নি।

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

SPF (প্রেরক নীতি কাঠামো)

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

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

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

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

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

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

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

1. এসপিএফ একটি মেল সার্ভারকে বার্তাটির সাথে কী করতে হবে তা জানায় না - যার অর্থ একটি বার্তা একটি এসপিএফ চেক ব্যর্থ করতে পারে এবং এখনও বিতরণ করা যেতে পারে।
2. একটি এসপিএফ রেকর্ড ব্যবহারকারীর দেখা 'থেকে' ঠিকানার দিকে তাকাচ্ছে না, এটি 'রিটার্ন-পাথ' দেখছে। এটি মূলত আপনি একটি চিঠিতে যে রিটার্ন অ্যাড্রেস লেখেন তার সমতুল্য। এটি মেল সার্ভারকে বলে যে চিঠিটি পরিচালনা করে যেখানে বার্তাটি ফেরত দিতে হবে (এবং এটি ইমেল শিরোনামে সংরক্ষণ করা হয় - মূলত প্রযুক্তিগত তথ্য সার্ভারগুলি ইমেল প্রক্রিয়া করতে ব্যবহার করে)।
   তার মানে আমি from:address-এ যা চাই তা রাখতে পারি এবং এটি SPF চেককে প্রভাবিত করবে না। প্রকৃতপক্ষে, এই দুটি ইমেল ঠিকানাই হ্যাকার দ্বারা তুলনামূলকভাবে জালিয়াতি করা যেতে পারে। কোনো এনক্রিপশন জড়িত না থাকায়, SPF শিরোনাম সম্পূর্ণরূপে বিশ্বাস করা যায় না।
3. এসপিএফ রেকর্ডগুলি ক্রমাগত আপ টু ডেট রাখতে হবে যা বৃহৎ, সর্বদা পরিবর্তিত সংস্থাগুলিতে কঠিন হতে পারে৷
4. ফরোয়ার্ড করা SPF কে বিরত করে। এর কারণ হল যদি google.com থেকে একটি ইমেল, bob@bobsburgers.com দ্বারা ফরওয়ার্ড করা হয়, তাহলে খামের প্রেরক অপরিবর্তিত থাকে (এর থেকে ঠিকানাটি এখনও google.com বলে)৷ প্রাপক মেল সার্ভার মনে করে যে এটি google.com থেকে এসেছে বলে দাবি করছে, কিন্তু bobsburgers.com থেকে আসছে, তাই এটি SPF চেক করতে ব্যর্থ হয়েছে (যদিও মেলটি আসলে google.com থেকে আসছে)।

এসপিএফ সম্পর্কে আরও পড়ার জন্য এই নিবন্ধগুলি দেখুন। আপনি একটি নির্দিষ্ট ডোমেনে SPF এবং DMARC রেকর্ডগুলি এখানে কনফিগার করা আছে কিনা তা পরীক্ষা করতে পারেন৷

DKIM (ডোমেনকি আইডেন্টিফাইড মেল)

ডিকেআইএম এসপিএফের অনুরূপ। এটি পাঠানোর ডোমেনের DNS-এ TXT রেকর্ডগুলিও ব্যবহার করে এবং এটি নিজেই বার্তাটির কিছু প্রমাণীকরণ প্রদান করে। এটি যাচাই করার চেষ্টা করে যে ট্রানজিটে বার্তাগুলি পরিবর্তন করা হয়নি৷

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

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

তারপর, ডোমেনের মেল সার্ভারগুলি (বাইরের সীমানায় - যে সার্ভারগুলি ডোমেনের বাইরে মেল পাঠাচ্ছে (যেমন gmail.com থেকে outlook.com)) ব্যক্তিগত কী ব্যবহার করে সমগ্র বার্তার অংশের একটি স্বাক্ষর তৈরি করতে, সহ হেডার

একটি স্বাক্ষর তৈরি করার জন্য সাধারণত পাঠ্যটিকে হ্যাশ এবং এনক্রিপ্ট করা প্রয়োজন (এই প্রক্রিয়া সম্পর্কে আরও বিশদ বিবরণের জন্য, এই নিবন্ধটি দেখুন)।

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

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

ডিকেআইএম একটি খুব নির্দিষ্ট কাজে একটি খুব ভাল কাজ করে - 'এই ইমেলটি কি ট্রানজিটে পরিবর্তন করা হয়েছিল নাকি প্রেরিত প্রেরকের কাছ থেকে নয়?' প্রশ্নের উত্তর দেওয়া। যাইহোক, যে সব এটা করে. এই পরীক্ষায় ব্যর্থ হওয়া ইমেলগুলির সাথে কীভাবে মোকাবিলা করতে হবে, কোন সার্ভার বার্তাটি পরিবর্তন করেছে বা কী পরিবর্তন করা হয়েছে তা এটি আপনাকে বলে না।

আপনার ডোমেনের খ্যাতি নির্ধারণের জন্য কিছু ISP, বা ইন্টারনেট পরিষেবা প্রদানকারীরাও DKIM ব্যবহার করে (আপনি কি প্রচুর স্প্যাম পাঠাচ্ছেন? আপনার কি কম ব্যস্ততা আছে? আপনার ইমেলগুলি কত ঘন ঘন বাউন্স হয়?)।

DKIM-এ আরও পড়ার জন্য এই নিবন্ধটি দেখুন। আপনি এখানে একটি DKIM রেকর্ড যাচাই করতে পারেন।

DMARC (ডোমেন-ভিত্তিক বার্তা প্রমাণীকরণ, রিপোর্টিং এবং কনফর্মেন্স)

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

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

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

DMARC বাস্তবায়ন করার জন্য, আপনাকে আপনার প্রয়োজনের উপর ভিত্তি করে একটি DMARC রেকর্ড তৈরি করতে হবে (আপনার ইমেল ট্র্যাফিক পর্যবেক্ষণ থেকে শুরু করে আপনার সমস্ত ইমেল উত্সগুলি কী পদক্ষেপ নেওয়ার জন্য জিজ্ঞাসা করতে হবে, যেমন DKIM বা SPF ব্যর্থ হওয়া ইমেলগুলি প্রত্যাখ্যান করা)। আপনি এখানে এবং এখানে এটি করার বিষয়ে আরও শিখতে পারেন৷

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

র্যাপ আপ

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

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

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

এইভাবে, ইন্টারনেটের প্রসারণ অব্যাহত থাকায়, আমরা যে সিস্টেমগুলির উপর নির্ভর করি সেগুলিকে সুরক্ষিত করার জন্য আমাদের নতুন উপায়গুলিকে মানিয়ে নেওয়া এবং বিকাশ করা চালিয়ে যেতে হবে৷