সিলেক্টর দিয়ে একটি DKIM কী খুঁজুন এবং এর ধরন, আসল দৈর্ঘ্য ও যেকোনো সমস্যা দেখুন
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.একটি DKIM চেকার কোনো ডোমেইনের selector._domainkey.domain-এ প্রকাশ করা পাবলিক কী এনে পড়ে। RFC 8301 অন্তত 1024 বিটের RSA কী বাধ্যতামূলক করে এবং 2048 সুপারিশ করে; খালি p= মানে কী-টি বাতিল করা হয়েছে। সিলেক্টর আসে একটি সাইন করা বার্তার s= ট্যাগ থেকে।
এই পৃষ্ঠাটি ইংরেজি মূল লেখা থেকে যন্ত্রের সাহায্যে অনুবাদ করা হয়েছে। এই অনুবাদটি এখনও কোনো মানুষ পর্যালোচনা করেননি, তাই ইংরেজি সংস্করণটিকেই নির্ভরযোগ্য ধরুন। ইংরেজি মূল লেখাটি পড়ুন
ডোমেইন ঘরে ডোমেইন এবং সিলেক্টর (স্বাক্ষরে s=) ঘরে সিলেক্টর লিখুন।
selector._domainkey.domain থেকে কী আনতে DKIM পরীক্ষা করুন চাপুন।
কী থেকেই হিসাব করা কী-এর ধরন ও কী-এর দৈর্ঘ্য পড়ুন, ওপরে সমস্যাগুলোর তালিকাসহ।
কী রেকর্ডটি রাখতে এর পাশে কপি চাপুন।
একটি ডোমেইন ও একটি সিলেক্টর লিখুন, পেজটি একটি পাবলিক DNS-over-HTTPS রিজলভারের কাছে সিলেক্টর, তারপর ._domainkey., তারপর ডোমেইন দিয়ে গঠিত নামের TXT রেকর্ড চায়। রেকর্ডের ট্যাগগুলো RFC 6376-এর 3.6.1 অনুচ্ছেদের সংজ্ঞা অনুযায়ী পড়া হয়: ভার্সন, কী-এর ধরন, অনুমোদিত হ্যাশ অ্যালগরিদম, সেবার ধরন, ফ্ল্যাগ এবং কী নিজে।
কী-এর দৈর্ঘ্য কী থেকেই হিসাব করা হয়, টেক্সট কত লম্বা তা দেখে অনুমান করা হয় না। p=-এর base64 ডিকোড করে ভেতরের DER কাঠামো RSA মডুলাস পর্যন্ত পড়া হয়, যার সঠিক বিট দৈর্ঘ্যই কী-এর আকার। RFC 8463-এ সংজ্ঞায়িত ed25519 কী সবসময় 256 বিট। RFC 8301-এর 3.2 অনুচ্ছেদ বলে প্রাপকদের 1024 বিটের কম RSA কী প্রত্যাখ্যান করতে হবে এবং প্রেরকদের 2048 ব্যবহার করা উচিত, আর ফলাফল জানায় কী-টি এই সীমার কোন পাশে পড়ে।
অন্য সমস্যাগুলো সহজ ভাষায় জানানো হয়: খালি p=, যার মানে কী বাতিল হয়েছে; t=y, যা ডোমেইনকে এখনো পরীক্ষাধীন চিহ্নিত করে, ফলে প্রাপকরা এর সাইন করা মেইলকে সাইনহীন হিসেবে গণ্য করে; এমন h= যা শুধু sha1 অনুমোদন করে, যা RFC 8301 বাতিল করেছে; এবং এমন রেকর্ড যা আদৌ DKIM নয়। কোনো সিলেক্টর CNAME দিয়ে অন্য কোথাও নির্দেশ করলে, যেমন অনেক মেইল সেবা করে, তা অনুসরণ করা হয় এবং লক্ষ্য দেখানো হয়।
সিলেক্টর খুঁজে পাওয়াই কঠিন অংশ। এটি ডোমেইনের পাঠানো কোনো বার্তার DKIM-Signature হেডারের s= মান, এবং এটি জানার একমাত্র নিশ্চিত উপায় এটাই। "Try common selectors" বোতাম বড় প্রোভাইডার ও হোস্টিং প্যানেলের ব্যবহৃত নয়টি নাম খোঁজে। মিল পেলে প্রমাণ হয় যে একটি কী আছে; না পেলে কিছুই প্রমাণ হয় না, কারণ সিলেক্টরের নাম যেকোনো কিছু হতে পারে।
যা এটি করে না: এটি কোনো বার্তার স্বাক্ষর যাচাই করে না। তার জন্য বার্তাটি লাগে।
আপনি যে ডোমেইন ও সিলেক্টর লেখেন তা আপনার বেছে নেওয়া রিজলভারে পাঠানো হয়, কারণ খোঁজার জন্য এগুলো দরকার। আর কিছুই আপনার ডিভাইস ছেড়ে যায় না।
ডোমেইনের পাঠানো একটি বার্তা খুলুন, মূল বা র সোর্স দেখুন, এবং DKIM-Signature হেডার খুঁজুন। এর s= ট্যাগ হলো সিলেক্টর এবং d= ট্যাগ হলো ডোমেইন। সাধারণ সিলেক্টর অনুমান করা যায়, এবং এখানকার বোতাম নয়টি চেষ্টা করে, কিন্তু নিশ্চিতভাবে জানায় শুধু হেডার।
RFC 8301 অন্তত 1024 বিটের RSA কী বাধ্যতামূলক করে এবং 2048 সুপারিশ করে। প্রাপকদের 1024 বিটের কম কী প্রত্যাখ্যান করতে হয়, তাই সেগুলো দিয়ে করা স্বাক্ষর ব্যর্থ হয়। 4096 বিটের বেশি কী সব প্রাপক যাচাই না-ও করতে পারে। ed25519 কী 256 বিট এবং সাধারণত RSA কী-এর পাশাপাশি প্রকাশ করা হয়।
খালি p= ট্যাগ মানে ওই সিলেক্টরের কী ইচ্ছাকৃতভাবে বাতিল করা হয়েছে। এটি দিয়ে সাইন করা মেইল এখন DKIM-এ ব্যর্থ হয়। নতুন সিলেক্টরে যাওয়ার সময় প্রোভাইডাররা একটি বাতিল রেকর্ড প্রকাশ করে, তাই বর্তমান মেইল নতুনটি ব্যবহার করলে পুরোনো সিলেক্টরে খালি p= থাকা স্বাভাবিক।
সাধারণত সিলেক্টর ভুল: প্রতিটি পাঠানোর সেবা নিজস্ব সিলেক্টর ব্যবহার করে, আর নামটি মুক্ত টেক্সট। কী হয়তো এখনো প্রকাশিত হয়নি, অথবা সেবাটি নিজের কী-এর দিকে নির্দেশ করা একটি CNAME রেকর্ড আশা করে। আগে একটি আসল বার্তার হেডারে s= মান দেখে নিন।
ডোমেইন ও সিলেক্টর আপনার বেছে নেওয়া পাবলিক DNS রিজলভারে যায়, Cloudflare বা Google, কারণ রেকর্ড খুঁজতে নামটি দরকার। রিজলভার জিজ্ঞেস করা নামগুলো ও আপনার IP ঠিকানা দেখে। আর কিছুই আপনার ডিভাইস ছেড়ে যায় না, এবং এই সাইটে পরীক্ষা নিয়ে কিছুই সংরক্ষিত হয় না।
এখনও আটকে আছেন? DKIM চেকার সম্পর্কে প্রশ্ন করুন আর যিনি জানেন তিনিই উত্তর দিতে পারেন। কোনো অ্যাকাউন্ট লাগবে না।