ইমেইল — SMTP, IMAP আর SPF, DKIM, DMARC

১ · ইমেইল ব্যবস্থার অংশগুলো — ডাকঘরের মতো ভাগ করা কাজ

আগের কয়েকটি পর্বে আপনি দেখেছেন application layer-এর protocol কীভাবে নকশা হয় (পর্ব ৩৪), DNS কীভাবে নামকে ঠিকানায় বদলায় (পর্ব ৩৫), আর HTTP কীভাবে ব্রাউজারকে সার্ভারের সাথে কথা বলায় (পর্ব ৩৬)। ইমেইল এদের চেয়ে পুরোনো — ১৯৭১ সালে Ray Tomlinson ARPANET-এ প্রথম এক যন্ত্র থেকে আরেক যন্ত্রে বার্তা পাঠান আর ব্যবহারকারী ও যন্ত্রের নাম আলাদা করতে @ চিহ্ন বেছে নেন। তবু আজও ইমেইল ইন্টারনেটের সবচেয়ে বেশি ব্যবহৃত সেবাগুলোর একটি: চাকরির আবেদন, ব্যাংকের বিবরণী, OTP, অফিসের যোগাযোগ — সবই এর ওপর।

HTTP-তে ব্রাউজার সরাসরি সার্ভারের কাছে চায় আর সাথে সাথে উত্তর পায়। ইমেইল আলাদা: প্রাপক হয়তো তখন অফলাইন, ফোন বন্ধ। তাই ইমেইল চলে store-and-forward নীতিতে — চিঠি এক সার্ভার থেকে আরেক সার্ভারে যায়, প্রতিটি সার্ভার দায়িত্ব নিয়ে জমা রাখে, আর শেষে প্রাপকের mailbox-এ অপেক্ষা করে যতক্ষণ না তিনি পড়েন। পর্ব ৩৪-এর ভাষায়, পাঠানোর দিকটি push (প্রেরক ঠেলে দেয়), আর পড়ার দিকটি pull (প্রাপক টেনে আনেন)।

একটি চিঠির যাত্রা — alice@example.com থেকে bob@example.org

Alice-এর প্রতিষ্ঠানের ডোমেইন example.com, Bob-এর example.org. Alice ল্যাপটপে লিখে “Send” চাপলেন, আর Bob পরে ফোনে পড়লেন। মাঝখানে কী কী ঘটে, ধাপে ধাপে দেখুন। (সব নাম আর ঠিকানা উদাহরণ; IP ঠিকানাগুলো documentation-এর জন্য সংরক্ষিত পরিসর থেকে নেওয়া।)

লক্ষ করুন, SMTP শুধু পাঠানোর protocol: MUA থেকে MSA, আর MTA থেকে MTA. পড়ার কাজে SMTP নেই — সেখানে IMAP বা POP3, বা webmail হলে HTTP. পরীক্ষায় এই ভাগটিই সবচেয়ে বেশি জিজ্ঞেস করা হয়।

২ · MX record — চিঠি কোন সার্ভারে যাবে

পর্ব ৩৫-এ DNS-এর record-এর ধরনগুলো দেখেছেন; সেখানে MX record আর TXT record-এর পরিচয়ও পেয়েছেন। ইমেইলে এই দুটিই মূল চরিত্র: MX বলে চিঠি কোথায় যাবে, আর TXT-এ থাকে SPF, DKIM, DMARC-এর নীতি — যা দিয়ে প্রাপক যাচাই করে চিঠি কে পাঠাতে পারে (অংশ ৭)।

একটি ডোমেইনের MX record দেখতে এমন (DNS zone ফাইলের চেনা লেখায়):

example.org.        3600  IN  MX  10 mx1.example.org.
example.org.        3600  IN  MX  20 mx2.example.org.
mx1.example.org.    3600  IN  A   198.51.100.25
mx2.example.org.    3600  IN  A   203.0.113.25

• Preference (priority) সংখ্যা: ছোট সংখ্যা আগে চেষ্টা হয়। mx1 (১০) না পাওয়া গেলে mx2 (২০). একই সংখ্যার একাধিক MX থাকলে প্রেরক এলোমেলোভাবে বেছে নেয় — এভাবে load ভাগ হয়।
• MX-এর লক্ষ্য একটি নাম, IP নয়: তারপর সেই নামের A/AAAA খুঁজতে হয়। নিয়ম অনুযায়ী MX-কে CNAME-এ নির্দেশ করা উচিত নয়।
• MX না থাকলে: RFC 5321 অনুযায়ী প্রেরক ডোমেইনটির নিজের A/AAAA ঠিকানাকেই mail server ধরে নেয় (implicit MX). যে ডোমেইন ইমেইল একেবারেই গ্রহণ করে না, সে null MX (MX 0 ., RFC 7505) দিয়ে সেটা স্পষ্ট জানাতে পারে — তখন প্রেরক সাথে সাথে bounce দেয়, অহেতুক চেষ্টা করে না।

Linux-এ নিজে দেখতে dig MX example.org +short; Windows-এ nslookup -type=mx example.org. অনুশীলনের জন্য নিজের প্রতিষ্ঠানের ডোমেইন দেখুন।

৩ · SMTP — লেখায় লেখায় একটি কথোপকথন

SMTP (Simple Mail Transfer Protocol)-এর প্রথম মান RFC 821, প্রকাশ হয় ১৯৮২ সালের আগস্টে, Jon Postel-এর লেখা; একই মাসে বার্তার গঠন নিয়ে RFC 822. পরে RFC 2821 (২০০১) হয়ে আজকের মূল মান RFC 5321 (২০০৮)। মাঝখানে ১৯৯৫ সালে (RFC 1869) এসেছিল ESMTP — সার্ভার নিজের বাড়তি ক্ষমতা ঘোষণা করতে পারে, আর ক্লায়েন্ট পুরোনো HELO-র বদলে EHLO দিয়ে শুরু করে।

SMTP চলে TCP-এর ওপর (পর্ব ২৯), আর পুরো কথোপকথন মানুষের পড়ার মতো লেখায় — প্রতিটি লাইন শেষ হয় CRLF দিয়ে। ক্লায়েন্ট একটি command পাঠায় (চার অক্ষরের শব্দ: EHLO, MAIL, RCPT, DATA, QUIT…), সার্ভার একটি তিন অঙ্কের reply code আর ব্যাখ্যা দিয়ে উত্তর দেয়। এটি একটি state machine: ভুল ক্রমে command দিলে (যেমন MAIL-এর আগে RCPT) সার্ভার 503 bad sequence of commands বলে।

নিচে mail.example.com (ক্লায়েন্ট, C) আর mx1.example.org (সার্ভার, S)-এর একটি পূর্ণ কথোপকথন — সরলতার জন্য STARTTLS-এর অংশ বাদ রাখা হয়েছে। Bob আছেন, carol নামে কেউ নেই।

Reply code-এর চার শ্রেণি

সাময়িক আর স্থায়ী ব্যর্থতার পার্থক্যই ইমেইলকে নির্ভরযোগ্য করে: 4xx পেলে পাঠানো MTA চিঠিটি নিজের mail queue-তে রেখে দেয় আর কিছুক্ষণ পরপর আবার চেষ্টা করে। RFC 5321 পরামর্শ দেয় দুই চেষ্টার মাঝে অন্তত ৩০ মিনিট রাখতে আর অন্তত ৪–৫ দিন চেষ্টা চালিয়ে যেতে; বাস্তব সার্ভারগুলো নিজের মতো সময়সূচি রাখে (যেমন Postfix-এর ডিফল্ট সর্বোচ্চ ৫ দিন)। শেষ পর্যন্ত না গেলে প্রেরক bounce পান। অনেক সার্ভার অচেনা প্রেরককে প্রথমবার ইচ্ছা করে 4xx দেয় — greylisting — কারণ সত্যিকারের MTA আবার চেষ্টা করে, কিন্তু অনেক spam পাঠানোর সফটওয়্যার করে না।

নিচের simulator-এ একটি ছোট MX সার্ভার state machine হিসেবে লেখা। প্রথম চেষ্টায় bob greylist-এ পড়ে 451 পায়, carol নেই বলে 550; ৩০ মিনিট পরের চেষ্টায় bob-এর চিঠি যায়, আর body-র একটি বিন্দু-দিয়ে-শুরু লাইন dot-stuffing হয়।

// Toy SMTP: sending MTA (C) talks to example.org's MX (S). Try 1: bob greylisted, carol unknown.
function mx(greylist) {
  let st = "new", rcpt = [], body = [];
  return (line) => {
    if (st === "data") {                                    // body lines get no reply
      if (line === ".") { st = "ready"; return `250 2.0.0 queued for ${rcpt}`; }
      body.push(line.startsWith(".") ? line.slice(1) : line); return null; }  // un-stuff
    const cmd = line.slice(0, 4);
    if (cmd === "EHLO") { st = "ready"; return "250-mx.example.org\n   250 STARTTLS"; }
    if (cmd === "MAIL" && st === "ready") { st = "mail"; return "250 2.1.0 sender ok"; }
    if (cmd === "RCPT" && st === "mail") {
      if (!line.includes("<bob@")) return "550 5.1.1 no such user here";
      if (greylist) return "451 4.7.1 greylisted, try again later";
      rcpt.push("bob"); return "250 2.1.5 recipient ok";
    }
    if (cmd === "DATA" && rcpt.length) { st = "data"; return "354 end data with <CRLF>.<CRLF>"; }
    if (cmd === "QUIT") return `221 2.0.0 bye   (server stored: ${JSON.stringify(body)})`;
    return "503 5.5.1 bad sequence of commands";
  };
}
const body = ["Subject: test", "", "Hi Bob,", ".hidden starts with a dot", "-- Alice"];
const stuffed = body.map(l => (l.startsWith(".") ? "." + l : l));   // dot-stuffing
let queue = ["bob", "carol"];
const why = { 4: "4xx temporary: keep in queue, retry later", 5: "5xx permanent: drop, bounce (NDR) to alice" };
for (const [t, grey] of [[0, true], [30, false]]) {
  console.log(`=== attempt at t=${t} min, queue: ${queue}`);
  const S = mx(grey), say = (l) => { console.log("C: " + l); const r = S(l); if (r) console.log("S: " + r); return r || ""; };
  console.log("S: 220 mx.example.org ESMTP"); say("EHLO mail.example.com"); say("MAIL FROM:<alice@example.com>");
  const ok = queue.filter(u => {
    const c = say(`RCPT TO:<${u}@example.org>`)[0];
    if (why[c]) console.log(`   [${u}: ${why[c]}]`); if (c === "5") queue = queue.filter(x => x !== u);
    return c === "2";
  });
  if (ok.length) { say("DATA"); stuffed.forEach(say); say("."); queue = []; }  say("QUIT");
}

=== attempt at t=0 min, queue: bob,carol
S: 220 mx.example.org ESMTP
C: EHLO mail.example.com
S: 250-mx.example.org
   250 STARTTLS
C: MAIL FROM:<alice@example.com>
S: 250 2.1.0 sender ok
C: RCPT TO:<bob@example.org>
S: 451 4.7.1 greylisted, try again later
   [bob: 4xx temporary: keep in queue, retry later]
C: RCPT TO:<carol@example.org>
S: 550 5.1.1 no such user here
   [carol: 5xx permanent: drop, bounce (NDR) to alice]
C: QUIT
S: 221 2.0.0 bye   (server stored: [])
=== attempt at t=30 min, queue: bob
S: 220 mx.example.org ESMTP
C: EHLO mail.example.com
S: 250-mx.example.org
   250 STARTTLS
C: MAIL FROM:<alice@example.com>
S: 250 2.1.0 sender ok
C: RCPT TO:<bob@example.org>
S: 250 2.1.5 recipient ok
C: DATA
S: 354 end data with <CRLF>.<CRLF>
C: Subject: test
C: 
C: Hi Bob,
C: ..hidden starts with a dot
C: -- Alice
C: .
S: 250 2.0.0 queued for bob
C: QUIT
S: 221 2.0.0 bye   (server stored: ["Subject: test","","Hi Bob,",".hidden starts with a dot","-- Alice"])

৪ · Port 25, 587, 465 — আর খাম বনাম চিঠি

Port 465-এর ইতিহাস জটিল: ১৯৯০-এর দশকের শেষে অল্প সময়ের জন্য “SMTP over SSL”-এর জন্য নিবন্ধিত হয়ে পরে তুলে নেওয়া হয়, তবু অনেক সফটওয়্যার এটি ব্যবহার করে যাচ্ছিল। ২০১৮ সালে RFC 8314 submission-এর জন্য implicit TLS-কেই পছন্দনীয় বলে, কারণ STARTTLS-এ শুরুর অংশ এনক্রিপ্ট-হীন থাকে (অংশ ৮)। আজ ৫৮৭ আর ৪৬৫ দুটোই প্রচলিত।

বাসার সংযোগ থেকে port 25 কেন বন্ধ

অনেক ISP বাসা বা মোবাইল সংযোগ থেকে বাইরের port 25 আটকে রাখে, কারণ ক্ষতিকর সফটওয়্যারে আক্রান্ত কম্পিউটার (botnet) সরাসরি অন্যের MX-এ লাখো spam পাঠাতে পারে। সাধারণ ব্যবহারকারীর এই port লাগেই না — তাঁর অ্যাপ MSA-তে ৫৮৭ বা ৪৬৫ দিয়ে পাঠায়, আর MSA-ই বাইরে relay করে। নিজের মেইল সার্ভার চালাতে চাইলে সমাধান ISP-র অনুমতি বা একটি relay সেবা — firewall ঘুরিয়ে যাওয়ার চেষ্টা নয়। (নীতি ISP-ভেদে ভিন্ন, আর সময়ের সাথে বদলায়।)

Envelope বনাম header — খামের ঠিকানা আর চিঠির “প্রিয় …”

অংশ ৩-এর কথোপকথনে প্রেরক-প্রাপক দুবার এসেছে: একবার MAIL FROM/RCPT TO-তে, আবার DATA-র ভেতরে From:/To: header-এ। প্রথমটি envelope — MTA শুধু এটি দেখে চিঠি পৌঁছায়। দ্বিতীয়টি চিঠির ভেতরের লেখা — MUA পাঠককে দেখায়, কিন্তু পৌঁছানোয় এর কোনো ভূমিকা নেই। ডাকঘরের ভাষায়: পিয়ন খামের ওপরের ঠিকানা পড়েন; ভেতরে কেউ “ইতি, আপনার ব্যাংক ম্যানেজার” লিখলে পিয়ন তা যাচাই করেন না।

• BCC: Alice Bcc-তে dana@example.net দিলেন। MUA বা MSA dana-কে envelope-এ একটি বাড়তি RCPT TO হিসেবে রাখে, কিন্তু পাঠানোর আগে Bcc: header মুছে দেয়। ফলে dana চিঠি পান, অথচ To:/Cc:-এর কেউ জানেন না।
• Mailing list ও forwarding: একটি তালিকার ঠিকানায় পাঠানো চিঠির To:-এ থাকে তালিকার নাম, কিন্তু envelope-এ প্রতিটি সদস্যের ঠিকানা; আর bounce যাতে তালিকা-পরিচালকের কাছে যায়, সেজন্য MAIL FROM বদলানো হয়।
• Spoofing: SMTP নিজে কোনো header যাচাই করে না। কেউ নিজের সার্ভার থেকে From: security@example.com লিখে পাঠাতে পারে, যদিও সে example.com-এর কেউ নয় — email spoofing. অংশ ৭-এর SPF, DKIM, DMARC ঠিক এই ফাঁক বন্ধ করতে এসেছে।

৫ · বার্তার গঠন — RFC 5322 header, Received আর MIME

DATA-র ভেতরে যা যায়, তার নিয়ম RFC 5322 (আগে RFC 822, RFC 2822): ওপরে header-এর সারি — প্রতিটি নাম: মান — তারপর একটি ফাঁকা লাইন, তারপর body. মূল header-গুলো:

Received header — নিচ থেকে ওপরে পড়ুন

প্রতিটি MTA চিঠি নেওয়ার সময় একটি নতুন Received লাইন সবার ওপরে বসায়। তাই সবচেয়ে নিচেরটি প্রথম ধাপ, সবচেয়ে ওপরেরটি শেষ ধাপ। কুরিয়ারের ট্র্যাকিং ইতিহাসের মতো — শুধু উল্টো ক্রমে লেখা। Bob-এর কাছে পৌঁছানো চিঠির ওপরের অংশ (উদাহরণ):

Return-Path: <alice@example.com>
Received: from mail.example.com (mail.example.com [192.0.2.25])
        by mx1.example.org with ESMTPS id 4F2A1C
        for <bob@example.org>; Mon, 26 Oct 2026 10:15:09 +0600
Received: from [10.0.2.15] (unknown [192.0.2.140])
        by smtp.example.com with ESMTPSA id 77B0E2
        for <bob@example.org>; Mon, 26 Oct 2026 10:15:07 +0600
Authentication-Results: mx1.example.org; spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com; dmarc=pass header.from=example.com
From: Alice <alice@example.com>
To: Bob <bob@example.org>

নিচ থেকে পড়লে: Alice-এর ল্যাপটপ (অফিসের ভেতরের ঠিকানা 10.0.2.15, বাইরে দেখা গেছে 192.0.2.140) MSA smtp.example.com-এ জমা দিল — ESMTPSA-র S মানে TLS, A মানে AUTH. দুই সেকেন্ড পরে mail.example.com থেকে mx1.example.org-এ গেল TLS-সহ। সাবধানতা: প্রতিটি Received শুধু সেই সার্ভারের দাবি; নিজের সার্ভারের লাইন ভরসাযোগ্য, কিন্তু নিচের লাইন প্রেরক বানিয়ে লিখতে পারে।

MIME — ৭-bit ASCII-র পৃথিবীতে বাংলা আর ফাইল

RFC 822-এর ইমেইল ছিল শুধু ৭-bit ASCII লেখা, লাইন ১০০০ অক্ষরের কম। বাংলা, ছবি বা PDF পাঠানোর উপায় ছিল না। ১৯৯২ সালে প্রথম, আর ১৯৯৬ সালে RFC 2045–2049-এ চূড়ান্ত হয় MIME (Multipurpose Internet Mail Extensions). মূল কৌশল: SMTP না বদলে, বার্তার ভেতরে কিছু নতুন header যোগ করে যেকোনো ডেটাকে ASCII লেখায় মুড়ে দেওয়া।

• MIME-Version: 1.0 — “এটি MIME বার্তা”।
• Content-Type: — কী ধরনের জিনিস: text/plain; charset=UTF-8, text/html, image/png, application/pdf.
• multipart/alternative — একই লেখার একাধিক রূপ (সাধারণ লেখা আর HTML); MUA যেটা ভালো দেখাতে পারে সেটা দেখায়।
• multipart/mixed — আলাদা আলাদা অংশ: লেখা আর সংযুক্ত ফাইল। অংশগুলো আলাদা হয় একটি boundary লাইন দিয়ে: --boundary প্রতিটি অংশের আগে, আর শেষে --boundary--. Boundary এমন হতে হবে যা কোনো অংশের ভেতরে নেই।
• Content-Transfer-Encoding: — ডেটাকে কীভাবে ASCII বানানো হলো: base64 বা quoted-printable (৮-bit সমর্থিত হলে 8bit-ও চলে)।

Base64 — হাতে হিসাব

নিয়ম: ৩ বাইট = ২৪ bit; সেটিকে ৬ bit করে ৪ টুকরো; প্রতিটি টুকরো (০–৬৩) একটি অক্ষরে — A–Z (০–২৫), a–z (২৬–৫১), 0–9 (৫২–৬১), + (৬২), / (৬৩)। শেষে বাইট কম পড়লে = দিয়ে পূরণ। উদাহরণ “Hi!”:

H        i        !
01001000 01101001 00100001          ← ৩ বাইট = ২৪ bit
010010 000110 100100 100001          ← ৬ bit করে ৪ টুকরো
  18      6      36     33
   S      G       k      h           → "SGkh"

১৮ = S (A থেকে ১৮তম), ৬ = G, ৩৬ = ৩৬ − ২৬ = ১০ → k, ৩৩ = ৩৩ − ২৬ = ৭ → h. ফলে আকার বাড়ে ৪/৩ গুণ, প্রায় ৩৩%, আর MIME প্রতি ৭৬ অক্ষরে লাইন ভাঙে — তাই ১০ MB-র ফাইল তারে প্রায় ১৩.৭ MB হয়ে যায়। এজন্য মেইল সরবরাহকারীর “২৫ MB সংযুক্তির সীমা” আসলে মূল ফাইলের প্রায় ১৮–১৯ MB.

Quoted-printable প্রায় পুরোটা ASCII লেখার জন্য ভালো: সাধারণ অক্ষর যেমন আছে তেমন, শুধু অন্য বাইট =XX (হেক্স) আকারে। “café” হয় caf=C3=A9 (é-র UTF-8 বাইট C3 A9), আর লম্বা লাইনের শেষে = মানে “নরম লাইন-ভাঙা”। বাংলার প্রতিটি অক্ষর UTF-8-এ ৩ বাইট, তাই quoted-printable-এ একটি বাংলা অক্ষর ৯টি ASCII অক্ষর হয়ে যায় — বাংলার জন্য base64 অনেক সাশ্রয়ী।

Header-এ বাংলা: encoded-word

Header-এর ভেতরে Content-Transfer-Encoding দেওয়া যায় না, তাই RFC 2047 আনে encoded-word: =?charset?B?base64?= (B = base64) বা =?charset?Q?…?= (Q = quoted-printable-এর মতো)। একটি encoded-word ৭৫ অক্ষরের বেশি হতে পারে না; লম্বা subject কয়েকটি word-এ ভাঙে। (নতুন SMTPUTF8 এক্সটেনশন, RFC 6531, দুই সার্ভার সমর্থন করলে header আর ঠিকানায় সরাসরি UTF-8 পাঠাতে দেয় — তবে encoded-word এখনো সর্বত্র চলে।)

নিচের কোড একটি বাংলা subject-কে encoded-word বানায়, একটি ছোট CSV ফাইলকে base64-এ মোড়ে, পুরো multipart/mixed বার্তা তৈরি করে, তারপর প্রাপকের মতো খুলে আবার আসল লেখা বের করে।

// MIME by hand: Bangla subject as an RFC 2047 encoded-word, a base64 attachment, multipart/mixed.
const enc = new TextEncoder(), dec = new TextDecoder();
const b64 = (bytes) => btoa(String.fromCharCode(...bytes));            // bytes -> base64 text
const unb64 = (s) => Uint8Array.from(atob(s), (c) => c.charCodeAt(0));  // base64 text -> bytes
const wrap = (s) => s.match(/.{1,76}/g).join("\r\n");                     // MIME: lines of max 76

const hi = enc.encode("Hi!");                                              // the worked example
console.log("Hi! =", [...hi].map((b) => b.toString(2).padStart(8, "0")).join(" "), "->", b64(hi));
const subj = enc.encode("ঢাকা অফিস");
const word = `=?UTF-8?B?${b64(subj)}?=`;
console.log(`subject: ${subj.length} UTF-8 bytes -> ${word}`);

const csv = enc.encode("roll,name,marks\n1,Rahim,78\n2,Karim,85\n3,Salma,91\n4,Nodi,88\n");
const B = "b39-7f3a";                        // boundary: must never appear inside any part
const msg = ["From: alice@example.com", "To: bob@example.org", `Subject: ${word}`,
  "MIME-Version: 1.0", `Content-Type: multipart/mixed; boundary="${B}"`, "",
  `--${B}`, "Content-Type: text/plain; charset=UTF-8", "Content-Transfer-Encoding: base64", "",
  wrap(b64(enc.encode("ফাইল সংযুক্ত"))),
  `--${B}`, 'Content-Type: text/csv; name="marks.csv"', "Content-Transfer-Encoding: base64",
  'Content-Disposition: attachment; filename="marks.csv"', "", wrap(b64(csv)), `--${B}--`, ""].join("\r\n");
console.log(`----- message (${csv.length}-byte file -> ${b64(csv).length} base64 chars) -----`);
console.log(msg.replace(/\r/g, ""));

console.log("----- receiver decodes -----");
const w = msg.match(/=\?UTF-8\?B\?([^?]+)\?=/)[1];
console.log("Subject:", dec.decode(unb64(w)));
for (const part of msg.split(`--${B}`).slice(1, -1)) {
  const [head, body] = part.split("\r\n\r\n");
  const type = head.match(/Content-Type: ([^;\r]+)/)[1];
  const bytes = unb64(body.replace(/\r\n/g, ""));
  console.log(`[${type}, ${bytes.length} bytes]`, JSON.stringify(dec.decode(bytes)));
}

Hi! = 01001000 01101001 00100001 -> SGkh
subject: 25 UTF-8 bytes -> =?UTF-8?B?4Kai4Ka+4KaV4Ka+IOCmheCmq+Cmv+CmuA==?=
----- message (59-byte file -> 80 base64 chars) -----
From: alice@example.com
To: bob@example.org
Subject: =?UTF-8?B?4Kai4Ka+4KaV4Ka+IOCmheCmq+Cmv+CmuA==?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="b39-7f3a"

--b39-7f3a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

4Kar4Ka+4KaH4KayIOCmuOCmguCmr+CngeCmleCnjeCmpA==
--b39-7f3a
Content-Type: text/csv; name="marks.csv"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="marks.csv"

cm9sbCxuYW1lLG1hcmtzCjEsUmFoaW0sNzgKMixLYXJpbSw4NQozLFNhbG1hLDkxCjQsTm9kaSw4
OAo=
--b39-7f3a--

----- receiver decodes -----
Subject: ঢাকা অফিস
[text/plain, 34 bytes] "ফাইল সংযুক্ত"
[text/csv, 59 bytes] "roll,name,marks\n1,Rahim,78\n2,Karim,85\n3,Salma,91\n4,Nodi,88\n"

৬ · Push আর pull — POP3, IMAP, webmail আর একটি আসল SMTP সংযোগ

SMTP ঠেলে পাঠায়: প্রেরকের সার্ভার নিজে উদ্যোগ নিয়ে প্রাপকের সার্ভারে যায়। কিন্তু Bob-এর ফোন সার্ভার নয় — তার স্থায়ী ঠিকানা নেই, সে প্রায়ই NAT-এর পেছনে (পর্ব ১৯) বা বন্ধ। তাই শেষ ধাপটি টানা: Bob-এর অ্যাপ নিজে সার্ভারের কাছে গিয়ে জিজ্ঞেস করে “নতুন কিছু আছে?” এই কাজের দুটি প্রধান protocol:

Webmail আর API

ব্রাউজারে Gmail বা Outlook খুললে আপনার যন্ত্র আর IMAP বা SMTP বলে না — ব্রাউজার webmail সার্ভারের সাথে HTTPS-এ কথা বলে (পর্ব ৩৬-এর HTTP, আর পর্ব ৪৮-এর TLS). Webmail সার্ভার ভেতরে mailbox থেকে পড়ে, আর পাঠানোর সময় সরবরাহকারীর MTA বাইরের ডোমেইনে সাধারণ SMTP দিয়েই পাঠায়। অর্থাৎ শেষ মাইলে HTTP, সার্ভার থেকে সার্ভারে এখনো SMTP. বড় সরবরাহকারীরা নিজস্ব HTTP API-ও দেয়, আর মান হিসেবে আছে JMAP (RFC 8620, 8621; ২০১৯) — IMAP-এর কাজ JSON আর HTTP দিয়ে, মোবাইলের জন্য বেশি দক্ষভাবে। অ্যাপ থেকে বিপুল পরিমাণে চিঠি পাঠানোর সেবাগুলোও (লেনদেনের রসিদ, OTP) প্রায়ই HTTP API নেয়, কিন্তু নিজেরা বাইরে SMTP দিয়েই পৌঁছায়।

আসল TCP-তে একটি SMTP কথোপকথন

এতক্ষণ simulator দেখেছেন; এবার সত্যিকারের socket. নিচের C প্রোগ্রাম loopback (127.0.0.1) port 2525-এ একটি listening socket খোলে, তারপর fork() করে: child process একটি ছোট SMTP-ধাঁচের সার্ভার হয়, parent হয় ক্লায়েন্ট। ক্লায়েন্ট পুরো কথোপকথন পাঠায় আর প্রতিটি লাইন ছাপে; সার্ভার নিজে কিছু ছাপে না, তাই আউটপুটের ক্রম সবসময় একই। (Socket প্রোগ্রামিংয়ের বিস্তারিত পর্ব ৪১-এ; সার্ভারটি ইচ্ছা করে অতি সরল — আসল MTA নয়।)

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>
#include <arpa/inet.h>
static void mx(int ls) {                  /* child process: a tiny SMTP-like server */
    int c = accept(ls, NULL, NULL), n = 0, data = 0; char l[256], last[256] = "";
    FILE *in = fdopen(c, "r"), *out = fdopen(dup(c), "w");
    setvbuf(out, NULL, _IOLBF, 0); fputs("220 mx.example.org toy ESMTP\r\n", out);
    while (fgets(l, sizeof l, in)) { l[strcspn(l, "\r\n")] = 0;     /* strip CRLF */
        if (data && strcmp(l, ".") != 0) { n++; strcpy(last, l[0] == '.' ? l + 1 : l); }
        else if (data) { data = 0; fprintf(out, "250 OK: %d lines, last: %s\r\n", n, last); }
        else if (!strncmp(l, "RCPT TO:<carol", 14)) fputs("550 5.1.1 no such user\r\n", out);
        else if (!strncmp(l, "DATA", 4)) { data = 1; fputs("354 end with <CRLF>.<CRLF>\r\n", out); }
        else if (!strncmp(l, "QUIT", 4)) { fputs("221 bye\r\n", out); break; }
        else fputs(strncmp(l, "EHLO", 4) ? "250 OK\r\n" : "250 mx.example.org\r\n", out);
    }
}
int main(void) {
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_port = htons(2525),
                             .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    int ls = socket(AF_INET, SOCK_STREAM, 0), s = socket(AF_INET, SOCK_STREAM, 0);
    if (bind(ls, (struct sockaddr *)&a, sizeof a) || listen(ls, 1)) { perror("bind"); return 1; }
    fflush(stdout); pid_t pid = fork(); if (pid == 0) { mx(ls); _exit(0); }   /* child = server */
    if (connect(s, (struct sockaddr *)&a, sizeof a)) { perror("connect"); return 1; }
    FILE *in = fdopen(s, "r"), *out = fdopen(dup(s), "w"); char r[256];
    const char *cmd[] = { "EHLO mail.example.com", "MAIL FROM:<alice@example.com>", "RCPT TO:<bob@example.org>",
        "RCPT TO:<carol@example.org>", "DATA", "Subject: hi", "", "..starts with a dot", ".", "QUIT", NULL };
    for (int i = -1; i < 0 || cmd[i]; i++) {     /* i = -1: only read the 220 greeting */
        if (i >= 0) { fprintf(out, "%s\r\n", cmd[i]); fflush(out); printf("C: %s\n", cmd[i]); }
        if ((i < 5 || i > 7) && fgets(r, sizeof r, in)) {   /* lines 5-7 are inside DATA: no reply */
            r[strcspn(r, "\r\n")] = 0; printf("S: %s\n", r); }
    }
    waitpid(pid, NULL, 0); return 0;
}

S: 220 mx.example.org toy ESMTP
C: EHLO mail.example.com
S: 250 mx.example.org
C: MAIL FROM:<alice@example.com>
S: 250 OK
C: RCPT TO:<bob@example.org>
S: 250 OK
C: RCPT TO:<carol@example.org>
S: 550 5.1.1 no such user
C: DATA
S: 354 end with <CRLF>.<CRLF>
C: Subject: hi
C: 
C: ..starts with a dot
C: .
S: 250 OK: 3 lines, last: .starts with a dot
C: QUIT
S: 221 bye

৭ · জাল প্রেরক ঠেকানো — SPF, DKIM আর DMARC

অংশ ৪-এ দেখেছেন, SMTP নিজে প্রেরকের পরিচয় যাচাই করে না। এর ফল phishing: ব্যাংক, মোবাইল ব্যাংকিং সেবা বা অফিসের IT বিভাগের নামে ভুয়া চিঠি, যাতে পাসওয়ার্ড বা OTP চাওয়া হয়। প্রতিরক্ষার তিনটি স্তর — তিনটিই DNS-এর TXT record-এ প্রকাশিত, আর প্রাপকের MX চিঠি গ্রহণের সময় যাচাই করে। এখানে আমরা শুধু প্রতিরক্ষার দিক দেখছি: নিজের ডোমেইন কীভাবে রক্ষা করবেন আর প্রাপক কীভাবে বিচার করে।

SPF — কোন IP আমার ডোমেইনের চিঠি পাঠাতে পারে

SPF (Sender Policy Framework, RFC 7208, ২০১৪) ডোমেইনের TXT record-এ অনুমোদিত প্রেরকের তালিকা রাখে:

example.com.       TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.example.com -all"
_spf.example.com.  TXT "v=spf1 ip4:198.51.100.0/25 -all"

• প্রাপক SPF যাচাই করে envelope-এর MAIL FROM-এর ডোমেইন দিয়ে (খালি হলে EHLO-র নাম দিয়ে) — From: header দিয়ে নয়। এটিই SPF-এর বড় সীমা।
• বাঁ থেকে ডানে প্রথম মিলে যাওয়া অংশই ফল দেয়। ip4:192.0.2.0/24 — 192.0.2.0 থেকে 192.0.2.255 (পর্ব ১৭-এর CIDR হিসাব)। include: মানে “ওই ডোমেইনের SPF-এ এই IP pass করলে মিল” — ভেতরের fail-এর মানে এখানে শুধু “মিলল না”, পুরো ফল fail নয়।
• শেষের -all = বাকি সবাই fail (কড়া); ~all = softfail (সন্দেহজনক, সাধারণত গ্রহণ করে চিহ্ন দেয়); ?all = neutral. +all মানে “সবাই অনুমোদিত” — কখনো ব্যবহার করবেন না।
• ১০-lookup সীমা: যেসব অংশে আরও DNS প্রশ্ন লাগে (include, a, mx, ptr, exists, redirect), সব মিলিয়ে ১০টির বেশি হলে ফল permerror — যেন কারও SPF দিয়ে অন্যের DNS-এ চাপ সৃষ্টি না করা যায়। অনেক বাইরের সেবা include করতে থাকলে এই সীমা সহজেই পেরোয়, তখন বৈধ চিঠিও ব্যর্থ হয়। একটি ডোমেইনে SPF record-ও একটিই থাকতে হবে।
• দুর্বলতা: চিঠি forward হলে (যেমন bob@example.org নিজের চিঠি অন্য ঠিকানায় পাঠান) নতুন সংযোগের IP forward-কারীর, মূল প্রেরকের নয় — SPF fail করে।

DKIM — চিঠির ওপর ডিজিটাল সই

DKIM (DomainKeys Identified Mail, RFC 6376, ২০১১) Yahoo-র DomainKeys আর Cisco-র একটি প্রস্তাব মিলিয়ে তৈরি। পাঠানো সার্ভার নিজের গোপন key দিয়ে বার্তার কিছু header আর body-র hash-এর ওপর একটি ডিজিটাল সই দেয়, আর সেটি একটি নতুন header-এ যোগ করে:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=sel2026;
    h=from:to:subject:date:message-id;
    bh=Wp3kq8...=;            ← body-র hash (base64)
    b=dK8sF2...=              ← সই (base64)

• d= — কোন ডোমেইন সই দিচ্ছে; s= — selector, একই ডোমেইনের একাধিক key আলাদা করতে।
• প্রাপক public key আনে DNS থেকে: sel2026._domainkey.example.com-এর TXT, যেমন "v=DKIM1; k=rsa; p=MIIBIjANBg…". সেই key দিয়ে সই যাচাই করে।
• কী সই হয়: h=-তে তালিকাভুক্ত header (From: বাধ্যতামূলক) আর body-র hash. c=relaxed মানে ফাঁকা জায়গা বা header-এর বড়-ছোট হাতের অক্ষরের সামান্য বদল সহ্য করা হবে। খাম (MAIL FROM, RCPT TO) সই হয় না।
• Forwarding-এ বার্তা না বদলালে DKIM টিকে থাকে — SPF-এর তুলনায় বড় সুবিধা। কিন্তু mailing list subject-এ “[তালিকা]” যোগ করলে বা নিচে footer বসালে সই ভাঙে।

Public key আর ডিজিটাল সইয়ের গণিত পর্ব ৪৭-এ, আর certificate ও TLS পর্ব ৪৮-এ। এখানে শুধু মনে রাখুন: গোপন key ছাড়া কেউ বৈধ সই বানাতে পারে না, কিন্তু DNS-এর public key দিয়ে যে কেউ যাচাই করতে পারে।

DMARC — নীতি আর alignment

SPF আর DKIM দুটিই কোনো একটি ডোমেইনকে “প্রমাণ” করে — কিন্তু সেটি পাঠকের দেখা From: ডোমেইন কি না, তা কেউ বলে না। প্রতারক নিজের ডোমেইন example.net-এর জন্য ঠিকঠাক SPF আর DKIM বানিয়ে From:-এ example.com লিখলে দুটিই pass! DMARC (RFC 7489, ২০১৫) এই ফাঁক বন্ধ করে। এটি _dmarc.example.com-এর TXT-এ থাকে:

_dmarc.example.com.  TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

• DMARC pass = (SPF pass এবং SPF-এর ডোমেইন From:-এর সাথে aligned) অথবা (DKIM pass এবং d= From:-এর সাথে aligned).
• Alignment: relaxed (r, ডিফল্ট) — একই organizational domain হলেই চলে (mail.example.com আর example.com মিলবে); strict (s) — হুবহু একই।
• নীতি p=: none (শুধু পর্যবেক্ষণ আর রিপোর্ট), quarantine (spam/junk-এ পাঠানো), reject (SMTP-তেই প্রত্যাখ্যান)। চূড়ান্ত সিদ্ধান্ত প্রাপকের; নীতি একটি অনুরোধ।
• রিপোর্ট: rua= ঠিকানায় প্রাপকেরা দিনে সাধারণত একবার XML aggregate report পাঠায় — কোন IP থেকে আপনার ডোমেইনের নামে কতগুলো চিঠি এল, কতগুলো pass/fail. এগুলো দেখেই প্রতিষ্ঠান বোঝে কোন বৈধ সেবা এখনো ঠিকমতো সাজানো নেই।

নিচের stepper-এ একটি “চতুর” জাল চিঠি: প্রতারক example.net ডোমেইনের মালিক, তার SPF আর DKIM দুটোই ঠিকঠাক, শুধু From:-এ লিখেছে example.com-এর নিরাপত্তা বিভাগের ঠিকানা।

এবার একসাথে ছয়টি চিঠি। নিচের কোড DNS record-গুলো ডেটা হিসেবে নেয়, SPF নিজে হিসাব করে (ip4 পরিসর, include, -all/~all), DKIM-এর ফল ইনপুট হিসেবে নেয়, তারপর DMARC alignment আর নীতি থেকে চূড়ান্ত সিদ্ধান্ত দেয়।

// A receiving MX checks SPF (envelope MAIL FROM domain), DKIM (given) and DMARC (header From: domain).
const TXT = {                                   // DNS TXT records, given as data (no real DNS)
  "example.com":        "v=spf1 ip4:192.0.2.0/24 include:_spf.example.com -all",
  "_spf.example.com":   "v=spf1 ip4:198.51.100.0/25 -all",
  "example.net":        "v=spf1 ip4:203.0.113.0/28 -all",
  "example.org":        "v=spf1 ip4:198.51.100.128/25 ~all",
  "_dmarc.example.com": "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com",
  "_dmarc.example.org": "v=DMARC1; p=quarantine" };
const ip2n = (ip) => ip.split(".").reduce((n, o) => n * 256 + +o, 0);
const inNet = (ip, c) => { const [net, len = 32] = c.split("/"), k = 2 ** (32 - len);
  return Math.floor(ip2n(ip) / k) === Math.floor(ip2n(net) / k); };
function spf(domain, ip) {                      // pass / fail / softfail / neutral / none
  const rec = TXT[domain]; if (!rec) return "none";
  for (const term of rec.split(" ").slice(1)) {
    const [mech, arg] = term.split(":");
    if (mech === "ip4" && inNet(ip, arg)) return "pass";
    if (mech === "include" && spf(arg, ip) === "pass") return "pass";  // only a pass there matches
    if (mech === "-all" || mech === "~all") return mech === "-all" ? "fail" : "softfail";
  } return "neutral";
}
const org = (d) => d.split(".").slice(-2).join(".");    // simplification of the Public Suffix List
const row = (...v) => v.map((x, i) => String(x).padEnd([16, 10, 9, 9, 7, 11][i])).join("");
const msgs = [ // label, connecting IP, envelope MAIL FROM domain, header From: domain, DKIM result d=
  ["1 own server", "192.0.2.25", "example.com", "example.com", "pass example.com"],
  ["2 via include", "198.51.100.20", "example.com", "example.com", "none"],
  ["3 crude spoof", "203.0.113.99", "example.com", "example.com", "none"],
  ["4 clever spoof", "203.0.113.5", "example.net", "example.com", "pass example.net"],
  ["5 forwarded", "203.0.113.77", "example.com", "example.com", "pass example.com"],
  ["6 org softfail", "192.0.2.99", "example.org", "example.org", "none"] ];
console.log(row("message", "SPF", "SPF-al", "DKIM-al", "DMARC", "policy") + "-> action");
for (const [label, ip, mfrom, from, dkim] of msgs) {
  const s = spf(mfrom, ip), [dres, dd = ""] = dkim.split(" "), rec = TXT["_dmarc." + org(from)];
  const sAl = s === "pass" && org(mfrom) === org(from), dAl = dres === "pass" && org(dd) === org(from);
  const p = rec ? rec.match(/p=(\w+)/)[1] : "(none)", ok = sAl || dAl;
  console.log(row(label, s, sAl, dAl, ok ? "pass" : "fail", p) + "-> " + (ok || p === "none" || !rec ? "deliver" : p)); }

message         SPF       SPF-al   DKIM-al  DMARC  policy     -> action
1 own server    pass      true     true     pass   reject     -> deliver
2 via include   pass      true     false    pass   reject     -> deliver
3 crude spoof   fail      false    false    fail   reject     -> reject
4 clever spoof  pass      false    false    fail   reject     -> reject
5 forwarded     fail      false    true     pass   reject     -> deliver
6 org softfail  softfail  false    false    fail   quarantine -> quarantine

৮ · পথের নিরাপত্তা, end-to-end, spam আর বড় প্রেরকদের নিয়ম

ARC — forward আর mailing list-এর সমস্যা

Mailing list চিঠি বদলালে DKIM আর SPF দুটিই ভাঙতে পারে। ARC (Authenticated Received Chain, RFC 8617, ২০১৯, experimental) এর একটি আংশিক উত্তর: প্রতিটি মধ্যবর্তী সার্ভার নিজের দেখা যাচাইয়ের ফল (“আমি পেয়েছিলাম তখন DKIM pass ছিল”) নিজের সই দিয়ে যোগ করে। মধ্যবর্তীকে বিশ্বাস করবে কি না, তা শেষ প্রাপকের সিদ্ধান্ত।

STARTTLS-এর দুর্বলতা, MTA-STS আর DANE

Port 25-এ STARTTLS ঐচ্ছিক (opportunistic): সার্ভার EHLO-র উত্তরে STARTTLS ঘোষণা করলে ক্লায়েন্ট এনক্রিপশনে যায়, না করলে সাধারণ লেখায় পাঠায়। যেহেতু ঘোষণাটি নিজেই এনক্রিপ্ট-হীন, পথের একজন আক্রমণকারী (MITM) “250 STARTTLS” লাইনটি মুছে দিলে দুই সার্ভার কিছু টের না পেয়েই খোলা লেখায় কথা বলে — এটি downgrade-এর ঝুঁকি। আর certificate যাচাই না করলে নকল সার্ভারও TLS দিতে পারে। দুটি প্রতিরক্ষা:

• MTA-STS (RFC 8461, ২০১৮): ডোমেইন HTTPS-এ একটি নীতি-ফাইল প্রকাশ করে — “আমার MX এগুলো, আর এদের সাথে বৈধ certificate-সহ TLS ছাড়া পাঠাবেন না”। প্রেরক নীতিটি কিছুদিন মনে রাখে। সাথে TLS-RPT (RFC 8460) দিয়ে TLS ব্যর্থতার রিপোর্ট আসে।
• DANE (SMTP-র জন্য RFC 7672): MX-এর certificate-এর ছাপ DNS-এর TLSA record-এ থাকে, আর DNSSEC দিয়ে তা স্বাক্ষরিত — প্রেরক DNS থেকেই জানে কোন certificate আশা করবে। শর্ত: ডোমেইনে DNSSEC চালু থাকতে হবে।

End-to-end encryption — PGP আর S/MIME

STARTTLS শুধু পথ ঢাকে; প্রতিটি সার্ভারে আর mailbox-এ চিঠি সরবরাহকারীর কাছে খোলা থাকে। প্রেরক থেকে প্রাপক পর্যন্ত গোপন রাখতে body-ই এনক্রিপ্ট করতে হয়: PGP (মান OpenPGP) বা S/MIME (certificate-ভিত্তিক)। দুটিতেই প্রাপকের public key আগে জানতে হয়, আর header (Subject, প্রাপক) সাধারণত খোলা থাকে — বিস্তারিত ভাবনার প্রশ্ন ০৪-এ।

Spam filter — সংক্ষেপে

প্রাপকের MX কয়েক স্তরে বিচার করে: সংযোগের IP আর ডোমেইনের সুনাম (অতীতের spam, নিষিদ্ধ তালিকা, reverse DNS), SPF/DKIM/DMARC-এর ফল, SMTP আচরণ (greylisting-এ আবার চেষ্টা করে কি না), আর বিষয়বস্তু — লিংক, সংযুক্তির ধরন, আর ব্যবহারকারীদের “Spam” বোতাম থেকে শেখা মডেল। কোনো একক পরীক্ষা চূড়ান্ত নয়; নম্বর জমে, সীমা পেরোলে junk বা প্রত্যাখ্যান।

বড় প্রেরকদের নতুন নিয়ম (২০২৪ থেকে)

Google আর Yahoo ২০২৩ সালের শেষে ঘোষণা দেয়, আর ২০২৪ সালের শুরু থেকে প্রয়োগ শুরু করে: যারা দিনে প্রায় ৫,০০০-এর বেশি চিঠি তাদের ব্যবহারকারীদের পাঠায়, তাদের SPF আর DKIM দুটোই থাকতে হবে, অন্তত p=none-এর DMARC থাকতে হবে আর From: ডোমেইন aligned হতে হবে, বিপণনের চিঠিতে এক-ক্লিকে unsubscribe (RFC 8058) থাকতে হবে, আর ব্যবহারকারীর spam-রিপোর্টের হার খুব কম (প্রায় ০.৩%-এর নিচে) রাখতে হবে। পরে Microsoft-ও নিজের ভোক্তা মেইলের জন্য অনুরূপ শর্ত ঘোষণা করে। সীমা আর শর্তের খুঁটিনাটি সময়ের সাথে বদলায় — নিজের প্রতিষ্ঠানের জন্য প্রতিটি সরবরাহকারীর বর্তমান নির্দেশিকা দেখে নিন।

৯ · AI-এর যুগে ইমেইল — DNS record লেখানো আর যাচাই করা

“আমার ডোমেইনের জন্য SPF, DKIM, DMARC বানিয়ে দিন” — AI কয়েক সেকেন্ডে record লিখে দেয়। কিন্তু আপনার প্রতিষ্ঠান কোন কোন সেবা দিয়ে চিঠি পাঠায় (অফিসের মেইল, বিল পাঠানোর সফটওয়্যার, নিউজলেটার), তা AI জানে না। একটি ভুল record-এ নিজের বৈধ চিঠি junk-এ যায়, আর একটি ঢিলা record-এ প্রতারক আপনার নাম ব্যবহার করে। চেনা ভুলগুলো:

AI-এর ইমেইল-পরামর্শ চালুর আগে — চেকলিস্ট

• প্রতিষ্ঠানের সব চিঠি-পাঠানো সেবার তালিকা নিজে বানিয়েছি; AI-এর record সেই তালিকার সাথে মিলিয়েছি
• SPF-এ একটিমাত্র record, lookup ১০-এর কম, শেষে ~all বা -all — কখনো +all নয়
• CIDR পরিসর (যেমন /28 = ১৬টি ঠিকানা) ক্যালকুলেটরে আবার হিসাব করেছি
• পরীক্ষামূলক চিঠি পাঠিয়ে প্রাপকের দিকের Authentication-Results: header-এ spf, dkim, dmarc pass দেখেছি
• DMARC p=none দিয়ে শুরু করে রিপোর্ট পড়েছি; সার্ভার কনফিগ শুধু নিজের ল্যাব বা VM-এ আগে পরীক্ষা করেছি, open relay নেই নিশ্চিত হয়েছি