Email Authentication: ইমেইল স্পুফিং প্রতিরোধে SPF, DKIM এবং DMARC এর সঠিক ব্যবহার!

Email এর মূল প্রোটোকল SMTP 1982 সালে RFC 821 হিসেবে ডিজাইন করা হয়েছিল, যখন ইন্টারনেট ছিল একটি ছোট এবং বিশ্বস্ত সম্প্রদায়। সেই সময়ে কোনো built-in authentication mechanism অন্তর্ভুক্ত করা হয়নি। SMTP তে "From" ক্ষেত্রটি যে কেউ যেকোনো কিছু লিখতে পারে, ঠিক যেমন একটি চিঠির খামে যেকোনো নাম এবং ঠিকানা লেখা যায়।

এই মৌলিক দুর্বলতার কারণে যেকোনো আক্রমণকারী, যার একটি SMTP সার্ভার অ্যাক্সেস আছে, তিনি যেকোনো ডোমেইন থেকে ইমেইল পাঠানোর ভান করতে পারেন। [email protected] থেকে আসা একটি ইমেইল আসলে সম্পূর্ণ ভিন্ন কোনো সার্ভার থেকে আসতে পারে। প্রাপক ইমেইলের header inspect না করলে কোনোভাবেই বুঝতে পারবেন না যে এটি জাল।

Email spoofing এর বিভিন্ন রূপ রয়েছে। Display name spoofing এ আক্রমণকারী "From" ফিল্ডের display name "Your Boss" দেখায় কিন্তু আসল email address অন্য। Exact domain spoofing এ আক্রমণকারী আপনার ডোমেইন ব্যবহার করে। Lookalike domain ব্যবহার করে homograph attack যেখানে paypa1.com এর মতো similar domain ব্যবহার করা হয়। Reply-to manipulation এ ইমেইল legitimate দেখায় কিন্তু reply অন্য জায়গায় চলে যায়। SPF, DKIM এবং DMARC বিশেষভাবে domain-based spoofing প্রতিরোধে ডিজাইন করা হয়েছে।

Sender Policy Framework বা SPF RFC 7208 এ সংজ্ঞায়িত একটি ইমেইল প্রমাণীকরণ প্রোটোকল। এটি একটি ডোমেইনের জন্য authorized email server এর একটি তালিকা প্রকাশ করে। যখন একটি প্রাপক সার্ভার একটি ইমেইল গ্রহণ করে, এটি ইমেইলের sender domain এর SPF record পরীক্ষা করে এবং নিশ্চিত করে যে ইমেইলটি একটি authorized IP address থেকে এসেছে।

SPF record একটি TXT রেকর্ড হিসেবে DNS এ প্রকাশিত হয়। একটি সাধারণ SPF record দেখতে এরকম হতে পারে: "v=spf1 include:_spf.google.com include:mailgun.org ip4:192.168.1.0/24 ~all"। এখানে v=spf1 SPF version নির্দেশ করে। include directive অন্যান্য SPF record import করে, ip4 specific IP allow করে। শেষের ~all বা -all মেকানিজম unauthorized senders এর জন্য policy নির্দেশ করে।

SPF এর কয়েকটি গুরুত্বপূর্ণ সীমাবদ্ধতা রয়েছে। প্রথমত, এটি শুধুমাত্র "Mail From" বা "Return-Path" header verify করে, যা ব্যবহারকারীর দৃশ্যমান "From" header থেকে ভিন্ন হতে পারে। দ্বিতীয়ত, এটি email forwarding এর সাথে ভাল কাজ করে না কারণ forwarding server এর IP সাধারণত original sender এর SPF এ অনুমোদিত নয়। তৃতীয়ত, SPF record এ 10 টির বেশি DNS lookup নিষিদ্ধ যা জটিল configuration এ সমস্যা সৃষ্টি করতে পারে।

DomainKeys Identified Mail বা DKIM RFC 6376 এ সংজ্ঞায়িত আরেকটি প্রমাণীকরণ প্রোটোকল। SPF এর থেকে এর পদ্ধতি ভিন্ন - এটি cryptographic signature ব্যবহার করে। প্রতিটি outgoing ইমেইল sender এর private key দিয়ে signed হয়, এবং প্রাপক public key দিয়ে signature verify করতে পারেন। Public key DNS এ TXT record হিসেবে প্রকাশিত থাকে।

একটি DKIM signature ইমেইলের header এ যুক্ত হয়, যা দেখতে এরকম: "DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; c=relaxed/relaxed; q=dns/txt; t=1683724815; bh=...; h=From:To:Subject:Date; b=..."। এখানে d= signing domain নির্দেশ করে, s= selector যা DNS এ public key খুঁজতে ব্যবহৃত হয়, h= signed header এর তালিকা, bh= body hash, এবং b= actual signature।

DKIM এর সবচেয়ে গুরুত্বপূর্ণ সুবিধা হলো এটি email forwarding এর মধ্য দিয়ে অক্ষুণ্ণ থাকে, যতক্ষণ না forwarding server header বা body modify করে। DKIM signature ইমেইলের অখণ্ডতাও verify করে - যদি transit এ ইমেইল পরিবর্তন হয়, signature invalid হয়ে যাবে। তবে DKIM এ কিছু complexity রয়েছে যেমন key rotation, selector management এবং canonicalization এর সঠিক handling।

DKIM key এর শক্তিও বিবেচ্য বিষয়। আগে 1024-bit RSA key জনপ্রিয় ছিল কিন্তু আধুনিক standard 2048-bit বা তার বেশি প্রস্তাব করে। DKIM key regular rotation একটি best practice কিন্তু অনেক প্রতিষ্ঠানে অবহেলিত থাকে। কিছু সম্প্রতি প্রকাশিত গবেষণায় দেখানো হয়েছে কীভাবে দুর্বল DKIM key এর সুযোগ নিয়ে আক্রমণ করা যায়।

Domain-based Message Authentication, Reporting and Conformance বা DMARC RFC 7489 এ সংজ্ঞায়িত একটি policy framework যা SPF এবং DKIM এর উপর ভিত্তি করে গঠিত। DMARC এর মূল অবদান হলো এটি "alignment" এর ধারণা প্রবর্তন করে - SPF বা DKIM verify হওয়া domain অবশ্যই ইমেইলের visible "From" header এর সাথে মিলতে হবে।

DMARC record একটি TXT record হিসেবে _dmarc.yourdomain.com এ প্রকাশিত হয়। একটি সাধারণ DMARC record এরকম: "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; aspf=s; adkim=s"। এখানে p= policy নির্দেশ করে যা none, quarantine বা reject হতে পারে। rua= aggregate report এর জন্য email address। pct= এই policy এর জন্য কত শতাংশ ইমেইল প্রযোজ্য।

DMARC এর reporting feature অত্যন্ত মূল্যবান। দৈনিক বা সাপ্তাহিক aggregate report পাওয়া যায় যা দেখায় কোন source থেকে আপনার ডোমেইন এর নামে ইমেইল পাঠানো হচ্ছে, কতগুলো ইমেইল SPF/DKIM পাস করেছে, এবং কতগুলো ফেল হয়েছে। এই report XML format এ আসে যা সাধারণত human-friendly নয়, কিন্তু dmarcian, Valimail, Mimecast এবং অন্যান্য সার্ভিস এগুলো বিশ্লেষণ এবং visualize করে।

DMARC implementation এর জন্য একটি phased approach সবচেয়ে কার্যকর। প্রথম পর্যায়ে p=none policy দিয়ে শুরু করুন যা শুধু monitoring করে কিন্তু কোনো ইমেইল block করে না। এই সময়ে report বিশ্লেষণ করে সমস্ত legitimate sending source চিহ্নিত করুন এবং SPF/DKIM সঠিকভাবে configure করুন। পরবর্তী পর্যায়ে p=quarantine এবং pct=10 দিয়ে শুরু করে ধীরে ধীরে percentage বাড়ান। অবশেষে p=reject এবং pct=100 এ পৌঁছান।

বাস্তব পরিবেশে SPF, DKIM এবং DMARC বাস্তবায়ন বেশ জটিল হতে পারে। সবচেয়ে বড় চ্যালেঞ্জ হলো shadow IT - বিভিন্ন বিভাগ এবং ব্যবহারকারী আপনার ডোমেইন থেকে ইমেইল পাঠাচ্ছে এমন service যা IT অজানা। DMARC report বিশ্লেষণ এই অজানা sender চিহ্নিত করতে সাহায্য করে। CRM, marketing platform, HR system, recruitment tool, customer support এবং অন্যান্য SaaS application সাধারণত আপনার ডোমেইন থেকে ইমেইল পাঠানোর প্রয়োজন।

Third-party email service বিশেষ care প্রয়োজন। Mailchimp, SendGrid, HubSpot, Salesforce, Constant Contact এর মতো সার্ভিস তাদের নিজস্ব SPF/DKIM configuration এর প্রয়োজন। বেশিরভাগ ক্ষেত্রে এই providers Custom Authentication বা CNAME-based DKIM configuration সমর্থন করে যা আপনার ডোমেইন থেকে authentic-appearing ইমেইল পাঠাতে সাহায্য করে।

Subdomain strategy DMARC implementation এ একটি গুরুত্বপূর্ণ বিবেচনা। আপনি কি প্রতিটি subdomain এর জন্য আলাদা DMARC policy চান? sp= tag subdomain এর জন্য আলাদা policy সেট করতে দেয়। অনেক প্রতিষ্ঠান marketing email এর জন্য আলাদা subdomain ব্যবহার করে এবং primary domain কে strict policy দিয়ে রক্ষা করে।

BIMI বা Brand Indicators for Message Identification একটি নতুন standard যা DMARC এর উপর তৈরি। এটি প্রাপক ইমেইল ক্লায়েন্টে আপনার brand logo প্রদর্শন করতে অনুমতি দেয়, যা trust বৃদ্ধি করে। BIMI বাস্তবায়নের জন্য DMARC অবশ্যই p=quarantine বা p=reject এ থাকতে হবে এবং একটি SVG logo এবং Verified Mark Certificate (VMC) প্রয়োজন।

আধুনিক ইমেইল নিরাপত্তা SPF, DKIM, DMARC এর বাইরেও বিস্তৃত। MTA-STS বা Mail Transfer Agent Strict Transport Security RFC 8461 এ সংজ্ঞায়িত একটি policy framework যা ইমেইল প্রেরকদের নির্দেশ দেয় TLS ব্যবহার করতে। TLS-RPT বা SMTP TLS Reporting এর সাথে এটি ইমেইল transit এর গোপনীয়তা এবং integrity নিশ্চিত করে। DANE বা DNS-based Authentication of Named Entities আরও কঠোর TLS verification প্রদান করে।

ARC বা Authenticated Received Chain RFC 8617 এ সংজ্ঞায়িত যা mailing list এবং forwarding scenario এ ইমেইল প্রমাণীকরণের authenticity বজায় রাখতে সাহায্য করে। ARC এর জন্য সমর্থন ক্রমশ বাড়ছে কিন্তু সর্বজনীন নয়।

ইমেইল gateway এবং anti-phishing সমাধান যেমন Proofpoint, Mimecast, Microsoft Defender for Office 365 এবং Abnormal Security DMARC এর সাথে complementary সুরক্ষা প্রদান করে। এই সমাধানগুলো AI-ভিত্তিক content analysis, sender behavior analysis এবং impersonation detection ব্যবহার করে। DMARC বাস্তবায়নের পরও lookalike domain এবং display name spoofing রোধে এই সমাধান প্রয়োজন।

কর্মীদের প্রশিক্ষণ একটি অপরিহার্য স্তর। নিয়মিত phishing simulation চালান এবং কর্মীদের সন্দেহজনক ইমেইল চেনার প্রশিক্ষণ দিন। ইমেইল header inspection এবং reporting mechanism সম্পর্কে জ্ঞান বৃদ্ধি করুন। External email এ visual indicator যোগ করা একটি কার্যকর কৌশল যা ব্যবহারকারীদের সতর্ক করে।

নিয়মিত monitoring এবং maintenance অপরিহার্য। DMARC report নিয়মিত পর্যালোচনা করুন এবং নতুন legitimate sender যোগ হলে SPF/DKIM update করুন। DKIM key rotation কমপক্ষে বার্ষিক করুন। ব্যর্থতার পর policy adjust করার পরিকল্পনা রাখুন যাতে legitimate ইমেইল ব্যাহত না হয়।