صندوق البريد

MBOX هو مصطلح عام لمجموعة من تنسيقات الملفات ذات الصلة المستخدمة لحفظ مجموعات من رسائل البريد الإلكتروني . وقد تم تطبيقه لأول مرة في الإصدار الخامس من نظام يونكس .

تُدمج جميع الرسائل في ملف MBOX (صندوق البريد) وتُخزن كنص عادي في ملف واحد. تبدأ كل رسالة بكلمة "From" متبوعة بمسافة (ما يُعرف بسطر "From") ثم عنوان البريد الإلكتروني للمرسل. يُحدد RFC 4155 أن الطابع الزمني UTC يتبع مسافة فاصلة أخرى. ^{[ 1 ]}

يُعد نظام معالجة الرسائل MH تنسيقًا مشابهًا لتنسيق mbox . أما الأنظمة الأخرى، مثل خادم Microsoft Exchange وخادم Cyrus IMAP ، فتخزن صناديق البريد في قواعد بيانات مركزية تُدار بواسطة نظام البريد، ولا يمكن للمستخدمين الوصول إليها مباشرةً. غالبًا ما يُشار إلى تنسيق صندوق البريد maildir كبديل لتنسيق mbox في أنظمة تخزين البريد الإلكتروني الشبكية.

على عكس بروتوكولات الإنترنت المستخدمة لتبادل البريد الإلكتروني، لم يتم تحديد تنسيق تخزين البريد الإلكتروني رسميًا من خلال آلية التقييس RFC ، بل تُرك الأمر برمته لمطوري برامج البريد الإلكتروني. مع ذلك، حدد معيار POSIX إطارًا عامًا بالتعاون مع برنامج mailx . في عام 2005، تم توحيد نوع الوسائط application/mbox في RFC 4155، والذي أشار إلى أن mbox يخزن رسائل البريد بتنسيق رسالة الإنترنت الأصلي (RFC 2822)، باستثناء استخدام حرف سطر جديد، وتخزين البيانات النظيفة بسبعة بتات، واشتراط إنهاء كل رسالة جديدة مضافة بسطر فارغ تمامًا في قاعدة بيانات mbox. ^{[ 1 ] [ 2 ]}

يستخدم تنسيق mbox سطرًا فارغًا واحدًا متبوعًا بالسلسلة 'From ' (مع مسافة) لتحديد الرسائل؛ وهذا قد يخلق غموضًا إذا احتوت الرسالة على نفس التسلسل في نص الرسالة.

على مر السنين، ظهرت أربعة إصدارات شائعة ولكنها غير متوافقة: mboxo و mboxrd و mboxcl و mboxcl2 . طُوِّر نظام التسمية هذا بواسطة دانيال ج. بيرنشتاين وراهول ديسي وآخرين عام 1996. نشأ كل منها من إصدار مختلف من نظام يونكس . نشأ كل من mboxcl و mboxcl2 من تنسيق الملفات المستخدم في أدوات البريد الإلكتروني لنظام يونكس System V الإصدار 4. أما mboxrd فقد ابتكره راهول ديسي وآخرون كترشيد لـ mboxo ، ثم اعتمدته لاحقًا بعض أدوات البريد الإلكتروني في يونكس، بما في ذلك qmail .

تُعاني جميع هذه الصيغ من مشكلة تتمثل في ضرورة تعديل محتوى الرسالة أحيانًا لإزالة الغموض، كما هو موضح أدناه، مما يُجبر التطبيقات على معرفة قاعدة الاقتباس المُستخدمة لإجراء عملية الإرجاع الصحيحة، وهو أمرٌ غير عملي. يضمن استخدام MIME واختيار ترميز نقل المحتوى الذي يقتبس أسطر "From_" بطريقة متوافقة مع المعايير عدم الحاجة إلى تغيير محتوى الرسالة، بل فقط تمثيلها في MIME . وبالتالي، تبقى قيم التحقق ثابتة، وهو شرط أساسي لدعم S/MIME و Pretty Good Privacy . من المرجح أن تستخدم التطبيقات التي تُنشئ رسائل جديدة وتُخزنها في ملفات قاعدة بيانات mbox هذا الأسلوب لفصل محتوى الرسالة عن تنسيق تخزين قاعدة البيانات.

يحدد كل من mboxo و mboxrd بداية الرسالة من خلال البحث عن سطور " From " الموجودة قبل رؤوس رسائل البريد الإلكتروني. إذا ظهرت سلسلة نصية فارغة (" ") في بداية سطر في رأس الرسالة أو متنها (وهو ما يُعد مخالفة لمعايير البريد في حالة الرأس، وليس في حالة المتن)، فيجب تعديل رسالة البريد الإلكتروني قبل تخزينها في ملف صندوق بريد mbox، وإلا سيُعتبر هذا السطر بدايةً لرسالة جديدة. لتجنب تفسير سلسلة نصية فارغة (" ") في بداية سطر في متن البريد الإلكتروني على أنها بداية رسالة جديدة، تقوم بعض الأنظمة بتعديل "From" ^{[ 3 ]} في الرسالة، عادةً بإضافة علامة أكبر من (>).From From 

 من وجهة نظري...

في صيغة mboxo ، تتسم هذه الأسطر بغموض لا رجعة فيه. ^{[ 4 ]} في صيغة mboxo ، قد يؤدي ذلك إلى تلف الرسالة. إذا كان السطر موجودًا بالفعل في البداية (كما هو الحال في الاقتباس)، فإنه يبقى دون تغيير عند الكتابة. وعند قراءته لاحقًا بواسطة برنامج البريد، تتم إزالة البادئة بشكل خاطئ. تحل صيغة mboxrd هذه المشكلة عن طريق التحويل إلى ، ثم التحويل إلى ، وهكذا. ويكون التحويل قابلاً للعكس دائمًا. ^{[ 5 ]}>From >From >From >From >>From 

مثال:

من MAILER-DAEMON، الجمعة 8 يوليو 2011، الساعة 12:08:34، من: المؤلف <author@example.com> ، إلى: المستلم <recipient@example.com>، الموضوع: رسالة تجريبية 1. هذا هو نص الرسالة. >من (يجب وضع علامة الهروب قبل كلمة "from"). يوجد 3 أسطر. من MAILER-DAEMON، الجمعة 8 يوليو 2011، الساعة 12:08:34، من: المؤلف <author@example.com> ، إلى: المستلم <recipient@example.com>، الموضوع: رسالة تجريبية 2. هذا هو نص الرسالة الثاني.

تستخدم صيغتا mboxcl و mboxcl2 رأسًاContent-Length: لتحديد أطوال الرسائل، وبالتالي سطر " من" الحقيقي  التالي . لا تزال صيغة mboxcl تقتبس أسطر "من   " في الرسائل نفسها كما تفعل صيغة mboxrd ، بينما لا تفعل صيغة mboxcl2 ذلك.

نظرًا لتخزين أكثر من رسالة في ملف واحد، يلزم وجود آلية لقفل الملفات لتجنب التلف الذي قد ينتج عن قيام عمليتين أو أكثر بتعديل صندوق البريد في الوقت نفسه. قد يحدث هذا إذا قام برنامج توصيل البريد الإلكتروني عبر الشبكة بتسليم رسالة جديدة في الوقت الذي يقوم فيه قارئ البريد بحذف رسالة موجودة.

استُخدمت آليات مختلفة غير متوافقة بين تنسيقات mbox المختلفة لتمكين قفل ملفات الرسائل، بما في ذلك fcntl(). lockf()وهذا لا يعمل بشكل جيد مع أنظمة الملفات المثبتة على الشبكة، مثل نظام ملفات الشبكة (NFS) ، ولهذا السبب استخدم نظام Unix تقليديًا ملفات "قفل النقطة" الإضافية، والتي يمكن إنشاؤها بشكل ذري حتى عبر NFS.

يجب أيضًا قفل ملفات Mbox أثناء قراءتها. وإلا، فقد يرى القارئ محتويات رسائل تالفة إذا كانت عملية أخرى تقوم بتعديل ملف Mbox في نفس الوقت، حتى وإن لم يحدث أي تلف فعلي في الملف.

في تطوير البرمجيات مفتوحة المصدر ، من الشائع إرسال التصحيحات بصيغة diff إلى قائمة بريدية للمناقشة. تسمح صيغة diff بإضافة "رؤوس" غير ذات صلة، مثل بيانات mbox. ^{[ 8 ] [ 9 ]} تدعم أنظمة التحكم في الإصدارات ، مثل Git، إنشاء تصحيحات بصيغة mbox وإرسالها إلى القائمة كرسائل بريد إلكتروني ضمن سلسلة محادثات. ^{[ 10 ] [ 11 ]}

يُستخدم تنسيق MBOX أيضًا كتنسيق لتبادل رسائل البريد الإلكتروني وأرشفتها. ولأن MBOX يخزن عدة رسائل بريد إلكتروني بالتسلسل في ملف نصي واحد، فإنه يُستخدم عادةً لتصدير بيانات صناديق البريد ونقلها وأرشفتها بين أنظمة البريد الإلكتروني المختلفة. تحتوي كل رسالة في ملف MBOX على رؤوس الرسائل كاملةً ومحتوى مُشفّر بتقنية MIME، مما يسمح بحفظ بيانات البريد الإلكتروني بغض النظر عن برنامج البريد الإلكتروني المُرسِل.

• دليل البريد
• ميكس (البريد الإلكتروني)
• نظام معالجة الرسائل MH

• صفحة دليل qmail mbox
• اتحاد البريد الإلكتروني عبر الإنترنت – هيئة وضع المعايير