نام (NAME)

mbox - قالب ذخیره‌سازی پیام‌های رایانامه (ایمیل)

توضیحات (DESCRIPTION)

این سند قالبی را شرح می‌دهد که به طور سنتی توسط میزبان‌های یونیکس برای ذخیره‌سازی محلی پیام‌های ایمیل استفاده می‌شود. فایل‌های mbox معمولاً در مسیر نگهداری موقت ایمیل‌های سیستم (spool)، با نام‌های مختلف در پوشه‌های Mail کاربران، و با نام mbox در دایرکتوری خانگی کاربران قرار دارند.

یک فایل mbox یک فایل متنی شامل تعداد دلخواهی از پیام‌های رایانامه (ایمیل) است. هر پیام از یک مهر پستی (postmark) تشکیل شده که پس از آن پیام ایمیل با قالب‌بندی مطابق با RFC822 و RFC2822 قرار می‌گیرد. قالب فایل خط‌محور است. خطوط با نویسه تغییر خط (LF با کد اسکی ۱۰) از یکدیگر جدا می‌شوند.

یک خط مهر پستی شامل چهار نویسه «From» است که به دنبال آن یک نویسه فاصله، سپس نشانی فرستنده پاکت (envelope) پیام، یک فاصله سفید و در نهایت مهر زمانی می‌آید. این خط معمولاً خط From_ نامیده می‌شود.

انتظار می‌رود نشانی فرستنده از نوع addr-spec به گونه‌ای که در بخش 3.4.1 از RFC2822 تعریف شده باشد. تاریخ باید به فرمت date-time خروجی تابع asctime(3) باشد. به دلایل سازگاری با نرم‌افزارهای قدیمی، سال‌های دو رقمی بزرگ‌تر یا مساوی ۷۰ باید به عنوان سال‌های ۱۹۷۰ به بعد تفسیر شوند، در حالی که سال‌های دو رقمی کمتر از ۷۰ باید به عنوان سال‌های ۲۰۰۰ تا ۲۰۶۹ تعبیر گردند. نرم‌افزاری که فایل‌ها را در این قالب می‌خواند باید برای پذیرش اطلاعات منطقه زمانی غیرعددی مانند «CET DST» برای ساعت تابستانی اروپای مرکزی نیز آماده باشد.

نمونه:

>From example@example.com Fri Jun 23 02:56:55 2000

برای جلوگیری از تفسیر نادرست خطوط بدنه پیام که با چهار نویسه «From» به همراه یک نویسه فاصله آغاز می‌شوند، عامل تحویل ایمیل (MDA) باید هر بار رخ دادن «From » در ابتدای خط بدنه را نقل‌قول (quote) یا اسکیپ کند.

دو طرح مختلف برای نقل‌قول وجود دارد؛ اولی (MBOXO) تنها خطوط معمولی «From » در بدنه را با افزودن «>» به ابتدای خط نقل‌قول می‌کند؛ دومی (MBOXRD) خطوطی را که از پیش نقل‌قول شده‌اند نیز با افزودن یک «>» دیگر نقل‌قول می‌کند (مانند «>From »، «>>From » و...). دومی این مزیت را دارد که خطوطی مانند:

>From the command line you can use the '-p' option

به اشتباه نقل‌قول‌زدایی نمی‌شوند، زیرا یک MDA از نوع MBOXRD این خط را پیش از ذخیره به شکل زیر تبدیل می‌کند:

>>From the command line you can use the '-p' option

علاوه بر MBOXO و MBOXRD، قالب MBOXCL نیز وجود دارد که همان MBOXO همراه با فیلد «Content-Length:» است که تعداد بایت‌های بدنه پیام را مشخص می‌کند؛ برخی MUAها (مانند mutt(1)) هنگام بازنویسی صندوق‌های پستی، صندوق‌های MBOXO را به صورت خودکار به MBOXCL تبدیل می‌کنند، زیرا MBOXCL می‌تواند بدون مشکل توسط هر MUA مبتنی بر MBOXO خوانده شود.

اگر زمان تغییر (که معمولاً از طریق stat(2) تعیین می‌شود) یک فایل mbox غیرخالی از زمان دسترسی به آن بیشتر باشد، فایل دارای ایمیل جدید است. بسیاری از MUAها یک سرآیند Status: در هر پیام قرار می‌دهند تا نشان دهند کدام پیام‌ها قبلاً خوانده شده‌اند.

قفل‌گذاری (LOCKING)

از آنجا که فایل‌های mbox معمولاً توسط چندین برنامه به صورت موازی مورد دسترسی قرار می‌گیرند، دسترسی به این فایل‌ها عموماً نباید بدون قفل‌گذاری صورت پذیرد.

سه سازوکار قفل‌گذاری مختلف (و ترکیبی از آن‌ها) به صورت عمومی استفاده می‌شوند:

• قفل‌گذاری fcntl(2) بیشتر در سیستم‌های جدیدتر و منطبق بر استاندارد POSIX استفاده می‌شود. استفاده از این روش به ویژه زمانی که فایل‌های mbox از طریق سیستم فایل شبکه‌ای (NFS) قابل دسترسی هستند توصیه می‌شود، زیرا ظاهراً تنها روش مطمئن برای باطل کردن حافظه موقت کلاینت‌های NFS است.
• قفل‌گذاری flock(2) بیشتر در سیستم‌های مبتنی بر BSD به کار می‌رود.
• قفل نقطه‌ای (Dotlocking) در انواع سیستم‌ها استفاده می‌شود. برای قفل کردن یک فایل mbox با نام folder، برنامه ابتدا یک فایل موقت با نامی یکتا در دایرکتوری محل قرارگیری folder ایجاد می‌کند. سپس برنامه تلاش می‌کند با استفاده از فراخوان سیستمی link(2) یک پیوند سخت به نام folder.lock به فایل موقت ایجاد کند. موفقیت فراخوان سیستمی link(2) باید مجدداً با فراخوان‌های stat(2) اعتبارسنجی شود. اگر ایجاد پیوند موفقیت‌آمیز باشد، پوشه ایمیل قفل‌شده در نظر گرفته می‌شود. پس از آن فایل موقت را می‌توان با خیال راحت حذف کرد (unlink).

برای آزادسازی قفل، برنامه به سادگی فایل folder.lock را حذف می‌کند (unlink).

اگر چندین روش با هم ترکیب شوند، پیاده‌سازان باید اطمینان حاصل کنند که از حالت‌های غیرمسدودکننده (non-blocking) فراخوان‌های سیستمی fcntl(2) و flock(2) استفاده کنند تا از بن‌بست (deadlock) جلوگیری شود.

اگر چندین روش ترکیب شوند، یک فایل mbox نباید قبل از به دست آوردن تمامی قفل‌های جداگانه، با موفقیت قفل‌شده تلقی شود. هنگامی که یکی از روش‌های قفل‌گذاری جداگانه با شکست مواجه می‌شود، برنامه باید تمام قفل‌هایی را که با موفقیت کسب کرده است آزاد کند و پس از یک تاخیر مناسب، کل فرآیند قفل‌گذاری را از ابتدا آغاز نماید.

سازوکار قفل‌گذاری استفاده‌شده در یک سیستم خاص تابع خط‌مشی محلی سیستم است و باید به طور یکنواخت توسط تمام برنامه‌های نصب‌شده روی سیستم که به فایل‌های mbox دسترسی دارند استفاده شود. عدم رعایت این موضوع ممکن است منجر به از دست رفتن داده‌های ایمیل و خراب شدن فایل‌های mbox گردد.

فایل‌ها (FILES)

/var/spool/mail/$LOGNAME

$HOME/mbox

$HOME/Mail/

همچنین ببینید (SEE ALSO)

mutt(1), fcntl(2), flock(2), link(2), stat(2), asctime(3), maildir(5), mmdf(5), RFC822, RFC976, RFC2822

نویسنده (AUTHOR)

Thomas Roessler <roessler@does-not-exist.org>, Urs Janssen <urs@tin.org>

تاریخچه (HISTORY)

قالب mbox نخستین بار در نسخه ۶ یونیکس AT&T ظاهر شد.
گونه‌ای از این قالب در RFC976 مستند شده بود.