الخلاصة
- يعرّف IMAP علامة
\Seenبأن الرسالة قُرئت، لكن ما يرصده الخادم هو حالة قابلة للتغيير: قد يضبطهاBODY[...]ضمنياً، ويجلبBODY.PEEK[...]المحتوى بلا ضبطها، ويستطيع عميل مخوّل إضافتها أو حذفها. - الادعاء بأن إنساناً قرأ يحتاج ربط صاحب الهوية والعميل وجيل علبة البريد وUID والأمر والعلامات قبل التغيير وبعده واستجابة الخادم وحدث العرض. البت وحده لا يثبت الانتباه أو الفهم أو الموافقة أو الرد.
فعل بشري داخل آلة حالات
ابتكر Mark Crispin بروتوكول IMAP كي تبقى الرسائل على الخادم ويصل إليها أشخاص عبر عملاء وأماكن مختلفة. يسجل نصب Stanford التذكاري أنه ابتكر البروتوكول أثناء عمله مبرمج نظم بين 1977 و1988. ويعرض ملفه في IETF خمساً وعشرين RFC، منها RFC 3501 التي أصبحت مرجع IMAP4rev1 الطويل الأمد. ويذكره Unicode Consortium، الذي أسهم فيه سنوات، خبيراً في البريد الإلكتروني وأباً لـ IMAP.
تمنح RFC 3501 علامة \Seen وصفاً مباشراً: الرسالة قُرئت. وتحافظ RFC 9051 الخاصة بـ IMAP4rev2 على الدلالة. يفيد الاسم في تبادل حالة موحدة بين العملاء، لكنه لا يحوّل الخادم إلى مراقب للعين أو الانتباه أو الفهم. فالمواصفات تفرّق بين «المستخدم» الإنسان و«العميل» البرمجي.
يرى الخادم أوامر وبيانات وسمات. لذلك تظل العبارة الموثوقة ضيقة: تحمل علبة البريد الآن علامة القراءة المعيارية. ولكي تصبح العبارة حكماً على شخص، يجب معرفة كيف وصل البت إليها.
FETCH يكتب الحالة وPEEK لا يكتبها ضمنياً
عندما يطلب العميل جزءاً من المتن عبر BODY[...]، تفرض RFC 3501 وRFC 9051 ضبط \Seen ضمنياً. وإذا تغيرت العلامة، يبلغ الخادم الحالة الجديدة. يصبح الجلب نفسه كتابة لبيانات وصفية.
أما BODY.PEEK[...] فيجلب الجزء بلا ضبط ضمني. لذلك قد يُجلب المتن وتتغير العلامة، أو يُجلب ولا تتغير، أو يضبط STORE العلامة بلا جلب المتن، أو تُمسح بعد الجلب.
تدعم هذه الخيارات المعاينة والمزامنة وقوائم «اقرأ لاحقاً». وهي تعني أيضاً أن العلامة ليست حساساً بشرياً. قد يجلب فهرس أو مرشح أو مخبأ أو مولد معاينة المحتوى؛ وهذه إمكانية تشغيلية لا وصف لخدمة بعينها. وبالعكس، قد يعرض عميل بيانات PEEK ويبقي الرسالة غير مقروءة. ينتهي دليل الخادم عند الأمر وأثره.
يمكن أن تدخل الرسالة بعلامة Seen
يسمح APPEND بعلامات ابتدائية، وتتضمن المواصفات أمثلة لرسالة مضافة ومعها \Seen. تصف العلامة حينها حالة الإدخال، ولا تثبت أن إنساناً قرأ النسخة بعد تخزينها.
ويضيف STORE العلامة أو يزيلها. يمكن لـ«تعليم الكل كمقروء» أن يعمل بلا عرض متن، ويمكن لـ«تعليم كغير مقروء» أن يمحوها بعد قراءة كاملة. وفي علبة مشتركة أو متعددة العملاء، قد يكون صاحب صلاحية آخر هو من صنع الحالة التي يراها المراقب لاحقاً.
لذلك لا تعني «غير مقروءة» أن لا إنسان قرأها قط؛ بل تعني غياب \Seen الآن. قد يخفي الرقم الحالي جلباً سابقاً أو تراجعاً يدوياً أو سباق مزامنة أو حالة APPEND أصلية.
الصلاحية تغيّر الأثر الدائم
تخصص RFC 4314 الحق s لتعديل \Seen. إذا افتقر المستخدم الحالي إليه، فلا يجوز لـ FETCH الذي كان سيضبط العلامة أن يكتبها. ويتحقق STORE من الحق نفسه.
قد تجلب هويتان المتن ذاته وتتركان أثرين مختلفين: تكتب إحداهما البت، وتمنع السياسة الأخرى. عندئذ قد يثبت غياب العلامة حدّ تفويض، لا غياب عرض المحتوى.
وقد تستخدم التطبيقات علامات مشتركة أو غير مشتركة. لذا فالسؤال الكامل هو: حالة من، وفي أي نموذج علبة، وبأي حق كُتبت؟ لا تمنح العلبة الشخصية وعلبة الدعم المشتركة والتفويض التنفيذي دليلاً متساوياً لمجرد تشابه اسم العلامة.
ترتيب التغييرات لا يحدد السبب البشري
تضيف RFC 7162 آليتي CONDSTORE وQRESYNC. تكشف أرقام التعديل الحالة الأحدث وتحدّث المخبأ وتربط STORE بشرط UNCHANGEDSINCE. يمكن للكتابة القديمة أن تفشل كتعـارض بدلاً من طمس تحديث أحدث.
لكن MODSEQ إيصال ترتيب لا شهادة. لا يميز وحده FETCH الضمني من STORE أو عميل آخر أو وكيل خارجي، ولا يسجل الشاشة أو الانتباه. وتنقل RFC 8621 الفكرة إلى JMAP بالكلمة $seen التي يستطيع المستخدم المخوّل إضافتها أو حذفها. اتساق المزامنة يثبت الحالة المنسوخة، لا يوسّع نطاق ما راقبته.
بناء القراءة من إيصالات منفصلة
يحفظ السجل القابل للدفاع صاحب الهوية الموثقة والتفويض ونسخة العميل والجلسة. ويربط جيل العلبة عبر UIDVALIDITY بمعرف الرسالة UID. ثم يسمي السبب: BODY FETCH أو PEEK أو STORE أو APPEND أو مزامنة أو وكيل خارجي، مع الجزء المطلوب والعلامات قبل وبعد والاستجابة والوقت وMODSEQ إن وجد.
عرض الواجهة حدث آخر، وإقرار الإنسان حدث ثالث. يمكن للسجل أن يقول: «جُلب المتن؛ ضُبط Seen ضمنياً؛ العرض مجهول؛ لا إقرار». العبارة أقل راحة من «مقروءة»، لكنها لا تخترع شاهداً.
جعل Crispin حالة علبة البريد قابلة للتشغيل البيني. وعلى المؤسسات ألا تجعل هذه الحالة تشهد عن إنسان لم يره البروتوكول.
المصادر
- Mark Crispin — IETF Datatracker
- Mark Crispin في سجل Stanford التذكاري لعام 2012
- RFC 3501 — IMAP4rev1
- RFC 4314 — حقوق التحكم في وصول IMAP4
- RFC 7162 — IMAP CONDSTORE وQRESYNC
- RFC 8621 — JMAP Mail
- RFC 9051 — IMAP4rev2
- صورة Mark Crispin العامة — Unicode Consortium
- صفحة Mark Crispin التذكارية — Unicode Consortium
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
