نام (NAME)

lei-mail-formats - قالب‌های نامه پشتیبانی‌شده توسط lei

توضیحات (DESCRIPTION)

دستور lei-q(1) از نوشتن در چندین قالب رایج نامه برای هم‌کنش‌پذیری با کارخواه‌های کاربری نامه (MUA) پشتیبانی می‌کند؛ در ادامه برای کمک به کاربران در انتخاب قالب، مروری بر آن‌ها آورده شده است.

Maildir

قالب خروجی پیش‌فرض هنگام ارائه یک مسیر فایل‌سیستم است و از دسترسی خواندن و نوشتن موازی پشتیبانی می‌کند. عملکرد آن برای دایرکتوری‌های کوچک‌تر قابل قبول است، اما با بزرگ‌تر شدن صندوق‌های پستی کاهش می‌یابد. سرعت و مقیاس‌پذیری به دلیل استفاده از فایل‌های کوچک و تعداد زیاد فراخوان‌های سیستمی (syscalls)، توسط عملکرد هسته و فایل‌سیستم محدود می‌شود.

همچنین ببینید: https://cr.yp.to/proto/maildir.html و https://wiki2.dovecot.org/MailboxFormat/Maildir

خانواده Mbox (Mbox family)

خانواده mbox شامل چندین قالب ناسازگار با یکدیگر است. قفل‌گذاری برای دسترسی موازی پشتیبانی می‌شود، اما ممکن است میان ابزارهای گوناگون سازگار نباشد. با فشرده‌سازی (مانند gzip(1))، این قالب‌ها کمترین میزان فضا را مصرف می‌کنند و در عین حال عملکرد فقط‌خواندنی خوبی ارائه می‌دهند.

به‌روزرسانی کلیدواژه‌ها (سرفصل‌های "Status:" و/یا "X-Status:") عموماً نیازمند بازنویسی کل فایل mbox است.

همچنین ببینید: https://www.loc.gov/preservation/digital/formats/fdd/fdd000383.shtml، mbox(5)

mboxo

قالب سنتی BSD است. این قالب "From " را به ">From " نقل‌قول (quote) می‌کند، اما خطوطی که پیشاپیش با ">From " آغاز شده‌اند نقل‌قول نمی‌شوند، از این رو بازگشت‌پذیری خودکار تضمین نمی‌گردد. برنامه‌های MUA که از "mboxcl" یا "mboxcl2" پشتیبانی می‌کنند ممکن است این موارد را به‌صورت خودکار به قالب ترجیحی خود تبدیل کنند.

کوتاه‌شدگی فایل (Truncation) غیرقابل تشخیص است، مگر اینکه با gzip یا مشابه‌های آن فشرده شده باشد.

mboxrd

تکاملی از "mboxo" است، اما خطوط "From " را که با هر تعداد کاراکتر ">" پیشوند خورده باشند نقل‌قول می‌کند و بنابراین کاملاً بازگشت‌پذیر است.

این قالب توسط PublicInbox::WWW(3pm) همراه با gzip تولید می‌شود. از نسخه 2.10 ابزار git، دستور "git am --patch-format=mboxrd" این قالب را می‌خواند. دستورات "git log" و "git format-patch --stdout" نیز می‌توانند با سوییچ "--pretty=mboxrd" این قالب را تولید کنند.

همانند "mboxo" فشرده‌نشده، فایل‌های mboxrd فشرده‌نشده نیز در برابر کوتاه‌شدگی غیرقابل تشخیص آسیب‌پذیر هستند.

این قالب در برنامه‌های MUA که از آن ناآگاه هستند، بدون مشکل به رفتاری مشابه "mboxo" تنزل می‌یابد، زیرا نقل‌قول‌های اضافی ">From " برای انسان قابل تشخیص است.

mboxcl

همان "mboxo" با سرفصل "Content-Length:" است؛ خطوط "From " همچنان نقل‌قول باقی می‌مانند تا خوانایی با MUAهای مبتنی بر "mboxo" و "mboxrd" حفظ شود. با این حال، هنگام استفاده از ابزارهایی که از "Content-Length:" آگاه نیستند و به‌روزرسانی‌ها را با ساختار "mboxo" می‌نویسند، خراب شدن این فایل‌ها بسیار محتمل است.

برنامه mutt(1) هنگام باز کردن فایل، قالب‌های "mboxo" و "mboxrd" را به mboxcl تبدیل می‌کند.

همچنین ببینید: https://www.jwz.org/doc/content-length.html

mboxcl2

مشابه "mboxcl" است، اما بدون هرگونه نقل‌قول برای "From ". این قالب به‌طور کامل با MUAهایی که فقط از "mboxo" و/یا "mboxrd" پشتیبانی می‌کنند ناسازگار است. این قالب توسط mutt(1) هنگام نوشتن در یک mbox جدید تولید می‌شود.

MH

پشتیبانی مقدماتی برای خواندن از نسخه 2.0.0 فراهم شده است. معناشناسی قفل‌گذاری میان نویسنده‌های موجود به شکلی ناسازگار تفاوت دارد: Python و nmh با یکدیگر سازگار به نظر می‌رسند، در حالی که mutt به دلیل احتمال بازنویسی و تخریب فایل ".mh_sequences" توسط rename(2)، مستعد تداخل و برای دسترسی موازی نامناسب به نظر می‌رسد. اطلاعات بیشتر درباره دیگر کلاینت‌ها بسیار مورد استقبال خواهد بود.

شماره‌های توالی ممکن است توسط برخی از ابزارهای نویسنده فشرده (pack) و مجدداً استفاده شوند؛ بنابراین اگر inotify|kevent هنگام خاموش بودن lei-daemon(8) این فشرده‌سازی را از دست داده باشد، کاربران lei ممکن است نیاز به اجرای lei-refresh-mail-sync(1) داشته باشند.

برنامه lei برای خواندن آرشیوهای mlmmj به‌عنوان MH ایمن است، زیرا mlmmj نه شماره‌ها را فشرده می‌کند و نه از فایل .mh_sequences برای ذخیره وضعیت استفاده می‌نماید.

MMDF

هنوز پشتیبانی نمی‌شود، و مشخص نیست که آیا میزان استفاده و پشتیبانی فعلی، ارزش افزودن آن را دارد یا خیر.

IMAP

بسته به نرم‌افزار سرور IMAP و پیکربندی آن، سرورهای IMAP ممکن است از هر یک از قالب‌های پیش‌گفته (یا ترکیبی از آن‌ها) یا یک پایگاه داده غیراستاندارد استفاده کنند. در حال حاضر lei از Mail::IMAPClient استفاده می‌کند که روی اتصالات با تاخیر کم (low-latency) عملکرد قابل قبولی دارد. عملکرد روی اتصالات با تاخیر بالا در حال حاضر ضعیف است.

eml

یک فایل نامه خام تکی. "eml" یک قالب خروجی برای lei نیست، اما به‌عنوان یک "--input-format" ("-F") برای دستورات فقط‌خواندنی نظیر lei-tag(1) و lei-import(1) پذیرفته می‌شود.

از آنجا که "eml" پسوند مربوط به نوع MIME "message/rfc822" است (طبق فایل "mime.types")، اگر "--input-format" مشخص نشده باشد، lei نوع را بر اساس پسوند ".eml" استنتاج می‌کند.

فایل‌های دارای پسوند ".patch" که توسط git-format-patch(1) (بدون "--stdout") تولید می‌شوند، فایل‌های "eml" به همراه سرفصل "From " قالب mbox هستند. lei(1) هنگام خواندن این فایل‌ها جهت سازگاری با "git-am(1)" و ابزارهای مشابه، خطوط "From " را حذف می‌کند تا با آن‌ها به عنوان "eml" رفتار کند.

حق نشر (COPYRIGHT)

حق نشر ۲۰۲۱ تمام مشارکت‌کنندگان <mailto:meta@public-inbox.org>

مجوز: AGPL-3.0+ http://www.gnu.org/licenses/agpl-3.0.txt

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

lei(1)، lei-q(1)، lei-convert(1)، lei-overview(7)