প্রযুক্তি · মানদণ্ড
মানদণ্ড মেনে চলি।ঘাটতি খোলাখুলি জানাই।
FOLD যত প্রোটোকলে কথা বলে, তার প্রতিটি কোনো না কোনো RFC-তে সংজ্ঞায়িত। এই পাতায় আছে সেগুলো, যা দিয়ে একটি মেইল ক্লায়েন্টকে মাপা হয়, আর প্রতিটির ক্ষেত্রে কোড আজ কী করে: বাস্তবায়িত, আংশিক বাস্তবায়িত, বাকি, নাকি ইচ্ছাকৃতভাবে বাদ দেওয়া, এবং কেন।
2026-09-23 তারিখে কোডের সঙ্গে মিলিয়ে যাচাই করা
- বাস্তবায়িত
- 58
- বাস্তবায়িত এবং ব্যবহৃত হচ্ছে।
- আংশিক
- 8
- এর একটি অংশ কাজ করে; কোন অংশ, তা নোটে বলা আছে।
- বাকি
- 10
- এখনো বাস্তবায়িত হয়নি।
- ইচ্ছাকৃতভাবে বাদ
- 6
- ইচ্ছাকৃতভাবে বাস্তবায়ন করা হয়নি; কারণ নোটে দেওয়া আছে।
বার্তার ফরম্যাট
একটি বার্তা কীভাবে গঠিত হয়, পড়া হয় ও দেখানো হয়।
| RFC | মানদণ্ড | অবস্থা | FOLD-এ |
|---|---|---|---|
| RFC 5322 | Internet Message Format | বাস্তবায়িত | লেখার সময় কঠোর; পড়ার সময় CR-বিহীন একক লাইন ফিড, 8-বিট হেডার ও তারিখের নানা রূপ মেনে নেয়। |
| RFC 2045-2049 | MIME | বাস্তবায়িত | FOLD পুরো বার্তা ডাউনলোড করে এবং ডিভাইসেই MIME ট্রি তৈরি করে। |
| RFC 2047 | MIME Encoded-Words | বাস্তবায়িত | হেডারে ASCII-বহির্ভূত টেক্সট, ডিকোড ও এনকোড দুটোই। |
| RFC 2231 | MIME Parameter Value and Encoded Word Extensions | আংশিক | দীর্ঘ ও ASCII-বহির্ভূত ফাইলনাম পড়া হয়; পাঠানোর সময় FOLD এখনো এগুলো এই রূপে লেখে না। |
| RFC 2183 | Content-Disposition | বাস্তবায়িত | ইনলাইন নাকি সংযুক্তি, এবং ফাইলনাম। |
| RFC 2387 | multipart/related | বাস্তবায়িত | এমবেড করা ছবিসহ বার্তা, পড়া ও লেখা দুটোই। |
| RFC 2392 | Content-ID and Message-ID URLs | বাস্তবায়িত | cid: লিংক বার্তার ভেতরের এমবেড করা ছবিতে গিয়ে পৌঁছায়। |
| RFC 6532 | Internationalized Email Headers | বাস্তবায়িত | UTF-8 হেডার সবসময় পড়া হয়; FOLD সেগুলো লেখে কেবল আন্তর্জাতিক ঠিকানার জন্য, এবং কেবল তখনই, যখন সার্ভার SMTPUTF8 বা UTF8=ACCEPT সমর্থনের কথা জানায়।2026-09-21 থেকে |
| RFC 3676 | The Text/Plain Format and DelSp Parameters | বাকি | format=flowed টেক্সট এখনো নতুন করে লাইনে সাজানো (reflow) হয় না, আর FOLD তা পাঠায়ও না। |
| RFC 2369 | List Commands in Header Fields | বাস্তবায়িত | List-Unsubscribe একটি অ্যাকশন হিসেবে: মেইলের মাধ্যমে অনুরোধ FOLD নিজেই পাঠায়, ওয়েব লিংক ব্রাউজারে খোলে। |
| RFC 2919 | List-Id | বাস্তবায়িত | মেইলিং লিস্ট শনাক্ত করে, যাতে সেগুলোর সাধারণ স্বাক্ষর-ভাঙন জালিয়াতি হিসেবে না দেখায়। |
| RFC 8058 | One-Click Unsubscribe | বাকি | হেডারটি শনাক্ত করা হয়, কিন্তু FOLD এক-ক্লিকের অনুরোধ পাঠায় না; আনসাবস্ক্রাইব হয় মেইল বা ওয়েব পাতার মাধ্যমে। |
| RFC 8098 | Message Disposition Notification | আংশিক | পাঠানোর সময় FOLD পঠন রসিদ চাইতে পারে, কিন্তু নিজে ইচ্ছাকৃতভাবে কখনো পাঠায় না। |
পড়া ও সিঙ্ক (IMAP)
FOLD সার্ভারকে জিজ্ঞেস করে সে কী কী সমর্থন করে, সাইন-ইনের পর আবার জিজ্ঞেস করে, এবং প্রতিটি এক্সটেনশন কেবল তখনই চালু করে, যখন সার্ভার তা ঘোষণা করে; না করলে সহজতর পথে ফিরে যায়।
| RFC | মানদণ্ড | অবস্থা | FOLD-এ |
|---|---|---|---|
| RFC 3501 | IMAP4rev1 | বাস্তবায়িত | প্রতিটি সার্ভার যে ভিত্তি সমর্থন করে, STARTTLS সহ, এনক্রিপশনহীন সংযোগে ফিরে যাওয়ার কোনো পথ ছাড়াই। |
| RFC 9051 | IMAP4rev2 | ইচ্ছাকৃতভাবে বাদ | শনাক্ত করা হয়, চালু করা হয় না: লক্ষ্যগোষ্ঠীর কোনো সার্ভার এটি চায় না; FOLD তার বদলে rev1-এর এক্সটেনশন ব্যবহার করে। |
| RFC 2177 | IDLE | বাস্তবায়িত | FOLD প্রতিটি অ্যাকাউন্টের ইনবক্সে IDLE চালু রাখে এবং প্রতি 25 মিনিটে তা নবায়ন করে; অন্য ফোল্ডারে নির্দিষ্ট বিরতিতে খোঁজ নেওয়া হয়, iPhone ও iPad-এ কেবল অ্যাপ খোলা থাকা অবস্থায়। |
| RFC 4315 | UIDPLUS | বাস্তবায়িত | UID EXPUNGE, যাতে FOLD কেবল নিজের বার্তাগুলোই সরায়। |
| RFC 6851 | MOVE | বাস্তবায়িত | বিকল্প হিসেবে COPY ও EXPUNGE সহ; একটি MOVE-এর পর FOLD যাচাই করে উৎস ফোল্ডারে কী থেকে গেছে। |
| RFC 7162 | CONDSTORE and QRESYNC | বাস্তবায়িত | VANISHED (EARLIER) সহ ডেল্টা সিঙ্ক। |
| RFC 5161 | ENABLE | বাস্তবায়িত | সার্ভার ENABLED দিয়ে নিশ্চিত করার পরই কোনো সুইচ কার্যকর বলে ধরা হয়। |
| RFC 6154 | SPECIAL-USE | বাস্তবায়িত | ফোল্ডারের ভূমিকা আসে সার্ভারের চিহ্ন থেকে, প্রচলিত নাম কেবল বিকল্প হিসেবে কাজ করে, আর অনুপস্থিত ফোল্ডার তাদের ভূমিকাসহ তৈরি করা হয়। |
| RFC 9208 | QUOTA | বাস্তবায়িত | মেইলবক্সের ব্যবহৃত জায়গা Mac-এ দেখানো হয়। |
| RFC 7888 | LITERAL+ and LITERAL- | বাস্তবায়িত | আপলোডের সময় কম রাউন্ড ট্রিপ। |
| RFC 4959 | SASL-IR | বাস্তবায়িত | এক রাউন্ড ট্রিপে সাইন-ইন। |
| RFC 5530 | IMAP Response Codes | বাস্তবায়িত | ভুল পাসওয়ার্ড আর সাময়িকভাবে অনুপলব্ধ সার্ভারকে আলাদা করে চেনা যায়। |
| RFC 4731 | ESEARCH | বাস্তবায়িত | iPhone ও iPad-এ সার্ভার-অনুসন্ধানের জন্য সংক্ষিপ্ত ফলাফল; ESEARCH-বিহীন সার্ভার পায় প্রচলিত SEARCH।2026-09-21 থেকে |
| RFC 5258 | LIST-EXTENDED | বাস্তবায়িত | এক কমান্ডেই ফোল্ডার ও তাদের ভূমিকা।2026-09-21 থেকে |
| RFC 5819 | LIST-STATUS | বাস্তবায়িত | একই LIST-এ ফোল্ডারের কাউন্টার, প্রতিটি ফোল্ডার আলাদাভাবে সিলেক্ট না করেই।2026-09-21 থেকে |
| RFC 6855 | UTF8=ACCEPT | বাস্তবায়িত | UTF-8 ফোল্ডারের নাম ও হেডার; ফোল্ডার-নামের এনকোডিং এক জায়গাতেই বদলানো হয়।2026-09-21 থেকে |
| RFC 2342 | NAMESPACE | বাকি | সক্ষমতাটি শনাক্ত করা হয়, কিন্তু কমান্ডটি কখনো পাঠানো হয় না। |
| RFC 2971 | ID | বাকি | কিছু Yahoo সার্ভার সাইন-ইনের আগে এটি চায়। |
| RFC 4978 | COMPRESS=DEFLATE | বাকি | স্থগিত: এর জন্য একটি আংশিক ফ্লাশ (partial flush) দরকার, যা Apple-এর Compression ফ্রেমওয়ার্কে নেই; সরাসরি zlib ব্যবহারই পরিকল্পিত পথ। |
| RFC 8474 | OBJECTID | বাকি | নাম বদলালেও স্থির থাকা আইডি; এখনো ব্যবহার করা হয় না। |
| RFC 8970 | PREVIEW | বাকি | প্রিভিউ ডিভাইসেই লোড করা বার্তা থেকে তৈরি হয়। |
| RFC 8508 | REPLACE | বাকি | লেখার সময় খসড়া ডিভাইসে সংরক্ষিত হয় এবং লেখার উইন্ডো বন্ধ হলে একবার আপলোড হয়; সার্ভারে থাকা আগের কপি প্রতিস্থাপিত হয় না। |
| RFC 3516 | BINARY | ইচ্ছাকৃতভাবে বাদ | দরকার নেই: FOLD নিজেই MIME ট্রি ডিকোড করে। |
| RFC 5256 | SORT and THREAD | ইচ্ছাকৃতভাবে বাদ | FOLD References ও In-Reply-To থেকে স্থানীয়ভাবে কথোপকথন তৈরি করে, সব সার্ভারে একইভাবে। |
| RFC 5465 | NOTIFY | ইচ্ছাকৃতভাবে বাদ | লক্ষ্যগোষ্ঠীর প্রায় কোনো সার্ভারই এটি দেয় না। |
পাঠানো (SMTP)
FOLD কীভাবে আপনার সার্ভারের হাতে একটি বার্তা তুলে দেয়।
| RFC | মানদণ্ড | অবস্থা | FOLD-এ |
|---|---|---|---|
| RFC 5321 | Simple Mail Transfer Protocol | বাস্তবায়িত | সঠিক dot-stuffing সহ। |
| RFC 6409 | Message Submission for Mail | বাস্তবায়িত | পাঠানোর আগে সবসময় সাইন-ইন, পোর্ট 587 বা 465-এ। |
| RFC 4954 | SMTP Service Extension for Authentication | বাস্তবায়িত | initial response সহ সাইন-ইন, আর কোনো পদ্ধতি ব্যর্থ হলে পরিচ্ছন্নভাবে বাতিল। |
| RFC 1870 | SIZE | বাস্তবায়িত | সার্ভার কোনো সীমা জানালে আকার আগেই ঘোষণা করা হয়, আর সীমার চেয়ে বড় বার্তা আপলোডের আগেই প্রত্যাখ্যাত হয়। |
| RFC 2920 | PIPELINING | বাস্তবায়িত | প্রেরক ও প্রাপকেরা দলে দলে; খামের সব উত্তর আসার পরেই DATA, যাতে বার্তা হয় সব প্রাপকের কাছে যায়, নয়তো কারও কাছেই না।2026-09-21 থেকে |
| RFC 6152 | 8BITMIME | বাস্তবায়িত | বার্তায় 8-বিট ডেটা থাকলে তা ঘোষণা করা হয়; সার্ভারের সমর্থন ছাড়া FOLD 8-বিট পাঠায় না।2026-09-21 থেকে |
| RFC 6531 | SMTPUTF8 | বাস্তবায়িত | আন্তর্জাতিক ঠিকানা ও UTF-8 হেডার; সার্ভারে এটি না থাকলে FOLD একটি স্পষ্ট বার্তা দিয়ে থেমে যায়।2026-09-21 থেকে |
| RFC 3463 | Enhanced Mail System Status Codes | বাস্তবায়িত | প্রত্যাখ্যানের কারণ সার্ভার কোডের বদলে সহজ ভাষায় ব্যাখ্যা করা হয় (RFC 2034 সহ)।2026-09-21 থেকে |
| RFC 3461 | Delivery Status Notifications | বাকি | অনুরোধে ডেলিভারি রিপোর্ট বাস্তবায়িত হয়নি। |
| RFC 3030 | CHUNKING (BDAT) | ইচ্ছাকৃতভাবে বাদ | শনাক্ত করা হয়, ব্যবহার করা হয় না; DATA সব ক্ষেত্র সামলায়। |
| RFC 8689 | REQUIRETLS | ইচ্ছাকৃতভাবে বাদ | এখনো প্রায় কোনো সার্ভারই এটি সমর্থন করে না। |
সংযোগ ও সাইন-ইন
সংযোগের এনক্রিপশন, সাইন-ইন পদ্ধতি ও স্বয়ংক্রিয় সেটআপ।
| RFC | মানদণ্ড | অবস্থা | FOLD-এ |
|---|---|---|---|
| RFC 8314 | Cleartext Considered Obsolete | বাস্তবায়িত | FOLD কখনো TLS ছাড়া সংযোগ করে না, আর DNS দুটোই দিলে implicit TLS বেছে নেয়। |
| RFC 3207 | SMTP over TLS (STARTTLS) | বাস্তবায়িত | সার্ভার STARTTLS না দিলে FOLD এনক্রিপশন ছাড়া পাঠানোর বদলে থেমে যায়। |
| RFC 7817 | TLS Server Identity Check for Email | বাস্তবায়িত | সার্টিফিকেট চেইন ও হোস্টনেম সিস্টেম কনফিগার করা সার্ভারের সঙ্গে মিলিয়ে যাচাই করে। |
| RFC 4422 | SASL | বাস্তবায়িত | নিচের প্রতিটি সাইন-ইন পদ্ধতির কাঠামো। |
| RFC 7677 | SCRAM-SHA-256 | আংশিক | পাঠানোর (SMTP) ক্ষেত্রে অগ্রাধিকার পায়, সার্ভার স্বাক্ষর যাচাইসহ; IMAP সাইন-ইন এখনো PLAIN ব্যবহার করে। |
| RFC 4616 | PLAIN | বাস্তবায়িত | কেবল TLS-এর ভেতরে, কখনো এনক্রিপশন ছাড়া নয় (ইচ্ছাকৃতভাবে RFC-এর চেয়ে কঠোর)। |
| RFC 6749 | OAuth 2.0 | বাস্তবায়িত | Google দিয়ে সাইন-ইন; IMAP ও SMTP-এর জন্য XOAUTH2, বড় প্রদানকারীরা যে পদ্ধতি ব্যবহার করে। |
| RFC 7636 | PKCE | বাস্তবায়িত | প্রতিটি OAuth সাইন-ইনে, কেবল S256; অ্যাপে কোনো ক্লায়েন্ট সিক্রেট নেই। |
| RFC 8252 | OAuth 2.0 for Native Apps | বাস্তবায়িত | সাইন-ইন হয় সিস্টেম ব্রাউজারে, কখনো এমবেড করা ওয়েব ভিউতে নয়। |
| RFC 7628 | OAUTHBEARER | বাকি | লক্ষ্যগোষ্ঠীর কোনো প্রদানকারী এটি চায় না; তাদের জন্য XOAUTH2-ই যথেষ্ট। |
| RFC 6186 | SRV Records for Email Submission and Access | বাস্তবায়িত | স্বয়ংক্রিয় সেটআপের উৎসগুলোর একটি। |
এনক্রিপশন ও স্বাক্ষর
S/MIME ও OpenPGP, এবং এদের পেছনের মৌলিক উপাদানগুলো।
| RFC | মানদণ্ড | অবস্থা | FOLD-এ |
|---|---|---|---|
| RFC 5652 | Cryptographic Message Syntax | বাস্তবায়িত | S/MIME-এর কন্টেইনার ফরম্যাট, iPhone ও iPad-এ নিজস্ব বাস্তবায়ন, Mac-এ সিস্টেমেরটি। |
| RFC 8551 | S/MIME 4.0 | আংশিক | RSA সার্টিফিকেট ও AES-CBC দিয়ে স্বাক্ষর, যাচাই, এনক্রিপ্ট ও ডিক্রিপ্ট; S/MIME 4.0 যে AES-GCM বাধ্যতামূলক করে, তা এখনো সমর্থিত নয়। |
| RFC 1847 | Security Multiparts for MIME | বাস্তবায়িত | স্বাক্ষরিত ও এনক্রিপ্ট করা মেইলের মোড়ক। |
| RFC 3565 | AES in CMS | বাস্তবায়িত | S/MIME এনক্রিপশনের জন্য AES। |
| RFC 5754 | SHA-2 in CMS | বাস্তবায়িত | S/MIME স্বাক্ষরের জন্য SHA-256 ও তার চেয়ে শক্তিশালী। |
| RFC 5280 | X.509 Certificates | বাস্তবায়িত | সার্টিফিকেট পাথ সিস্টেমের আস্থা-মূল্যায়নে যাচাই হয়; প্রত্যাহার (revocation) যাচাই ঐচ্ছিক। |
| RFC 9580 | OpenPGP | আংশিক | সংস্করণ 4-এর কী (Ed25519, Curve25519, RSA), AES-256 ও অখণ্ডতা যাচাইসহ, gpg-এর সঙ্গে টেস্ট করা; সংস্করণ 6-এর কী ও AEAD এনক্রিপশন এখনো সমর্থিত নয়। |
| RFC 6637 | Elliptic Curve Cryptography in OpenPGP | বাস্তবায়িত | Curve25519 এনক্রিপশন কী, যে ফরম্যাট FOLD তৈরি ও ব্যবহার করে। |
| RFC 3156 | MIME Security with OpenPGP | বাস্তবায়িত | স্বাক্ষরিত ও এনক্রিপ্ট করা মেইলের জন্য PGP/MIME। |
| RFC 3394 | AES Key Wrap | বাস্তবায়িত | Curve25519 প্রাপকদের জন্য সেশন কী মুড়ে দেয়। |
| RFC 7253 | OCB Authenticated Encryption | বাস্তবায়িত | সিস্টেমের AES-এর ওপর নিজস্ব বাস্তবায়ন, RFC-এর টেস্ট ভেক্টরের সঙ্গে যাচাই করা; GnuPG-এর OCB-এনক্রিপ্ট করা বার্তা পড়তে ব্যবহৃত হয়। |
| RFC 9106 | Argon2 | বাস্তবায়িত | Fortress মোডের কী ডেরিভেশন, RFC-এর টেস্ট ভেক্টরের সঙ্গে যাচাই করা। |
| RFC 7693 | BLAKE2 | বাস্তবায়িত | Argon2-এর ভেতরে, নিজস্ব বাস্তবায়ন, openssl-এর সঙ্গে যাচাই করা। |
| RFC 5869 | HKDF | বাস্তবায়িত | CryptoKit থেকে, Fortress মোডের জন্য। |
প্রেরকের সত্যতা
FOLD কীভাবে যাচাই করে, বার্তাটি আসলে কে পাঠিয়েছে।
| RFC | মানদণ্ড | অবস্থা | FOLD-এ |
|---|---|---|---|
| RFC 6376 | DKIM Signatures | বাস্তবায়িত | ডিভাইসেই যাচাই: বডি হ্যাশ ও স্বাক্ষর নতুন করে হিসাব করা হয়। |
| RFC 8463 | Ed25519 for DKIM | বাস্তবায়িত | RFC-এর উদাহরণ বার্তার সঙ্গে যাচাই করা। |
| RFC 8301 | DKIM Crypto Algorithm Usage | বাস্তবায়িত | 1024 বিটের কম কী ও rsa-sha1 স্বাক্ষর প্রত্যাখ্যান করা হয়। |
| RFC 8601 | Authentication-Results | আংশিক | কেবল অ্যাকাউন্টের IMAP হোস্টনেমের অধীনে সিল দেওয়া ফলাফলই বিশ্বাস করা হয়; যে প্রদানকারীরা অন্য নাম ব্যবহার করে, Gmail-সহ, তাদের ক্ষেত্রে এখনো কোনো ফলাফল মেলে না। |
| RFC 7489 | DMARC | আংশিক | আপনার সার্ভার যে DMARC ফলাফল লিখে রেখেছে, FOLD তা ব্যবহার করে এবং অ্যালাইনমেন্ট নিজেই যাচাই করে; প্রকাশিত নীতি খোঁজা হয় কেবল কোনো ব্র্যান্ড লোগো দেখানোর আগে। |
| RFC 7208 | SPF | আংশিক | SPF-এর জন্য প্রেরকের IP ঠিকানা দরকার; আপনার সার্ভার যে ফলাফল লিখে রেখেছে, FOLD তা পড়ে। |
| BIMI | Brand Indicators for Message Identification (Internet-Draft) | বাস্তবায়িত | লোগো দেখানো হয় কেবল তখনই, যখন DMARC একটি প্রয়োগমূলক নীতিসহ পাস করে এবং একটি যাচাইকৃত মার্ক সার্টিফিকেট থাকে; প্রতি বার্তায় একবার আনা হয় এবং বার্তার সঙ্গেই সংরক্ষিত হয়। |
| RFC 9399 | Logotypes in X.509 Certificates | বাস্তবায়িত | ব্র্যান্ড লোগো নেওয়া হয় যাচাইকৃত মার্ক সার্টিফিকেট থেকে। |
পদ্ধতি
এই পাতা কীভাবে হালনাগাদ রাখা হয়
অবস্থাটি আসে FOLD-এর কনফরম্যান্স নিয়ম এবং RFC-এর সঙ্গে মিলিয়ে মেইল স্ট্যাকের একটি অডিট থেকে। এখানে দেখানোর আগে প্রতিটি সারি সোর্স কোডের সঙ্গে মিলিয়ে যাচাই করা হয়, আর কোড বদলালে পাতাটিও বদলায়। কোডে মোট 95টি ভিন্ন RFC উদ্ধৃত; এই পাতা দেখায় সেগুলো, যা ঠিক করে দেয় একটি মেইল ক্লায়েন্ট আসল সার্ভারের সঙ্গে কতটা ভালোভাবে কাজ করে।