
read receipts
যে ইমেইল আপনি নিজেকে ফরওয়ার্ড করলেন তা স্প্যামে চলে গেল কেন
আপনি কোনো ভুল করেননি। SPF করেছে। এখানে সেই মেকানিক্স আছে যা আপনার প্রদানকারী কেউই ব্যাখ্যা করবে না।
আপনার পুরনো অ্যাকাউন্ট থেকে নতুন একটিতে অটো-ফরওয়ার্ড সেট করুন, এবং সেই মেইলের কিছু চুপচাপ স্প্যামে হারিয়ে যাবে — শুধুমাত্র এই কারণে নয় যে আপনার প্রদানকারী ভাঙা, বরং কারণ ফরওয়ার্ডিং বার্তাটি পাঠানোর পক্ষ পরিবর্তন করে কিন্তু ক্রিপ্টোগ্রাফিক প্রমাণ পরিবর্তন করে না। SPF ভুল সার্ভার চেক করে, DMARC ভার্ডিক্ট ফেইলে পরিণত হয়, এবং আপনি নিজেকে পাঠানো একটি বৈধ ইমেইল কোয়ারেন্টাইন হয়ে যায়। সমাধানের একটি নাম আছে: ARC, যা 2019 সালে RFC 8617 এ সংজ্ঞায়িত হয়েছিল।
ফরওয়ার্ডিং কেন আমার মেইল SPF ফেইল করায়?
কারণ SPF শেষ সার্ভার চেক করে যা বার্তাটি রিলে করেছে, এবং ফরওয়ার্ডিং সেই সার্ভার পরিবর্তন করে। SPF — Sender Policy Framework — একটি DNS রেকর্ড যা তালিকাভুক্ত করে কোন IP অ্যাড্রেসগুলি একটি ডোমেইনের জন্য মেইল পাঠাতে অনুমোদিত। যখন bank.com আপনাকে একটি রসিদ পাঠায়, গ্রহণকারী সার্ভার চেক করে: এটি কি bank.com অনুমোদিত একটি IP থেকে এসেছে? হ্যাঁ। পাস।
এখন সেই রসিদটি আপনার Gmail থেকে আপনার নতুন অ্যাড্রেসে ফরওয়ার্ড করুন। Google এর সার্ভারগুলি এটি এগিয়ে রিলে করে। চূড়ান্ত গ্রহণকারী সার্ভার SPF চেক চালায় এবং প্রশ্ন করে: Google কি bank.com এর জন্য পাঠাতে অনুমোদিত? না, এটি নয়। SPF ফেইল। Google এর নিজস্ব Workspace ডকুমেন্টেশন এটি স্পষ্টভাবে বলে — ফরওয়ার্ড করা বার্তাগুলি SPF ফেইল করে কারণ ফরওয়ার্ডিং সার্ভার মূল ডোমেইনের SPF রেকর্ডে নেই। কোনো স্পুফিং হয়নি। চেকটি শুধু ভুল হপ দেখছে।
তাহলে এটি স্প্যামে কেন পাঠায়?
DMARC। একা SPF ফেইল করা আগে সহনীয় ছিল; DMARC এটিকে একটি ভার্ডিক্টে পরিণত করেছে। DMARC SPF এবং DKIM একসাথে বাঁধে এবং রিসিভারদের বলে যখন উভয়ই ফেইল হয় তখন কী করতে হবে: কিছু না, কোয়ারেন্টাইন, বা প্রত্যাখ্যান। 2024 সালের মধ্যে, বড় সেন্ডারদের কোনো পছন্দ ছিল না — Google এবং Yahoo তাদের ব্যবহারকারীদের কাছে প্রতিদিন 5,000 এরও বেশি বার্তা পাঠানোর ক্ষেত্রে যে কাউকে DMARC প্রয়োজন করতে শুরু করেছিল।
DKIM, অন্যান্য স্তম্ভ, বার্তার মধ্যে বেক করা একটি স্বাক্ষর। তত্ত্বে এটি ফরওয়ার্ডিং সহ্য করে, কারণ এটি বিষয়বস্তুতে স্বাক্ষর করে, রুটে না। অনুশীলনে, যা কিছু বার্তা স্পর্শ করে তা এটি ভাঙে। একটি মেইলিং লিস্ট যা একটি "আপনি সাবস্ক্রাইব করছেন, এখানে আনসাবস্ক্রাইব করুন" পাদটীকা যোগ করে, একটি সার্ভার যা বিষয় লাইন পুনর্লিখন করে, এমনকি একটি লাইন কীভাবে মোড়ানো হয় তাতে পরিবর্তন — স্বাক্ষর আর মেলে না, এবং DKIM ও ফেইল করে। এখন উভয় স্তম্ভ নিচে, DMARC ফেইল বলে, এবং আপনার নিজের রসিদ জাঙ্ক ফোল্ডারে আছে।
ARC কী এবং এটি কি আসলে এটি ঠিক করে?
ARC — Authenticated Received Chain, RFC 8617 — একজন সৎ ফরওয়ার্ডারকে যাচাই করতে দেয় যে মেইল এটি স্পর্শ করার আগে প্রমাণীকরণ পাস করেছে। ফরওয়ার্ডিং সার্ভার বার্তাটিতে একটি সিলড রেকর্ড স্ট্যাম্প করে যা বলে "যখন এটি আমার কাছে পৌঁছেছিল, SPF এবং DKIM বৈধ ছিল — আমি যে লেগের জন্য যাচাই করতে পারি না তার জন্য আমার কথায় বিশ্বাস করুন।" চূড়ান্ত রিসিভার, যদি এটি সেই ফরওয়ার্ডারকে বিশ্বাস করে, তাহলে DMARC ফেইল ওভাররাইড করে এবং ডেলিভার করতে পারে।
ধরা পড়া হল "যদি এটি বিশ্বাস করে"। ARC একটি পাসওয়ার্ড নয়; এটি একটি খ্যাতি সিস্টেম। একটি রিসিভার ওজন করে ARC সিলার একটি পরিচিত, সুপরিচালিত অপারেটর কিনা। Google উভয়ই ARC হেডার স্ট্যাম্প করে এবং তাদের থেকে মেনে চলে যা বিশ্বাস করে, এই কারণেই একটি Gmail-থেকে-Gmail ফরওয়ার্ড সাধারণত বেঁচে থাকে যখন কিছু পুরনো বিশ্ববিদ্যালয় রিলে মাধ্যমে একটি ফরওয়ার্ড তা করে না।
যদি আপনি নিজে ফরওয়ার্ডিং চালান, দুটি কংক্রিট পদক্ষেপ সাহায্য করে। Server-Side Redirect / SRS-স্টাইল পুনর্লিখন ব্যবহার করুন যদি আপনার হোস্ট এটি অফার করে, যা এনভেলপ সেন্ডার পুনর্লিখন করে তাই SPF আপনার ফরওয়ার্ডারের বিপরীতে মূল ডোমেইনের পরিবর্তে চেক করে। এবং এমন প্রদানকারীদের মধ্যে ফরওয়ার্ড করার পছন্দ করুন যা উভয়ই ARC সমর্থন করে। যদি আপনি অ্যাকাউন্টগুলি একত্রিত করছেন এবং গন্তব্যকে শুধু প্রমাণীকরণ বিশৃঙ্খলা পরিচালনা করতে চান, যা এক্স অ্যাক্টলি AI email platform শোষণ করার জন্য নির্মিত।
আমি কখন আমার প্রদানকারীকে দোষ দেওয়া বন্ধ করব?
যখন প্যাটার্ন হল "শুধুমাত্র ফরওয়ার্ড করা মেইল ফেইল হয়," প্রদানকারী সঠিকভাবে তার কাজ করছে — প্রোটোকল সমস্যা। এখানে বলার বিষয়: অনুপস্থিত বার্তার হেডার খুলুন এবং Authentication-Results লাইন দেখুন। যদি আপনি spf=fail দেখেন একটি পাঠানো IP এর পাশে যা একটি মূল প্রেরকের পরিবর্তে একটি ফরওয়ার্ডারের অন্তর্গত, এটি SPF ভুল হপ চেক করছে। যদি dkim=fail এমন মেইলে দেখা যায় যা একটি তালিকা বা এমন রিলে যা বার্তা সম্পাদনা করে, এটি একটি জাল স্বাক্ষর নয়, একটি বিকৃত স্বাক্ষর।
অস্বস্তিকর সত্য হল যে ইমেইল প্রমাণীকরণ বলা হয়েছিল, স্তর দ্বারা স্তর, দুই দশক জুড়ে একটি সিস্টেমে যা কখনও অনুমান করেনি যে কেউ মিথ্যা বলবে। SPF 2006 এ এসেছিল, DKIM 2007 এ, DMARC 2015 এ, ARC 2019 এ — প্রতিটি শেষটি খোলা একটি গর্তে প্যাচ করছে। ফরওয়ার্ডিং সেই সিলাই যেখানে সমস্ত চারটি একে অপরের বিপরীতে ঘষে, এবং আপনার ইনবক্স যেখানে আপনি ঘর্ষণ অনুভব করেন।
@@BODY_END@@সূত্র
- IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
- Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
- Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold