'\" t .\" ** The above line should force tbl to be used as a preprocessor ** .\" .\" Manual page in man(7) format with tbl(1) and groff_www(7) .\" macros for fetchmail .\" .\" For license terms, see the file COPYING in this directory. .\" .\" .\" .\" The date is the last change of actual content, the version should match .\" the distribution (configure.ac). .TH FETCHMAIL 1 2025-10-10 "fetchmail 6.6.7" "fetchmail reference manual" .SH "نام (NAME)" fetchmail \- بازیابی ایمیل از سرورهای دارای قابلیت POP، IMAP، ETRN یا ODMR .SH "خلاصه دستور (SYNOPSIS)" \fBfetchmail\fP [\fIگزینه‌ها...\fP] [\fIسرور_ایمیل...\fP] .br \fBfetchmailconf\fP .SH "توضیحات (DESCRIPTION)" برنامه \fBfetchmail\fP یک ابزار بازیابی و فوروارد ایمیل است؛ این ابزار ایمیل‌ها را از سرورهای ایمیل راه دور بازیابی کرده و به سیستم تحویل محلی (کلاینت) شما فوروارد می‌کند. سپس می‌توانید ایمیل‌های دریافت شده را با استفاده از کلاینت‌های معمول ایمیل مانند \fBmutt\fP(1)، \fBelm\fP(1) یا \fBMail\fP(1) مدیریت کنید. ابزار \fBfetchmail\fP می‌تواند در حالت دیمن (پس‌زمینه) اجرا شود تا در فواصل زمانی مشخص به طور مکرر از یک یا چند سیستم استعلام بگیرد. .PP برنامه \fBfetchmail\fP می‌تواند ایمیل‌ها را از سرورهایی که از هر یک از پروتکل‌های رایج بازیابی ایمیل پشتیبانی می‌کنند جمع‌آوری کند: POP2 (منسوخ‌شده، در نسخه‌های آینده حذف خواهد شد)، POP3، IMAP2bis، IMAP4 و IMAP4rev1. این برنامه همچنین می‌تواند از افزونه ESMTP ETRN و پروتکل ODMR استفاده کند. (اسناد RFC توصیف‌کننده تمام این پروتکل‌ها در انتهای این صفحه راهنما فهرست شده‌اند.) .PP اگرچه هدف اصلی \fBfetchmail\fP استفاده روی پیوندهای درخواستی TCP/IP (مانند اتصالات SLIP یا PPP) است، اما ممکن است به عنوان یک عامل انتقال پیام (MTA) برای سایت‌هایی که بنا به دلایل امنیتی اجازه تراکنش‌های SMTP ارائه‌شده از سمت فرستنده (sender-initiated) را با sendmail نمی‌دهند نیز مفید باشد. .SH "هشدارهای منسوخ‌شدگی و امنیت رمزنگاری (DEPRECATION AND CRYPTOGRAPHIC SECURITY WARNINGS)" چندین الگوریتم رمزنگاری که در استانداردهای ایمیل برای احراز هویت به آن‌ها ارجاع داده شده است، بر پایه الگوریتم‌های MD4، MD5 یا SHA1 بودند که به ترتیب در سال‌های ۱۹۹۰، ۱۹۹۱ و ۱۹۹۵ توسعه یافتند. ۳۰ سال بعد، این الگوریتم‌ها دیگر امن تلقی نمی‌شوند و شکسته شده به شمار می‌روند. همه استانداردهای IETF و اسناد RFC استفاده از آن‌ها را کنار نگذاشته‌اند، و برخی پروتکل‌ها همچنان به طور فعال به چیزی که به نوعی MD4، MD5 یا SHA1 را در خود دارد نیازمندند؛ بنابراین غیرفعال کردن کامل استفاده از آن‌ها در fetchmail موجب از کار افتادن پروتکل‌هایی مانند ODMR، یا طرح‌های احراز هویت پیش‌تر محبوبی مانند POP3 به همراه APOP خواهد شد. توصیه می‌شود اتصالات پوشش‌داده‌شده با TLS را از طریق درگاه‌های اختصاصی 993 (برای IMAP4) یا 995 (برای POP3) یا مذاکره درون‌باندی STARTTLS به همراه این طرح‌های احراز هویت ترجیح دهید تا خطر افشای اطلاعات ورود کاهش یابد. همچنین، طرح‌های احراز هویت ضعیف در نسخه‌های آینده fetchmail به تدریج حذف خواهند شد؛ لطفاً فایل NEWS را که همراه با توزیع fetchmail شما ارائه شده است بررسی کنید. .SH "پشتیبانی و عیب‌یابی (SUPPORT, TROUBLESHOOTING)" برای عیب‌یابی، ردیابی و اشکال‌زدایی، باید میزان جزئیات خروجی fetchmail را افزایش دهید تا بتوانید دقیقاً آنچه رخ می‌دهد را مشاهده کنید. برای انجام این کار، لطفاً \fBهر دو دستور زیر را با اضافه کردن تمام گزینه‌هایی که به طور معمول استفاده می‌کنید، اجرا کنید:\fP .IP .nf env LC_ALL=C fetchmail \-V \-v \-\-nodetach \-\-nosyslog .fi .IP (این خط فرمان به زبان انگلیسی نحوه تفسیر پیکربندی شما توسط fetchmail را نمایش می‌دهد.) .IP .nf env LC_ALL=C fetchmail \-vvv \-\-nodetach \-\-nosyslog .fi .IP (این خط فرمان در عمل fetchmail را به همراه خروجی انگلیسی با جزئیات کامل اجرا می‌کند.) .PP همچنین به .UR "https://fetchmail.sourceforge.io/fetchmail-FAQ.html#G3" مورد #G3 در بخش پرسش‌های متداول (FAQ) برنامه fetchmail .UE مراجعه کنید. .PP اگر مایل به دریافت خروجی به زبان محلی خود هستید (در صورت پشتیبانی)، می‌توانید بخش LC_ALL=C را در دستورات بالا حذف کنید. با این حال، اگر قصد ارسال گزارش به لیست‌های ایمیل را دارید، لطفاً آن را نگه دارید؛ زیرا نگهدارندگان لزوماً زبان شما را متوجه نمی‌شوند، لطفاً از انگلیسی استفاده کنید. .SS "شروع سریع (QUICKSTART)" ۱. یک سرور ایمیل محلی SMTP، یا یک عامل تحویل ایمیل خط فرمانی (MDA) مانند maildrop یا dovecot-lda را راه‌اندازی، پیکربندی، آزمایش و اشکال‌زدایی کنید. اطمینان حاصل کنید که ایمیلی که از طریق آن برای خود ارسال می‌کنید به مقصد درست می‌رسد. تا زمانی که این بخش به درستی کار نکرده است ادامه ندهید، در غیر این صورت خطر از دست رفتن ایمیل‌ها وجود دارد! .PP ۲. یک فایل .fetchmailrc در پوشه خانگی خود ایجاد کنید که برای بازیابی‌های POP3 ساختاری شبیه به این داشته باشد: .IP .nf poll mailserver.example.org proto POP3 uidl user joe.sixpack keep ssl .fi .PP شما باید چندین عنصر را در اینجا تنظیم کنید: mailserver.example.org نام سرور است. joe.sixpack نام کاربری مورد استفاده برای اتصال به سرور است. گزینه keep مشخص می‌کند که پیام‌ها باید به جای حذف شدن، روی سرور باقی بمانند. گزینه ssl مشخص می‌کند که اتصال باید رمزگذاری شود. اگر به جای POP3 نیاز به استفاده از IMAP دارید، عبارت "proto POP3 uidl" را به "proto IMAP" تغییر دهید. .PP اگر تصمیم گرفتید تحویل ایمیل را از طریق یک برنامه خط فرمانی انجام دهید، یک گزینه mda اضافه کنید، به عنوان مثال: .IP .nf mda "/usr/bin/maildrop -d %T" .fi .PP ۳. سپس اطمینان حاصل کنید که فایل ~/.fetchmailrc برای هیچ‌کس جز خودتان قابل خواندن یا نوشتن نباشد: .IP .nf chmod 0600 ~/.fetchmailrc .fi .PP ۴. در نهایت، fetchmail را در حالت پرجزئیات (verbose) اجرا کرده و بررسی کنید که درست کار می‌کند. برای محدود کردن اثرات احتمالی در صورت بروز مشکل، ابتدا فقط دریافت دو پیام را امتحان می‌کنیم: .IP .nf fetchmail -v --fetchlimit 2 .fi .PP اگر سپس سرور POP3 از UIDL پشتیبانی نکرد، نمی‌توانید از گزینه "keep" روی آن سرور استفاده کنید و باید گزینه‌های uidl و keep را حذف کنید؛ اما توجه داشته باشید که در این حالت fetchmail پیام‌هایی را که با موفقیت تحویل داده است از روی سرور حذف خواهد کرد. .SH "راهنمای سریع TLS (SSL) (TLS (SSL) QUICKSTART)" توزیع fetchmail شما باید همراه با یک فایل README.SSL ارائه شده باشد، که توصیه می‌شود آن را مطالعه کنید. پیشنهاد می‌شود تمام استعلام‌ها را در صورت پشتیبانی سرور با \-\-ssl \-\-sslproto tls1.2+ پیکربندی کنید، که fetchmail را منطبق بر استانداردهای پیشنهادی اخیر IETF و بهترین رویه‌های جاری، شامل RFC-8314، RFC-8996 و RFC-8997 تنظیم می‌کند. برنامه Fetchmail نسخه 6.6.0 و جدیدتر همچنین از TLS و STARTTLS برای SMTP پشتیبانی می‌کند؛ برای نحوه پیکربندی آن‌ها گزینه \-\-smtphost را ببینید. .SH "مفاهیم (CONCEPTS)" اگر \fBfetchmail\fP با یک سرور POP یا IMAP (و نه با ETRN یا ODMR) استفاده شود، دو حالت عملیاتی بنیادین برای هر حساب کاربری که از آن ایمیل بازیابی می‌کند دارد: حالت \fIsingledrop\fP (تک‌مقصدی) و حالت \fImultidrop\fP (چندمقصدی). .IP "در حالت singledrop،" برنامه \fBfetchmail\fP فرض می‌کند که تمام پیام‌های موجود در حساب کاربری (صندوق پستی)، برای یک گیرنده واحد در نظر گرفته شده‌اند. هویت گیرنده یا به طور پیش‌فرض به کاربر محلی جاری که \fBfetchmail\fP را اجرا می‌کند نسبت داده می‌شود، یا باید به طور صریح در فایل پیکربندی مشخص گردد. .IP برنامه \fBfetchmail\fP زمانی از حالت singledrop استفاده می‌کند که پیکربندی fetchmailrc حداکثر شامل یک تعریف کاربر محلی برای یک حساب سرور مشخص باشد. .IP "در حالت multidrop،" برنامه \fBfetchmail\fP فرض می‌کند که حساب سرور ایمیل در واقع حاوی ایمیل‌هایی است که برای تعداد نامشخصی از گیرندگان مختلف در نظر گرفته شده‌اند. بنابراین، \fBfetchmail\fP باید تلاش کند «گیرنده پاکت» (envelope recipient) مناسب را از هدرهای هر پیام استخراج و استنتاج کند. در این حالت عملیاتی، \fBfetchmail\fP تقریباً عملکردی شبیه به یک عامل انتقال ایمیل (MTA) پیدا می‌کند. .IP توجه داشته باشید که نه پروتکل POP و نه IMAP برای استفاده به این شیوه طراحی نشده بودند، و از این رو اطلاعات پاکت نامه اغلب مستقیماً در دسترس نیست. ارائه‌دهنده خدمات اینترنت (ISP) باید اطلاعات پاکت نامه را در یکی از هدرهای پیام ذخیره کند \fBو\fP همچنین باید یک نسخه از پیام را به ازای هر گیرنده ذخیره نماید. اگر هر یک از این شرایط برقرار نباشد، این فرایند غیرقابل اعتماد خواهد بود، زیرا \fBfetchmail\fP مجبور است به حدس زدن گیرنده(های) واقعی پاکت نامه متوسل شود. این کار معمولاً برای پیام‌های لیست‌های ایمیل و ایمیل‌های Bcc شده، یا ایمیل‌های ارسالی برای چندین گیرنده در دامنه شما با شکست مواجه می‌شود. .IP برنامه \fBfetchmail\fP زمانی از حالت multidrop استفاده می‌کند که بیش از یک کاربر محلی و/یا یک کاراکتر عام (wildcard) برای یک حساب سرور مشخص در فایل پیکربندی تعیین شده باشد. .IP "در حالت‌های ETRN و ODMR،" این ملاحظات صدق نمی‌کند، زیرا این پروتکل‌ها بر پایه SMTP هستند که اطلاعات صریح گیرنده پاکت نامه را فراهم می‌سازد. این پروتکل‌ها همیشه از چندین گیرنده پشتیبانی می‌کنند. .PP هنگامی که هر پیام بازیابی می‌شود، \fBfetchmail\fP معمولاً آن را از طریق SMTP به درگاه 25 روی سیستمی که در حال اجرا است (localhost) تحویل می‌دهد، درست مانند اینکه از طریق یک پیوند معمولی TCP/IP دریافت شده باشد. \fBfetchmail\fP گیرنده پاکت نامه‌ای را که به شیوه شرح داده شده در بالا به دست آورده به سرور SMTP ارائه می‌دهد. سپس ایمیل طبق قوانین MTA شما تحویل داده خواهد شد (عامل انتقال ایمیل معمولاً \fBsendmail\fP(8)، \fBexim\fP(8) یا \fBpostfix\fP(8) است). فراخوانی MDA (عامل تحویل ایمیل) سیستم شما وظیفه MTA شماست. بنابراین تمامی مکانیسم‌های کنترل تحویل (مانند فایل‌های \fI.forward\fP) که معمولاً از طریق MTA سیستم و عوامل تحویل محلی در دسترس هستند، طبق معمول اعمال خواهند شد. .PP اگر پیکربندی fetchmail شما یک MDA محلی تعیین کند (گزینه \-\-mda را ببینید)، به جای برقراری ارتباط SMTP با درگاه 25، مستقیماً از آن استفاده خواهد شد. .PP اگر برنامه \fBfetchmailconf\fP در دسترس باشد، در راه‌اندازی و ویرایش پیکربندی fetchmailrc به شما کمک خواهد کرد. این برنامه تحت سیستم پنجره X اجرا می‌شود و نیازمند وجود زبان پایتون و ابزار Tk (همراه با اتصالات پایتون) روی سیستم شما است. اگر برای اولین بار fetchmail را برای حالت تک‌کاربره تنظیم می‌کنید، توصیه می‌شود از حالت تازه‌کار (Novice mode) استفاده کنید. حالت پیشرفته (Expert mode) کنترل کاملی بر پیکربندی fetchmail، از جمله قابلیت‌های چندمقصدی (multidrop) فراهم می‌کند. در هر دو حالت، دکمه «Autoprobe» توانمندترین پروتکلی را که یک سرور ایمیل مشخص پشتیبانی می‌کند به شما اطلاع داده و هشدارهای مربوط به مشکلات احتمالی آن سرور را نمایش می‌دهد. .SH "مقدمه‌ای بر این راهنما (PREFACE ON THIS MANUAL)" رشته‌های زمان اجرای Fetchmail به برخی زبان‌ها ترجمه (بومی‌سازی) شده‌اند، اما این صفحه راهنما فقط به زبان انگلیسی در دسترس است. در برخی شرایط، برای مقایسه خروجی با راهنما، ممکن است بازگرداندن خروجی fetchmail به زبان انگلیسی با بازنویسی متغیرهای محلی (locale) مفید باشد، به عنوان مثال: .IP .nf env LC_ALL=C fetchmail # سایر گزینه‌ها قبل از هش اضافه شوند .fi .IP .nf env LANG=en fetchmail # سایر گزینه‌ها قبل از هش اضافه شوند .fi .PP یا دستورات مشابه. جزئیات بسته به سیستم‌عامل متفاوت است. .SH "عملکرد عمومی (GENERAL OPERATION)" رفتار \fBfetchmail\fP توسط گزینه‌های خط فرمان و یک فایل کنترل اجرا به نام \fI~/.fetchmailrc\fP کنترل می‌شود، که ساختار دستوری آن را در بخش‌های بعدی توضیح می‌دهیم (این همان فایلی است که برنامه \fBfetchmailconf\fP ویرایش می‌کند). گزینه‌های خط فرمان بر تعاریف موجود در \fI~/.fetchmailrc\fP اولویت دارند و آن‌ها را بازنویسی می‌کنند. .PP هر نام سروری که پس از گزینه‌ها در خط فرمان مشخص کنید مورد استعلام قرار خواهد گرفت. اگر هیچ سروری را در خط فرمان مشخص نکنید، هر مدخل 'poll' موجود در فایل \fI~/.fetchmailrc\fP شما استعلام خواهد شد، مگر اینکه از گزینه idle استفاده شده باشد (که توضیحات آن را ببینید). .PP برای تسهیل استفاده از \fBfetchmail\fP در اسکریپت‌ها و خطوط لوله (pipelines)، این برنامه هنگام پایان کار یک کد خروج مناسب برمی‌گرداند -- بخش کدهای خروج (EXIT CODES) را در ادامه ببینید. .PP گزینه‌های زیر رفتار \fBfetchmail\fP را تغییر می‌دهند. به ندرت لازم است پس از راه‌اندازی یک فایل \fI.fetchmailrc\fP کارآمد، هیچ‌یک از این گزینه‌ها را مشخص کنید. .PP تقریباً تمام گزینه‌ها دارای یک کلمه کلیدی معادل هستند که می‌توان از آن برای تعریف آن‌ها در فایل \fI.fetchmailrc\fP استفاده کرد. .PP برخی گزینه‌های خاص در اینجا پوشش داده نشده‌اند، بلکه در بخش‌های «احراز هویت» (AUTHENTICATION) و «حالت دیمن» (DAEMON MODE) که در ادامه می‌آیند مستند شده‌اند. .SS "گزینه‌های عمومی (General Options)" .TP .B \-? | \-\-help نمایش راهنمای گزینه‌ها. .TP .B \-V | \-\-version اطلاعات نسخه نسخه نصب‌شده \fBfetchmail\fP شما را نمایش می‌دهد. هیچ عملیات بازیابی ایمیلی انجام نمی‌شود. در عوض، برای هر سرور مشخص‌شده، تمامی اطلاعات گزینه‌هایی که در صورت اتصال \fBfetchmail\fP به آن سرور محاسبه می‌شدند نمایش داده می‌شوند. هرگونه نویسه غیرقابل چاپ در گذرواژه‌ها یا نام‌های رشته‌ای دیگر به صورت توالی‌های گریز شبیه زبان C با بک‌اسلش نمایش داده می‌شوند. این گزینه برای بررسی اینکه آیا گزینه‌های شما به همان شکلی که می‌خواهید تنظیم شده‌اند یا خیر مفید است. .TP .B \-c | \-\-check یک کد وضعیت برمی‌گرداند تا مشخص کند آیا ایمیلی در انتظار است یا خیر، بدون اینکه واقعاً ایمیلی را بازیابی یا حذف کند (بخش کدهای خروج در ادامه را ببینید). این گزینه حالت دیمن را غیرفعال می‌کند (که در آن بی‌فایده خواهد بود). این گزینه با استعلام از چندین سایت به خوبی کار نمی‌کند و با ETRN یا ODMR نیز کارایی ندارد. اگر ایمیل‌های خوانده‌شده اما حذف‌نشده را در صندوق پستی سرور خود باقی بگذارید و پروتکل بازیابی شما نتواند پیام‌های نگه‌داشته‌شده را از پیام‌های جدید تشخیص دهد، نتیجه مثبت کاذب برمی‌گرداند. این بدان معناست که با IMAP کار می‌کند، با POP2 کار نمی‌کند و ممکن است گهگاه تحت POP3 دچار اختلال شود. .TP .B \-s | \-\-silent حالت خاموش (بی‌صدا). تمام پیام‌های پیشرفت/وضعیت را که معمولاً در حین بازیابی در خروجی استاندارد چاپ می‌شوند سرکوب می‌کند (اما پیام‌های خطای واقعی را سرکوب نمی‌کند). گزینه \-\-verbose بر این گزینه اولویت دارد. .TP .B \-v | \-\-verbose حالت پرجزئیات. تمام پیام‌های کنترلی رد و بدل شده میان \fBfetchmail\fP و سرور ایمیل در خروجی استاندارد (stdout) چاپ می‌شوند. بر گزینه \-\-silent اولویت دارد. تکرار دوگانه این گزینه (\-v \-v) باعث چاپ اطلاعات تشخیصی اضافی می‌شود. .TP .B \-\-nosoftbounce (از نسخه 6.3.10، کلمه کلیدی: set no softbounce، از نسخه 6.3.10) .br حالت برگشت سخت (Hard bounce). تمام خطاهای دائمی تحویل باعث حذف پیام‌ها از سرور بالادستی می‌شوند، بخش "no softbounce" را در ادامه ببینید. .TP .B \-\-softbounce (از نسخه 6.3.10، کلمه کلیدی: set softbounce، از نسخه 6.3.10) .br حالت برگشت نرم (Soft bounce). تمام خطاهای دائمی تحویل باعث می‌شوند در صورت پشتیبانی پروتکل، پیام‌ها روی سرور بالادستی باقی بمانند. .B این گزینه به طور پیش‌فرض فعال است تا با مستندات تاریخی fetchmail مطابقت داشته باشد، و در انتشار بعدی fetchmail به حالت hard bounce تغییر خواهد کرد. .SS "گزینه‌های نحوه برخورد با پیام‌ها (Disposal Options)" .TP .B \-a | \-\-all | (از نسخه 6.3.3) \-\-fetchall (کلمه کلیدی: fetchall، از نسخه 3.0) .br بازیابی هر دو دسته پیام‌های قدیمی (دیده‌شده) و جدید از سرور ایمیل. حالت پیش‌فرض، بازیابی پیام‌هایی است که سرور آن‌ها را دیده‌شده علامت‌گذاری نکرده است. تحت POP3، این گزینه همچنین استفاده از دستور RETR را به جای TOP اجباری می‌کند. توجه داشته باشید که بازیابی POP2 رفتاری شبیه به فعال بودن دائمی \-\-all دارد (بخش حالت‌های شکست در بازیابی در ادامه را ببینید) و این گزینه با ETRN یا ODMR کار نمی‌کند. اگرچه گزینه‌های خط فرمانی \-a و \-\-all و گزینه fetchall در فایل rc از دیرباز پشتیبانی می‌شدند، گزینه خط فرمانی \-\-fetchall در نسخه 6.3.3 اضافه شد. .TP .B \-k | \-\-keep (کلمه کلیدی: keep) .br نگه‌داشتن پیام‌های بازیابی‌شده روی سرور ایمیل راه دور. به طور معمول، پیام‌ها پس از بازیابی از پوشه موجود در سرور ایمیل حذف می‌شوند. تعیین گزینه \fBkeep\fP باعث می‌شود پیام‌های بازیابی‌شده در پوشه شما روی سرور ایمیل باقی بمانند. این گزینه با ETRN یا ODMR کار نمی‌کند. در صورت استفاده با POP3، توصیه می‌شود گزینه \-\-uidl یا کلمه کلیدی uidl را نیز مشخص کنید. .TP .B \-K | \-\-nokeep (کلمه کلیدی: nokeep) .br حذف پیام‌های بازیابی‌شده از سرور ایمیل راه دور. این گزینه حذف ایمیل‌های بازیابی‌شده را اجباری می‌کند. اگر در فایل \&\fI.fetchmailrc\fP خود حالت پیش‌فرض را روی \fBkeep\fP تنظیم کرده باشید، این گزینه می‌تواند مفید باشد. این گزینه در ETRN و ODMR به صورت اجباری فعال است. .TP .B \-\-moveto (کلمه کلیدی: moveto) .br در حالت IMAP، به جای پاکسازی (flush) پیام، آن را به پوشه IMAP مشخص‌شده منتقل می‌کند. این قابلیت برای جلوگیری از دست رفتن داده‌ها هنگام آزمایش مفید است و روش ترجیحی برای حذف ایمیل‌ها در برخی پیاده‌سازی‌هاست؛ برای نمونه، گوگل از شما می‌خواهد ایمیل‌ها را با انتقال به [Gmail]/Trash حذف کنید. فقط برای سرورهای IMAP در دسترس است. این گزینه تنها با \fB\-\-proto imap\fR پذیرفته می‌شود، اما در صورتی که IMAP به طور خودکار انتخاب شده باشد پذیرفته نمی‌شود. در صورت فعال بودن \fB\-\-keep\fR بی‌اثر است. .TP .B \-F | \-\-flush (کلمه کلیدی: flush) .br فقط POP3/IMAP. این یک گزینه خطرناک است و در صورت استفاده نادرست می‌تواند باعث از دست رفتن ایمیل‌ها شود. این گزینه پیام‌های قدیمی (دیده‌شده) را قبل از بازیابی پیام‌های جدید از سرور ایمیل حذف می‌کند. \fBهشدار:\fP اگر ایمیل خود را با کلاینت‌هایی غیر از fetchmail بررسی کنید، این گزینه می‌تواند باعث از دست رفتن ایمیل‌ها شود و باعث شود fetchmail پیامی را که هرگز قبلاً دریافت نکرده بود حذف کند. همچنین اگر سرور ایمیل پیام را پس از بازیابی دیده‌شده علامت‌گذاری کند (سرورهای IMAP2) می‌تواند باعث از دست رفتن ایمیل شود. احتمالاً نباید از این گزینه در فایل پیکربندی خود استفاده کنید. اگر از آن با POP3 استفاده می‌کنید، باید از گزینه 'uidl' استفاده نمایید. آنچه احتمالاً می‌خواهید تنظیمات پیش‌فرض است: اگر '\-k' را مشخص نکنید، fetchmail به طور خودکار پیام‌ها را پس از تحویل موفق حذف خواهد کرد. .TP .B \-\-limitflush فقط POP3/IMAP، از نسخه 6.3.0. حذف پیام‌های با حجم بیش از حد مجاز از سرور ایمیل قبل از بازیابی پیام‌های جدید. حد مجاز اندازه باید به طور جداگانه با گزینه \-\-limit مشخص شود. این گزینه با ETRN یا ODMR کار نمی‌کند. .SS "گزینه‌های پروتکل و پرس‌وجو (Protocol and Query Options)" .TP .B \-p | \-\-proto | \-\-protocol (کلمه کلیدی: proto[col]) .br مشخص کردن پروتکل مورد استفاده هنگام برقراری ارتباط با سرور ایمیل راه دور. اگر پروتکلی مشخص نشود، مقدار پیش‌فرض AUTO است. \fBproto\fP می‌تواند یکی از موارد زیر باشد: .RS .IP AUTO پروتکل‌های IMAP، POP3 و POP2 را امتحان می‌کند (موارد پشتیبانی‌نشده یا کامپایل‌نشده را نادیده می‌گیرد). .IP POP2 پروتکل Post Office Protocol 2 (قدیمی، در انتشار آینده حذف خواهد شد) .IP POP3 پروتکل Post Office Protocol 3 .IP APOP استفاده از POP3 با احراز هویت سنتی چالش MD5. در برابر حملات مرد میانی (man-in-the-middle) مقاوم تلقی نمی‌شود. .IP RPOP استفاده از POP3 با احراز هویت RPOP. .IP KPOP استفاده از POP3 با احراز هویت Kerberos V4 روی درگاه 1109. .IP SDPS استفاده از POP3 با افزونه‌های SDPS شرکت Demon Internet. .IP IMAP پروتکل‌های IMAP2bis، IMAP4 یا IMAP4rev1 (برنامه \fBfetchmail\fP قابلیت‌های آن‌ها را به طور خودکار تشخیص می‌دهد). .IP ETRN استفاده از گزینه ESMTP ETRN. .IP ODMR استفاده از پروفایل ESMTP با قابلیت On-Demand Mail Relay. .RE .PP تمام این گزینه‌ها اساساً به یک شیوه عمل می‌کنند (ارتباط با دیمن‌های استاندارد سرور برای بازیابی ایمیل‌هایی که قبلاً به صندوق پستی روی سرور تحویل داده شده‌اند)، به جز ETRN و ODMR. حالت ETRN به شما امکان می‌دهد از یک سرور ESMTP سازگار (مانند BSD sendmail در نسخه 8.8.0 یا بالاتر) بخواهید بلافاصله یک اتصال فرستنده SMTP به دستگاه کلاینت شما برقرار کرده و فوروارد تمامی مواردی را که در صف ایمیل‌های تحویل‌نشده سرور به مقصد دستگاه کلاینت شما قرار دارند آغاز کند. حالت ODMR نیازمند سروری با قابلیت ODMR است و مشابه ETRN عمل می‌کند، با این تفاوت که نیازی به داشتن DNS ایستا برای دستگاه کلاینت ندارد. .TP .B \-U | \-\-uidl (کلمه کلیدی: uidl) .br اجبار به استفاده از UIDL (فقط با POP3 موثر است). اجبار به ردیابی وضعیت «جدید بودن» پیام‌ها در سمت کلاینت (UIDL مخفف "unique ID listing" است و در RFC1939 شرح داده شده است). برای استفاده از صندوق پستی به عنوان یک دریافت‌کننده اخبار کوچک برای گروهی از کاربران به همراه 'keep' استفاده می‌شود. این واقعیت که پیام‌های دیده‌شده نادیده گرفته می‌شوند ثبت می‌شود، مگر اینکه ثبت خطای گزارش‌ها در حین اجرا در حالت دیمن از طریق syslog انجام شود. توجه داشته باشید که fetchmail ممکن است بسته به قابلیت‌های سرور بالادستی این گزینه را به طور خودکار فعال کند. همچنین توجه داشته باشید که این گزینه ممکن است در نسخه بعدی fetchmail حذف شده و استفاده از آن اجباری شود. همچنین ببینید: \-\-idfile. .TP .B \-\-idle (از نسخه 6.3.3) (کلمه کلیدی: idle، از قبل از نسخه 6.0.0) .br فعال کردن استفاده از IDLE (فقط با IMAP موثر است). توجه داشته باشید که این گزینه در یک زمان مشخص فقط با یک حساب کاربری و یک پوشه کار می‌کند؛ هنگامی که idle فعال باشد سایر پوشه‌ها یا حساب‌ها استعلام نخواهند شد! اگرچه کلمه کلیدی idle در فایل rc از دیرباز پشتیبانی می‌شد، گزینه خط فرمانی \-\-idle در نسخه 6.3.3 اضافه شد. استفاده از IDLE به این معنی است که fetchmail به سرور IMAP اعلام می‌کند تا اطلاعیه پیام‌های جدید را ارسال کند، تا بتوان آن‌ها را زودتر از آنچه با استعلام‌های دوره‌ای منظم ممکن است بازیابی کرد. برنامه Fetchmail همچنین شامل یک راهکار برای شبیه‌سازی IDLE است؛ این راهکار از نسخه 6.4.22 بی‌اثر بود و در نسخه 6.5.3 اصلاح شد (به دلیل کامیت 616e8c70 شکسته شده بود و در f91923b5 تعمیر شد)، گزارش Gitlab شماره #69. .TP .B \-\-forceidle (از نسخه 6.5.0) (کلمه کلیدی: forceidle، از نسخه 6.5.0) .br استفاده از IDLE حتی اگر سرور آن را در قابلیت‌های خود اعلام نکرده باشد. این یک گزینه خطرناک است، با احتیاط استفاده کنید. .TP .B \-\-idletimeout (از نسخه 6.5.0) (کلمه کلیدی: idletimeout، از نسخه 6.5.0) .br تنظیم مهلت زمانی (به ثانیه) برای دستور IDLE، زیرا سرورهای زیادی پروتکل را نقض می‌کنند (که نیازمند ۳۰ دقیقه است) و پس از چند دقیقه اتصال را قطع می‌کنند. مقدار پیش‌فرض: 1680 ثانیه (= ۲۸ دقیقه). .TP .B \-P | \-\-service (کلمه کلیدی: service) از نسخه 6.3.0. .br گزینه service به شما امکان می‌دهد نام سرویسی را برای اتصال مشخص کنید. اگر پایگاه‌داده سرویس‌های شما فاقد تخصیص‌های لازم پورت به سرویس باشد، می‌توانید یک شماره درگاه بر مبنای دهدهی در اینجا مشخص کنید. برای جزئیات، مورد R12 از بخش FAQ و مستندات \-\-ssl را ببینید. این گزینه جایگزین گزینه قدیمی‌تر \-\-port شده است. .P توجه داشته باشید که این گزینه به طور خودکار میان حالت‌های پوشش‌داده‌شده با TLS و حالت STARTTLS جابجا نمی‌شود؛ اگر در اینجا شماره درگاه یا نام سرویسی را مشخص کنید که با TLS پوشش داده شده است (به این معنی که مذاکره TLS را قبل از ارسال داده‌های برنامه به صورت متن آشکار آغاز می‌کند)، ممکن است لازم باشد \-\-ssl را در خط فرمان یا ssl را در فایل rc خود مشخص کنید. .TP .B \-\-port (کلمه کلیدی: port) .br نسخه منسوخ‌شده گزینه \-\-service که نام‌های سرویس را نمی‌پذیرد. \fBتوجه:\fP این گزینه ممکن است در نسخه‌های آینده حذف شود. .TP .B \-\-principal (کلمه کلیدی: principal) .br گزینه principal به شما امکان می‌دهد یک شناسه سرویس (principal) را برای احراز هویت متقابل مشخص کنید. این گزینه فقط برای POP3 یا IMAP به همراه احراز هویت Kerberos 4 کاربرد دارد. برای Kerberos 5 یا GSSAPI اعمال نمی‌شود. این گزینه ممکن است در نسخه آینده fetchmail حذف شود. .TP .B \-t | \-\-timeout (کلمه کلیدی: timeout) .br گزینه timeout به شما امکان می‌دهد یک مهلت زمانی عدم پاسخ سرور را بر حسب ثانیه تنظیم کنید. اگر سرور ایمیل برای تعداد ثانیه‌های مشخص‌شده پیام خوش‌آمدگویی ارسال نکند یا به دستورات پاسخ ندهد، \fBfetchmail\fP اتصال به آن را قطع خواهد کرد. بدون چنین مهلتی، \fBfetchmail\fP ممکن است در تلاش برای بازیابی ایمیل از میزبانی که از کار افتاده است تا زمان اتمام مهلت اتصال TCP معلق بماند، که ممکن است بسیار طولانی باشد. این وضعیت به ویژه برای اجرای \fBfetchmail\fP در پس‌زمینه آزاردهنده خواهد بود. یک مهلت زمانی پیش‌فرض وجود دارد که fetchmail\~\-V آن را گزارش می‌کند. اگر یک اتصال مشخص تعداد زیادی وقفه متوالی دریافت کند، fetchmail آن را مسدود تلقی کرده و تلاش مجدد را متوقف می‌کند. در این صورت از طریق ایمیل به کاربر فراخوان اطلاع داده خواهد شد. .IP از نسخه 6.3.10 برنامه fetchmail، کلاینت SMTP هنگام انتظار برای سرور SMTP/LMTP طرف مکالمه از حداقل مهلت‌های زمانی توصیه‌شده در RFC-5321 استفاده می‌کند. می‌توانید مهلت‌های زمانی را حتی بیشتر افزایش دهید، اما نمی‌توانید آن‌ها را کوتاه‌تر کنید. این برای جلوگیری از وضعیتی دردناک است که در آن fetchmail با مهلت زمانی کوتاهی (یک دقیقه یا کمتر) پیکربندی شده و پیامی طولانی (چندین مگابایت) را به MTA محلی ارسال می‌کند که پاسخ "OK" دادن آن بیش از مهلت زمانی طول می‌کشد، در حالی که در نهایت پاسخ خواهد داد؛ این بدان معناست که ایمیل به درستی تحویل داده می‌شود، اما fetchmail متوجه آن نمی‌شود و بنابراین این پیام بزرگ را بارها و بارها مجدداً بازیابی می‌کند. .TP .B \-\-plugin (کلمه کلیدی: plugin) .br گزینه plugin به شما امکان می‌دهد از یک برنامه خارجی برای برقراری اتصال TCP استفاده کنید. این قابلیت زمانی مفید است که بخواهید از ssh استفاده کنید یا به تنظیمات خاص فایروال نیاز داشته باشید. این برنامه در مسیرهای $PATH جستجو خواهد شد و می‌توان به صورت اختیاری نام میزبان و درگاه را با استفاده از "%h" و "%p" به عنوان آرگومان به آن ارسال کرد (توجه داشته باشید که منطق جایگذاری نسبتاً ابتدایی است و این نشانه‌ها باید با فاصله یا ابتدای رشته یا انتهای رشته محدود شوند). برنامه Fetchmail در ورودی استاندارد (stdin) پلاگین می‌نویسد و از خروجی استاندارد (stdout) آن می‌خواند. .TP .B \-\-plugout (کلمه کلیدی: plugout) .br همانند گزینه plugin در بالا، اما این گزینه برای اتصالات SMTP استفاده می‌شود. .TP .B \-r | \-\-folder (کلمه کلیدی: folder[s]) .br باعث بازیابی یک پوشه ایمیل غیرپیش‌فرض مشخص‌شده روی سرور ایمیل (یا فهرستی از پوشه‌ها با جداکننده کاما) می‌شود. ساختار دستوری نام پوشه وابسته به سرور است. این گزینه تحت POP3، ETRN یا ODMR در دسترس نیست. .TP .B \-\-tracepolls (کلمه کلیدی: tracepolls) .br به fetchmail دستور می‌دهد تا اطلاعات ردیابی استعلام را به صورت 'polling account %s' و 'folder %s' به خط Received که تولید می‌کند اضافه نماید، جایی که بخش‌های %s با نام راه دور کاربر، برچسب استعلام، و در صورت موجود بودن، پوشه (صندوق پستی) جایگزین می‌شوند (هدر Received معمولاً شامل نام واقعی سرور نیز هست). این قابلیت می‌تواند برای تسهیل فیلتر کردن ایمیل بر اساس حسابی که ایمیل از آن دریافت می‌شود استفاده شود. اطلاعات پوشه فقط از نسخه 6.3.4 به بعد نوشته می‌شود. .TP .B \-\-ssl (کلمه کلیدی: ssl) .br باعث می‌شود اتصال به سرور ایمیل از طریق SSL رمزگذاری شود، که با مذاکره مستقیم SSL پس از برقراری اتصال انجام می‌گیرد (حالت SSL-wrapped، یا Implicit TLS طبق RFC-8314 نامیده می‌شود). لطفاً توضیحات \-\-sslproto در ادامه را ببینید! اطلاعات بیشتر در فایل \fIREADME.SSL\fP همراه با fetchmail موجود است. .IP توجه داشته باشید که حتی اگر این گزینه حذف شود، fetchmail همچنان ممکن است از طریق ویژگی STLS یا STARTTLS اقدام به مذاکره درون‌باندی SSL برای POP3 یا IMAP کند. می‌توانید از گزینه \-\-sslproto برای تغییر این رفتار استفاده کنید. .IP اگر درگاهی مشخص نشود، تلاش برای اتصال به درگاه شناخته‌شده نسخه SSL پروتکل پایه صورت می‌گیرد. این درگاه معمولاً متفاوت از درگاه مورد استفاده توسط پروتکل پایه است. برای IMAP، این درگاه برای پروتکل متن آشکار 143 و برای پروتکل امن‌شده با SSL درگاه 993 است؛ برای POP3، برای متن آشکار درگاه 110 و برای نوع رمزگذاری‌شده درگاه 995 است. .IP اگر سیستم شما فاقد مدخل‌های مربوطه در /etc/services است، گزینه \-\-service را ببینید و شماره درگاه عددی را همان‌طور که در پاراگراف قبل ذکر شد مشخص کنید (مگر اینکه ISP شما درگاه‌های دیگری را به شما اعلام کرده باشد، که البته نامعمول است). .TP .B \-\-nossl (کلمه کلیدی: nossl) .br در صورت تعیین \-\-nossl در خط فرمان، مقدار پیش‌فرض ssl که قبلاً در بخش defaults یا در فایل rc تعیین شده بود لغو می‌شود. از \-\-sslproto با آرگومان مناسب برای فعال‌سازی STARTTLS استفاده کنید. .TP .B \-\-sslcert (کلمه کلیدی: sslcert) .br برای احراز هویت کلاینت مبتنی بر گواهی. برخی سرورهای رمزگذاری‌شده با SSL برای احراز هویت نیازمند کلیدها و گواهی‌های سمت کلاینت هستند. در بیشتر موارد، این مورد اختیاری است. این گزینه مکان گواهی کلید عمومی را مشخص می‌کند که باید در زمان برقراری نشست SSL به سرور ارائه شود. اگر سرور به آن نیاز نداشته باشد الزامی نیست (اما می‌تواند ارائه شود). می‌تواند همان فایل کلید خصوصی باشد (فایل ترکیبی کلید و گواهی)، اما این کار توصیه نمی‌شود. همچنین \-\-sslkey در ادامه را ببینید. .sp \fBتوجه:\fP اگر از احراز هویت کلاینت استفاده کنید، نام کاربری از CommonName گواهی استخراج شده و بر نام تنظیم‌شده با \-\-user اولویت خواهد داشت. .TP .B \-\-sslkey (کلمه کلیدی: sslkey) .br نام فایل کلید خصوصی SSL سمت کلاینت را مشخص می‌کند. برخی سرورهای رمزگذاری‌شده با SSL برای احراز هویت به کلیدها و گواهی‌های سمت کلاینت نیاز دارند. در بیشتر موارد، این مورد اختیاری است. این گزینه مکان کلید خصوصی مورد استفاده برای امضای تراکنش‌ها با سرور در زمان برقراری نشست SSL را مشخص می‌کند. اگر سرور به آن نیاز نداشته باشد الزامی نیست (اما می‌تواند ارائه شود). می‌تواند همان فایل گواهی کلید عمومی باشد (فایل ترکیبی کلید و گواهی)، اما این کار توصیه نمی‌شود. .IP اگر برای باز کردن قفل کلید به گذرواژه نیاز باشد، درست قبل از برقراری نشست با سرور درخواست گذرواژه خواهد شد. این موضوع می‌تواند در حالت دیمن پیچیدگی‌هایی ایجاد کند. .IP همچنین \-\-sslcert در بالا را ببینید. .TP .B \-\-sslproto (کلمه کلیدی: sslproto، توجه: تغییرات معنایی از نسخه 6.4.0) .br این گزینه به دلیل رفتارهای تاریخی fetchmail کاربرد دوگانه‌ای دارد. این گزینه هم نسخه پروتکل SSL/TLS و هم در صورتی که \-\-ssl مشخص نشده باشد، رفتار STARTTLS (ارتقای درون‌باندی پروتکل به یک اتصال SSL یا TLS) را کنترل می‌کند. با این حال برخی گزینه‌های دیگر ممکن است استفاده از TLS را اجباری کنند \-\- به ویژه، \-\-sslcertck اکنون رفتار پیش‌فرض است و نیازمند SSL می‌باشد. .IP مقادیر شناخته‌شده برای \-\-sslproto در زیر آمده است. به طور معمول باید یکی از گزینه‌های دارای مذاکره خودکار را انتخاب کنید، یعنی '\fBtls1.2+\fP' یا '\fBauto\fP' یا یکی از گزینه‌های دیگری که با نویسه مثبت (\fB+\fP) پایان می‌یابند. توجه داشته باشید که بسته به نسخه و پیکربندی کتابخانه TLS (مانند OpenSSL، AWS-LC، wolfSSL)، برخی گزینه‌ها باعث خطاهای زمان اجرا می‌شوند زیرا نسخه‌های درخواستی SSL یا TLS توسط کتابخانه TLS نصب‌شده پشتیبانی نمی‌شوند. حتماً قبل از استقرار برای کار بدون نظارت، به خوبی آزمایش کنید! .RS .IP '\fBauto\fP' (پیش‌فرض، مشابه TLS1.2+). از نسخه 6.4.0، تغییر یافته در نسخه 6.5.0. الزام به استفاده از TLS. مذاکره خودکار TLSv1.2 یا جدیدتر، غیرفعال‌سازی تنزل به نسخه‌های پایین‌تر. (نسخه‌های قدیمی‌تر fetchmail نسبت به 6.5.0 پروتکل‌های قدیمی‌تر را به صورت خودکار مذاکره می‌کردند؛ نسخه 6.4.x به طور پیش‌فرض TLSv1.0 را مجاز می‌دانست و نسخه 6.3.x اجازه SSLv3 را می‌داد). .IP "\fB''\fP، رشته خالی" غیرفعال‌سازی STARTTLS. اگر برای همان سرور گزینه \-\-ssl تعیین شده باشد، خطایی ثبت می‌شود و وانمود می‌شود که از '\fBauto\fP' استفاده شده است. .IP \&'\fBSSL23\fP' گزینه '\fBauto\fP' را ببینید. منسوخ‌شده، برای سازگاری با گذشته شناخته می‌شود. .IP \&'\fBTLS\fP' گزینه '\fBauto\fP' را ببینید. جهت تقارن با نام‌های متد کلاینت OpenSSL. .IP \&'\fBTLS1\fP' الزام به TLSv1. این مقدار برای TLSv1.1 یا جدیدتر مذاکره نمی‌کند و توصیه نمی‌شود. به جای آن از TLS1+ استفاده کنید مگر اینکه دومی باعث اختلال در سرور شما شود. .IP \&'\fBTLS1+\fP' از نسخه 6.4.0. این یک ویژگی مذاکره خودکار است که TLSv1.0 و جدیدتر را مجاز می‌دانست. .IP \&'\fBTLS1.1\fP' از نسخه 6.4.0. الزام به استفاده دقیق از TLS v1.1. .IP \&'\fBTLS1.1+\fP' از نسخه 6.4.0. الزام به TLS. مذاکره خودکار TLSv1.1 یا جدیدتر. .IP \&'\fBTLS1.2\fP' از نسخه 6.4.0. الزام به استفاده دقیق از TLS v1.2. .IP '\fBTLS1.2+\fP' از نسخه 6.4.0. الزام به TLS. مذاکره خودکار TLSv1.2 یا جدیدتر. این مقدار در fetchmail نسخه 6.5.x پیش‌فرض است. .IP \&'\fBTLS1.3\fP' از نسخه 6.4.0. الزام به استفاده دقیق از TLS v1.3. .IP '\fBTLS1.3+\fP' از نسخه 6.4.0. الزام به TLS. مذاکره خودکار TLSv1.3 یا جدیدتر. .IP "پارامترهای ناشناخته" همانند '\fBauto\fP' رفتار می‌شوند. .RE .IP نکته: به ندرت پیش می‌آید که به چیزی جز '' (برای اجبار به اتصال بدون رمزگذاری) یا 'auto' (برای اجبار به TLS) نیاز داشته باشید. .TP .B \-\-sslcertck (کلمه کلیدی: sslcertck، پیش‌فرض فعال از نسخه 6.4.0) .br .B گزینه \-\-sslcertck باعث می‌شود fetchmail استفاده از SSL/TLS را الزامی بداند و در صورتی که نتواند با موفقیت SSL یا TLS را مذاکره کند، یا نتواند گواهی را با موفقیت بررسی و اعتبارسنجی کرده و زنجیره آن را تا یک لنگر اعتماد (یا گواهی ریشه معتمد) دنبال کند، اتصال را قطع کند. لنگرهای اعتماد به صورت مجموعه‌ای از گواهی‌های معتمد محلی داده می‌شوند (گزینه‌های \fBsslcertfile\fP و \fBsslcertpath\fP را ببینید). اگر گواهی سرور قابل دریافت نباشد یا توسط یکی از گواهی‌های معتمد (مستقیم یا غیرمستقیم) امضا نشده باشد، بدون در نظر گرفتن گزینه \fBsslfingerprint\fP، برنامه fetchmail اتصال را قطع خواهد کرد. .TP .B \-\-nosslcertck (کلمه کلیدی: no sslcertck، فقط در نسخه 6.4.X) .br برعکس \-\-sslcertck، این یک گزینه غیرتوصیه‌شده است. این گزینه به fetchmail اجازه می‌دهد حتی در صورت شکست بررسی‌های اعتبارسنجی گواهی سرور، به اتصال ادامه دهد. فقط باید همراه با \-\-sslfingerprint استفاده شود. .TP .B \-\-sslcertfile (کلمه کلیدی: sslcertfile، از نسخه 6.3.17) .br فایلی را تنظیم می‌کند که fetchmail برای جستجوی گواهی‌های محلی استفاده می‌کند. حالت پیش‌فرض خالی است. این گزینه می‌تواند علاوه بر \fB\-\-sslcertpath\fP در زیر مشخص شود، و گواهی‌های مشخص‌شده در \fB\-\-sslcertfile\fP قبل از موارد موجود در \fB\-\-sslcertpath\fP پردازش خواهند شد. این گزینه می‌تواند علاوه بر \fB\-\-sslcertpath\fP استفاده شود. .IP این فایل یک فایل متنی است. این فایل شامل ادغام گواهی‌های CA معتمد با فرمت PEM است. .IP توجه داشته باشید که استفاده از این گزینه مانع از بارگذاری فایل گواهی‌های پیش‌فرض CA معتمد SSL می‌شود، مگر اینکه متغیر محیطی \fBFETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS\fP را با مقداری غیرخالی مقداردهی کنید. .TP .B \-\-sslcertpath (کلمه کلیدی: sslcertpath) .br پوشه‌ای را تنظیم می‌کند که fetchmail برای جستجوی گواهی‌های محلی از آن استفاده می‌کند. مقدار پیش‌فرض، پوشه پیش‌فرض OpenSSL شماست. پوشه باید به روشی که OpenSSL انتظار دارد هش‌بندی شده باشد - هر بار که گواهی‌ای را در پوشه اضافه یا اصلاح می‌کنید، باید از ابزار \fBc_rehash\fP (که همراه با OpenSSL در زیرپوشه tools/ ارائه می‌شود) استفاده کنید. همچنین پس از ارتقای OpenSSL، ممکن است نیاز به اجرای \fBc_rehash\fP داشته باشید. .IP این گزینه می‌تواند علاوه بر \fB\-\-sslcertfile\fP در بالا مشخص شود، که قوانین اولویت را در آن ببینید. .IP توجه داشته باشید که استفاده از این گزینه مانع از اضافه شدن پوشه پیش‌فرض گواهی‌های CA معتمد SSL می‌شود، مگر اینکه متغیر محیطی \fBFETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS\fP را با مقداری غیرخالی مقداردهی کنید. .TP .B \-\-sslcommonname (کلمه کلیدی: sslcommonname؛ از نسخه 6.3.9) .br استفاده از این گزینه توصیه نمی‌شود. قبل از استفاده از آن، با مدیر سرور بالادستی خود تماس بگیرید و درخواست کنید تا یک گواهی مناسب SSL مورد استفاده قرار گیرد. اگر دستیابی به آن ممکن نباشد، این گزینه می‌تواند برای تعیین نامی (CommonName) استفاده شود که fetchmail انتظار دارد در گواهی سرور وجود داشته باشد. سروری که به درستی پیکربندی شده باشد این نام را روی نام میزبانی که از طریق آن در دسترس است تنظیم می‌کند، و fetchmail نیز به طور پیش‌فرض همین انتظار را دارد. از این گزینه هنگامی استفاده کنید که CommonName روی مقدار دیگری تنظیم شده باشد تا از هشدار "Server CommonName mismatch" جلوگیری شود، و فقط در صورتی که نتوان مدیر سرور بالادستی را به استفاده از گواهی‌های مناسب ترغیب کرد. .TP .B \-\-sslfingerprint [{}] (کلمه کلیدی: sslfingerprint) .br اثرانگشت (fingerprint) کلید سرور را به صورت نماد هگزادسیمال همراه با دو نقطه جداکننده گروه‌های دو رقمی مشخص می‌کند. این فرمتی است که fetchmail هنگام برقراری اتصال SSL برای گزارش اثرانگشت استفاده می‌کند. هنگامی که این گزینه مشخص شود، fetchmail اثرانگشت کلید سرور را با اثرانگشت ارائه‌شده مقایسه می‌کند و در صورت عدم تطابق، بدون در نظر گرفتن تنظیمات \fBsslcertck\fP، اتصال با شکست مواجه خواهد شد. اتصال همچنین در صورتی که fetchmail نتواند گواهی SSL را از سرور دریافت کند ناموفق خواهد بود. این قابلیت می‌تواند برای جلوگیری از حملات مرد میانی (MITM) استفاده شود، اما اثرانگشت سرور باید از طریق یک کانال امن دریافت یا تأیید شود، و مسلماً نه از طریق همان اتصال اینترنتی که fetchmail استفاده می‌کند. .IP اثرانگشت می‌تواند با نام الگوریتم خلاصه پیام EVP_MD داخل آکولاد پیشوندگذاری شود، برای نمونه: {MD5}00:01:...:0F. تمامی الگوریتم‌های خلاصه‌سازی که کتابخانه ارائه‌دهنده SSL شما پشتیبانی می‌کند قابل استفاده هستند. یک الگوریتم معقول مانند SHA256 را انتخاب کنید. اگر پیشوند {algo} حذف شود، از MD5 برای سازگاری با fetchmail نسخه 6.4 و قدیمی‌تر استفاده می‌شود. .IP استفاده از این گزینه تا زمانی که \-\-nosslcertck فعال باشد، از چاپ خطاهای اعتبارسنجی گواهی جلوگیری می‌کند. .IP اگر فقط می‌خواهید خروجی لاگ --verbose را تغییر دهید تا به یک هش متفاوت منتقل شود، بدون اینکه هش گواهی سرور پین شود، می‌توانید از \-\-sslfingerprint '{algo}*' استفاده کنید، به عنوان مثال: \-\-sslfingerprint '{SHA256}*' .IP برای به دست آوردن اثرانگشت گواهی ذخیره‌شده در فایل cert.pem، دستور زیر را امتحان کنید: .sp .nf openssl x509 \-in cert.pem \-noout \-sha256 \-fingerprint .fi .sp برای جزئیات بیشتر، .BR x509 (1ssl) را ببینید. .SS "گزینه‌های کنترل تحویل (Delivery Control Options)" .TP .B \-S | \-\-smtphost (کلمه کلیدی: smtp[host]) .br (از نسخه 6.6.0 به بعد، fetchmail از TLS و STARTTLS برای میزبان‌های SMTP پشتیبانی می‌کند) .br (از نسخه 6.5.6 به بعد، fetchmail چگونگی تولید لیترال‌های آدرس IP بر اساس RFC-5321 را از یک رشته آدرس عددی خام IPv4 یا IPv6 می‌داند) .IP فهرستی از میزبان‌ها (hunt list) را برای فوروارد نامه‌ها مشخص می‌کند (یک یا چند نام میزبان، جداشده با کاما). میزبان‌ها به ترتیب فهرست آزمایش می‌شوند؛ نخستین میزبانی که در دسترس باشد، به عنوان مقصد فوروارد برای اجرای جاری انتخاب می‌شود. اگر این گزینه مشخص نشود، 'localhost' به عنوان پیش‌فرض استفاده می‌شود. هر نام میزبان می‌تواند دارای شماره پورت بعد از نام میزبان باشد. شماره پورت با یک اسلش از نام میزبان جدا می‌شود؛ پورت پیش‌فرض "smtp" است. اگر یک مسیر مطلق را مشخص کنید (که با / شروع شود)، به عنوان نام یک سوکت یونیکس تفسیر می‌شود که اتصالات LMTP را می‌پذیرد (مانند آنچه توسط دیمن Cyrus IMAP پشتیبانی می‌شود). .br مثال: .EX --smtphost server1,server2/2525,server3,/var/imap/socket/lmtp .EE این گزینه می‌تواند همراه با ODMR استفاده شود و fetchmail را به یک بازپخش‌کننده (relay) میان سرور ODMR و گیرنده SMTP یا LMTP تبدیل خواهد کرد. .IP هر نام میزبان برای سرورهای SMTP تا چهار گزینه را که با اسلش (/) جدا شده‌اند پشتیبانی می‌کند: .RS .IP "/25 or /587 or /smtp or /465 or /smtps" عدد ۲۵ یا هر عدد دیگری بین ۱ تا ۶۵۵۳۵ شماره پورت را برای اتصال مشخص می‌کند؛ smtp یا هر نام سرویس دیگری که سیستم بتواند آن را تفکیک کند (پیکربندی‌های ساده می‌توانند از /etc/services استفاده کنند)؛ در صورت عدم تعیین، fetchmail از شماره پورت‌های پیش‌فرض همان‌گونه که در زیر آمده استفاده خواهد کرد. .P یکی از موارد: .RS .IP /notls قابلیت STARTTLS فرصت‌طلبانه (opportunistic) را حتی در صورت پیشنهاد شدن توسط سرور غیرفعال می‌کند. این مورد در صورتی که نام میزبان دقیقاً .B localhost باشد، به صورت ضمنی اعمال می‌شود. .IP /starttls الزام می‌کند که سرور STARTTLS را در پاسخ Extended Hello (EHLO) پیشنهاد دهد و نیازمند آن است که گواهی سرور همانند زمانی که \-\-sslcertck تنظیم شده است، اعتبارسنجی شود. پورت پیش‌فرض ۲۵ خواهد بود. .IP /tls بسته‌بندی TLS را پیش از تبادل پیام خوش‌آمدگویی مذاکره می‌کند و نیازمند آن است که گواهی سرور همانند زمانی که \-\-sslcertck تنظیم شده است، اعتبارسنجی شود. پورت پیش‌فرض ۴۶۵ خواهد بود. .RE .IP "هیچ‌کدام از /notls، /tls، /starttls:" ارتباط TLS فرصت‌طلبانه (به‌جز برای localhost، بالا را ببینید). تلاش خواهد کرد تا در صورت ارائه توسط سرور، برای STARTTLS مذاکره کند، اما بر اعتبارسنجی گواهی پافشاری نخواهد کرد، مانند رفتاری که با \-\-nosslcertck انجام می‌شود. .IP /tlsproto=PROTO رفتاری مشابه با زمانی دارد که \-\-sslproto PROTO داده شده باشد (به آن مراجعه کنید). اگر /notls فعال باشد، نادیده گرفته می‌شود. .IP /servername=NAME نام گواهی X.509 مورد انتظار را به NAME تغییر می‌دهد و در صورتی که سرویس SMTP بر اساس نام سرور مالتی‌پلکس شود، آن را از طریق Server Name Indication (SNI) ارسال می‌کند. اگر /notls فعال باشد، نادیده گرفته می‌شود. .RE .IP نکته ۱: هر متنی که صراحتاً شناخته نشود به عنوان یک نام سرویس در نظر گرفته خواهد شد؛ خطاهای نگارشی مانند گزینه‌های اشتباه‌تایپ‌شده می‌توانند به شکل خطاهای گیج‌کننده ()getaddrinfo برای تفکیک یک سرویس ظاهر شوند، به عنوان نمونه: 'Servname not supported for ai_socktype'. .IP نکته ۲: هنگامی که گزینه‌های متناقض داده شوند، آخرین گزینه تعیین‌شده برتری دارد. .IP مثال: .EX --smtphost dnsname.example.org/25/starttls/tlsproto=tls1.3/servername=commonname.example.com .EE نام dnsname.example.org را تفکیک می‌کند، روی پورت ۲۵ به آن متصل می‌شود، تلاش می‌کند تا دستور STARTTLS را ارسال کرده و به TLS v1.3 ارتقا یابد و انتظار دارد که گواهی X.509 سرور با نام commonname.example.com مطابقت داشته باشد. .IP هشدار برای نسخه‌های 6.5.5 و قبل‌تر: اگر از آدرس‌های IP عددی در اینجا استفاده می‌کنید، حتماً از \-\-smtpaddress یا \-\-smtpname (به هر کدام که مراجعه کنید) همراه با یک لیترال آدرس SMTP معتبر استفاده نمایید! .TP .B \-\-esmtpname (از نسخه 6.5.7؛ کلمه کلیدی: esmtpname، از نسخه 5.9.9) شناسه احراز هویت (authorization ID) را برای SMTP AUTH جهت ورود به سرور SMTP تنظیم می‌کند. پیش‌فرض آن برداشت fetchmail از کاربر اجراکننده است که از نخستین متغیر محیطی تعریف‌شده میان FETCHMAILUSER، LOGNAME و USER گرفته می‌شود. (در حال حاضر در خروجی \-\-help فهرست نشده است) .IP نکته: این مورد به ازای هر "poll" است و برای تمام سرورهای فهرست‌شده در فهرست smtphost شما یکسان خواهد بود! .IP نکته: در حال حاضر fetchmail الزام نمی‌کند که اتصال حتماً از طریق رابط loopback یا لایه رمزگذاری‌شده امن TLS برقرار شود - اگر سرور SMTP لوکال‌هاست شما نیست، حتماً TLS یا STARTTLS را روی آن اجباری کنید. .TP .B \-\-esmtppassword (از نسخه 6.5.7؛ کلمه کلیدی: esmtppassword، از نسخه 5.9.9) رمز عبور/راز را برای SMTP AUTH جهت ورود به سرور SMTP تعیین می‌کند. (در حال حاضر در خروجی \-\-help فهرست نشده است) .IP نکته ۱: به‌جای فایل rcfile نرم‌افزار fetchmail، می‌توانید رمز عبور را در فایل netrc. قرار دهید. خط ورود (login) فایل netrc. باید با esmtpname مطابقت داشته باشد (به آن مراجعه کنید). .IP نکته ۲: این مورد به ازای هر "poll" است و برای تمام سرورهای فهرست‌شده در فهرست smtphost شما یکسان خواهد بود! رمز عبور از نخستین smtphost یا گزینه /servername= آن در فهرست که دارای یک مدخل netrc. باشد گرفته خواهد شد. .IP نکته ۳: در حال حاضر fetchmail الزام نمی‌کند که اتصال حتماً از طریق رابط loopback یا لایه رمزگذاری‌شده امن TLS برقرار شود - اگر سرور SMTP لوکال‌هاست شما نیست، حتماً TLS یا STARTTLS را روی آن اجباری کنید. .TP .B \-\-fetchdomains (کلمه کلیدی: fetchdomains) .br در حالت ETRN یا ODMR، این گزینه فهرستی از دامنه‌هایی را مشخص می‌کند که سرور باید پس از برقراری اتصال دوطرفه، نامه‌های مربوط به آن‌ها را ارسال کند. پیش‌فرض، FQDN ماشینی است که \fBfetchmail\fP را اجرا می‌کند. .TP .B \-D | \-\-smtpaddress (کلمه کلیدی: smtpaddress) .br دامنه‌ای را مشخص می‌کند که باید به آدرس‌های موجود در خطوط RCPT TO ارسالی به SMTP افزوده شود. در صورت عدم تعیین، نام سرور SMTP (همان‌طور که با \-\-smtphost مشخص شده است) برای SMTP/LMTP و 'localhost' برای سوکت یونیکس/BSMTP استفاده می‌شود. .IP نکته: اگر قصد دارید از آدرس‌های عددی با fetchmail نسخه 6.5.5 یا قدیمی‌تر استفاده کنید، یا از به‌اصطلاح لیترال‌های آدرس طبق استاندارد SMTP، آن‌ها را با ساختار نحوی مناسب SMTP بنویسید، برای نمونه \-\-smtpaddress "[192.0.2.6]" یا \-\-smtpaddress "[IPv6:2001:DB8::6]". .TP .B \-\-smtpname (کلمه کلیدی: smtpname) .br کاربر و دامنه‌ای را که باید در خطوط RCPT TO ارسالی به SMTP قرار گیرند، مشخص می‌کند. کاربر پیش‌فرض، کاربر محلی جاری است. لطفاً به نکته بالا درباره \-\-smtpaddress و لیترال‌های آدرس نیز مراجعه کنید. .TP .B \-Z | \-\-antispam (کلمه کلیدی: antispam) .br فهرستی از خطاهای عددی SMTP را مشخص می‌کند که باید به عنوان پاسخ مسدودسازی هرزنامه از سوی شنونده تفسیر شوند. مقدار 1\- این گزینه را غیرفعال می‌کند. برای گزینه خط فرمان، مقادیر فهرست باید با کاما جدا شوند. توجه داشته باشید که مقادیر antispam تنها برای پاسخ‌های "MAIL FROM" در گفتگوی SMTP/LMTP اعمال می‌شوند، اما چندین MTA (مانند Postfix در پیکربندی پیش‌فرض خود، qmail) کد پاسخ ضد هرزنامه را تا پس از RCPT TO به تعویق می‌اندازند. \-\-antispam در این شرایط کار نمی‌کند. همچنین به \-\-softbounce (پیش‌فرض) و معکوس آن مراجعه کنید. .TP .B \-m | \-\-mda (کلمه کلیدی: mda) .br این گزینه به \fBfetchmail\fP اجازه می‌دهد مستقیماً از یک عامل تحویل پیام یا محلی (MDA یا LDA) استفاده کند، به‌جای اینکه نامه‌ها را از طریق SMTP یا LMTP فوروارد کند. .IP برای جلوگیری از گم شدن نامه‌ها، از این گزینه تنها با MDAهایی مانند maildrop یا MTAهایی مانند sendmail استفاده کنید که در صورت پر بودن دیسک و سایر خطاهای تحویل، با وضعیت غیر صفر خارج می‌شوند؛ این وضعیت غیر صفر به fetchmail اطلاع می‌دهد که تحویل با شکست مواجه شده است و از حذف پیام روی سرور جلوگیری می‌کند. .IP اگر \fBfetchmail\fP با دسترسی ریشه (root) اجرا شود، شناسه کاربری خود را هنگام تحویل نامه از طریق یک MDA به صورت زیر تنظیم می‌کند: ابتدا متغیرهای محیطی FETCHMAILUSER، LOGNAME و USER به همین ترتیب بررسی می‌شوند. مقدار نخستین متغیر تعریف‌شده در این فهرست (حتی اگر خالی باشد!) در پایگاه‌داده کاربران سیستم جستجو می‌شود. اگر هیچ‌یک از این متغیرها تعریف نشده باشد، fetchmail از شناسه کاربری واقعی که با آن شروع به کار کرده است استفاده خواهد کرد. اگر یکی از متغیرها تعریف شده بود اما کاربر ذکرشده در آن یافت نشد، fetchmail اجرای خود را با دسترسی ریشه و بدون بررسی بقیه متغیرهای موجود در فهرست ادامه می‌دهد. در عمل، این بدان معناست که اگر fetchmail را به عنوان ریشه اجرا می‌کنید (که توصیه نمی‌شود)، مفیدترین کار تعریف متغیر محیطی FETCHMAILUSER است تا کاربری را که MDA باید تحت آن اجرا شود تعیین کنید. برخی MDAها (مانند maildrop) به گونه‌ای طراحی شده‌اند که setuid root باشند و به شناسه کاربری گیرنده setuid کنند، بنابراین حتی با اجرای fetchmail به عنوان کاربر غیرممتاز نیز این کارایی را از دست نمی‌دهید. برای جزئیات به راهنمای MDA مراجعه کنید. برخی MDAهای ممکن عبارتند از "/usr/sbin/sendmail \-i \-f %F \-\- %T" (\fBنکته:\fP برخی نسخه‌های قدیمی‌تر یا ارائه‌شده توسط توزیع‌کنندگان sendmail به اشتباه \-\- را به عنوان یک آدرس در نظر می‌گیرند، نه به عنوان نشانه‌ای برای پایان آرگومان‌های گزینه‌ها)، "/usr/bin/deliver" و "/usr/bin/maildrop \-d %T". آدرس‌های تحویل محلی در هر کجای دستور MDA که %T قرار دهید درج می‌شوند؛ آدرس فرستنده (From) پیام نیز در جایی که %F قرار دهید درج خواهد شد. \fBرشته‌های %F یا %T را داخل کوتیشن تکی (Single Quote) قرار ندهید!\fP برای هر دو مورد %T و %F، برنامه fetchmail آدرس‌ها را پس از حذف هرگونه کوتیشن تکی موجود در آن‌ها، داخل کوتیشن تکی (') محصور می‌کند و سپس دستور MDA به شل ارسال می‌شود. \fBهرگز از فراخوانی MDA که بر اساس محتوای To/Cc/Bcc تصمیم‌گیری می‌کند استفاده نکنید،\fP مانند "sendmail \-i \-t" یا "qmail-inject"، زیرا باعث ایجاد حلقه‌های نامه (mail loops) شده و خشم به‌حق بسیاری از مدیران پست را متوجه شما خواهد کرد. این یکی از شایع‌ترین خطاهای پیکربندی است! همچنین، \fIهرگز\fP سعی نکنید حالت multidrop را با یک MDA مانند maildrop که تنها یک آدرس را می‌پذیرد ترکیب کنید، مگر اینکه سرور بالادست شما یک نسخه از پیام را به ازای هر گیرنده ذخیره کند و گیرنده پاکت نامه (envelope recipient) را در یک هدر انتقال دهد؛ در غیر این صورت نامه‌های خود را از دست خواهید داد. بسته نرم‌افزاری شناخته‌شده .BR procmail (1) پیکربندی بسیار دشواری دارد و در صورت بروز خطاهای تحویل (حتی خطاهای موقت مانند کمبود فضای دیسک در صورتی که دیمن نامه کاربر دیگری میل‌باکس را برای پاکسازی پیام‌های قدیمی جابه‌جا کند) رفتار بسیار زننده «رد شدن و رفتن به قاعده بعدی» را از خود نشان می‌دهد، بنابراین نامه‌های شما دیر یا زود سر از میل‌باکس اشتباهی درمی‌آورند. پیکربندی صحیح procmail خارج از محدوده این سند است. استفاده از .BR maildrop (1) معمولاً بسیار آسان‌تر است و بسیاری از کاربران ساختار فیلترهای مورداستفاده در maildrop را ساده‌تر و قابل‌فهم‌تر می‌دانند. در نهایت، اکیداً توصیه می‌کنیم که از qmail-inject استفاده \fBنکنید\fP. رابط خط فرمان آن غیراستاندارد است بدون اینکه مزیتی برای کاربردهای معمول فراهم کند، و fetchmail هیچ تلاشی برای انطباق با انحرافات qmail-inject از استانداردهای معمول انجام نمی‌دهد. برخی از گزینه‌های خط فرمان و محیطی qmail-inject در واقع خطرناک هستند و می‌توانند باعث شکستن زنجیره گفتگوها (broken threads)، عدم شناسایی پیام‌های تکراری و ایجاد حلقه‌های فوروارد شوند. .TP .B \-\-lmtp (کلمه کلیدی: lmtp) .br موجب تحویل از طریق LMTP (پروتکل انتقال محلی نامه) می‌شود. در صورت انتخاب این گزینه، میزبان سرویس و پورت \fBباید\fP صراحتاً روی هر میزبان در فهرست smtphost (بالا را ببینید) مشخص شوند؛ پورت پیش‌فرض ۲۵ (مطابق با RFC 2033) پذیرفته نخواهد شد. .TP .B \-\-bsmtp (کلمه کلیدی: bsmtp) .br نامه‌های دریافت شده را به یک فایل BSMTP الحاق می‌کند. این فایل صرفاً شامل دستورات SMTP است که معمولاً هنگام ارسال نامه به یک دیمن شنونده SMTP توسط fetchmail تولید می‌شوند. آرگومان '\-' باعث می‌شود بسته BSMTP در خروجی استاندارد نوشته شود که کاربرد محدودی دارد: این حالت تنها برای اشکال‌زدایی منطقی است، زیرا خروجی عادی fetchmail روی همان کانال با آن ترکیب می‌شود و در نتیجه برای تحویل واقعی نامه مناسب نیست. این حالت ویژه ممکن است در نسخه‌های بعدی حذف شود. توجه داشته باشید که بازسازی خطوط MAIL FROM و RCPT TO توسط fetchmail لزوماً بدون نقص نیست؛ هشدارهایی که در بخش «استفاده و سوءاستفاده از صندوق‌های چندمقصده» (THE USE AND ABUSE OF MULTIDROP MAILBOXES) در ادامه بررسی شده‌اند در اینجا نیز صدق می‌کنند. این حالت نسبت به \-\-mda و SMTP/LMTP اولویت دارد. .TP .B \-\-bad\-header {reject|accept} (کلمه کلیدی: bad\-header؛ از نسخه 6.3.15) .br تعیین می‌کند که fetchmail چگونه باید با پیام‌های دارای هدرهای نادرست (یعنی هدرهایی با ساختار نحوی نامعتبر) رفتار کند. از گذشته، fetchmail چنین پیام‌هایی را رد می‌کرد، اما برخی توزیع‌کنندگان fetchmail را تغییر دادند تا آن‌ها را بپذیرد. اکنون می‌توانید رفتار fetchmail را به ازای هر سرور پیکربندی کنید. .SS "گزینه‌های کنترل محدودیت منابع (Resource Limit Control Options)" .TP .B \-l | \-\-limit (کلمه کلیدی: limit) .br یک آرگومان حداکثر اندازه بر حسب بایت (octet) می‌گیرد که در آن ۰ مقدار پیش‌فرض و همچنین مقدار ویژه به معنای «بدون محدودیت» است. در صورت غیر صفر بودن، پیام‌های بزرگتر از این اندازه واکشی نخواهند شد و روی سرور باقی می‌مانند (در نشست‌های پیش‌زمینه، پیام‌های پیشرفت وضعیت اشاره می‌کنند که پیام‌ها "oversized" یا بیش از حد بزرگ هستند). اگر پروتکل واکشی اجازه دهد (به‌ویژه در IMAP یا POP3 بدون گزینه fetchall)، پیام به عنوان دیده‌شده علامت‌گذاری نخواهد شد. .sp مقدار صریح ۰ برای \-\-limit هرگونه محدودیت تنظیم‌شده در فایل کنترل اجرای شما را لغو می‌کند. این گزینه برای کسانی در نظر گرفته شده است که به دلیل هزینه‌های متغیر و گران تماس‌های تلفنی نیاز دارند زمان واکشی را به دقت کنترل کنند. .sp در ترکیب با \-\-limitflush، می‌توان از آن برای حذف پیام‌های بسیار بزرگی که روی سرور منتظر مانده‌اند استفاده کرد. در حالت دیمن، اعلان‌های مربوط به پیام‌های بیش از حد بزرگ برای کاربر فراخواننده ایمیل می‌شود (به گزینه \-\-warnings مراجعه کنید). این گزینه همراه با ETRN یا ODMR کار نمی‌کند. .TP .B \-w | \-\-warnings (کلمه کلیدی: warnings) .br یک بازه زمانی بر حسب ثانیه می‌گیرد. هنگامی که \fBfetchmail\fP را با گزینه 'limit' در حالت دیمن اجرا می‌کنید، این گزینه بازه زمانی ارسال هشدارهای مربوط به پیام‌های بیش از حد بزرگ به کاربر فراخواننده (یا کاربر مشخص‌شده توسط گزینه 'postmaster') را کنترل می‌کند. یک اعلان از این دست همیشه در پایان نخستین بررسی (poll) که در آن پیام بسیار بزرگ شناسایی شود ارسال می‌گردد. پس از آن، ارسال مجدد اعلان تا زمان سپری شدن بازه هشدار متوقف می‌شود (و در پایان نخستین بررسی پس از آن انجام خواهد شد). .TP .B \-b | \-\-batchlimit (کلمه کلیدی: batchlimit) .br حداکثر تعداد پیام‌هایی را که پیش از قطع عمدی اتصال و بازسازی مجدد آن به یک شنونده SMTP ارسال می‌شوند، مشخص می‌کند (پیش‌فرض ۰ است که به معنای بدون محدودیت می‌باشد). تعیین صریح مقدار ۰ برای \-\-batchlimit هرگونه محدودیت تنظیم‌شده در فایل کنترل اجرای شما را لغو می‌کند. در حالی که \fBsendmail\fP(8) معمولاً بلافاصله پس از دریافت پایان‌دهنده پیام، فرآیند تحویل را آغاز می‌کند، برخی شنوندگان SMTP چندان سریع نیستند. MTAهایی مانند \fBsmail\fP(8) ممکن است تا زمان بسته شدن سوکت تحویل برای تحویل دادن نامه‌ها منتظر بمانند. این موضوع ممکن است هنگام پردازش دسته‌های بسیار بزرگ توسط \fBfetchmail\fP تاخیرهای آزاردهنده‌ای ایجاد کند. تنظیم محدودیت دسته روی یک مقدار غیر صفر از این تاخیرها جلوگیری خواهد کرد. این گزینه همراه با ETRN یا ODMR کار نمی‌کند. .TP .B \-B | \-\-fetchlimit (کلمه کلیدی: fetchlimit) .br تعداد پیام‌های پذیرفته‌شده از یک سرور مشخص را در یک بار بررسی محدود می‌کند. به صورت پیش‌فرض محدودیتی وجود ندارد. تعیین صریح مقدار ۰ برای \-\-fetchlimit هرگونه محدودیت تنظیم‌شده در فایل کنترل اجرای شما را لغو می‌کند. این گزینه همراه با ETRN یا ODMR کار نمی‌کند. .TP .B \-\-fetchsizelimit (کلمه کلیدی: fetchsizelimit) .br تعداد اندازه‌های پیام‌های پذیرفته‌شده از یک سرور مشخص را در یک تراکنش محدود می‌کند. این گزینه برای کاهش تاخیر در دانلود نخستین نامه در زمانی که نامه‌های زیادی در صندوق پستی وجود دارد مفید است. به صورت پیش‌فرض، این محدودیت ۱۰۰ است. اگر روی ۰ تنظیم شود، اندازه‌های تمام پیام‌ها در ابتدا دانلود می‌شوند. این گزینه همراه با ETRN یا ODMR کار نمی‌کند. برای POP3، تنها مقدار غیر صفر معتبر ۱ است. .TP .B \-\-fastuidl (کلمه کلیدی: fastuidl) .br به‌جای جستجوی خطی، یک جستجوی دودویی برای یافتن نخستین UID دیده‌نشده انجام می‌دهد. جستجوی دودویی از دانلود UIDهای تمام نامه‌ها جلوگیری می‌کند. این کار در زمان صرفه‌جویی می‌کند (به‌ویژه در حالت دیمن) که در آن دانلود مجموعه یکسانی از UIDها در هر بررسی هدر دادن پهنای باند است. عدد 'n' نشان می‌دهد که جستجوی خطی هر چند وقت یک‌بار باید انجام شود. در حالت دیمن، در صورتی که 'n' بزرگتر از ۱ باشد، جستجوی خطی یک بار انجام شده و سپس در 'n-1' بار بررسی بعدی از جستجوی دودویی استفاده می‌شود؛ اگر 'n' برابر با ۱ باشد همواره از جستجوی دودویی استفاده می‌شود؛ اگر 'n' برابر با ۰ باشد همواره از جستجوی خطی استفاده می‌شود. در حالت غیر دیمن، اگر 'n' برابر با ۱ باشد از جستجوی دودویی استفاده می‌شود؛ در غیر این صورت جستجوی خطی به کار می‌رود. مقدار پیش‌فرض 'n' برابر با ۴ است. این گزینه تنها با POP3 کار می‌کند. .TP .B \-e | \-\-expunge (کلمه کلیدی: expunge) .br ترتیبی می‌دهد که حذف نامه‌ها پس از تعداد معینی پیام نهایی شود. تحت POP2 یا POP3، برنامه fetchmail نمی‌تواند بدون ارسال QUIT و پایان دادن به نشست، حذف‌ها را نهایی کند -- با فعال بودن این گزینه، fetchmail یک نشست طولانی بازیابی نامه را به چندین زیرنشست تقسیم می‌کند و پس از هر زیرنشست QUIT می‌فرستد. این روش دفاع خوبی در برابر قطع خط در سرورهای POP3 است. تحت IMAP، برنامه \fBfetchmail\fP معمولاً پس از هر حذف یک دستور EXPUNGE صادر می‌کند تا حذف فوراً انجام شود. این کار زمانی که اتصال شما به سرور ناپایدار و پرهزینه باشد ایمن‌ترین راه است، زیرا از ارسال مجدد نامه‌های تکراری پس از قطع اتصال جلوگیری می‌کند. با این حال، در صندوق‌های پستی بزرگ، بار ناشی از نمایه‌سازی مجدد (re-indexing) پس از هر پیام می‌تواند فشار زیادی به سرور وارد کند، بنابراین اگر اتصال شما قابل اعتماد است، بهتر است دستورات expunge با دفعات کمتری اجرا شوند. همچنین توجه داشته باشید که برخی سرورها پس از هر خروج تاخیری چند ثانیه‌ای اعمال می‌کنند، بنابراین fetchmail ممکن است نتواند بلافاصله پس از یک expunge دوباره وارد شود -- در صورت وقوع ممکن است خطاهای "lock busy" را مشاهده کنید. اگر این گزینه را روی یک عدد صحیح N تنظیم کنید، به \fBfetchmail\fP می‌گوید که تنها به ازای هر Nمین حذف، دستور expunge صادر کند. آرگومان صفر دستورات expunge را کاملاً متوقف می‌کند (بنابراین تا پایان اجرا هیچ expungeای انجام نخواهد شد). این گزینه همراه با ETRN یا ODMR کار نمی‌کند. .SS "گزینه‌های احراز هویت (Authentication Options)" .TP .B \-u | \-\-user | \-\-username (کلمه کلیدی: user[name]) .br شناسه کاربری مورد استفاده هنگام ورود به سرور نامه را مشخص می‌کند. شناسه کاربری مناسب هم به سرور و هم به کاربر بستگی دارد. پیش‌فرض، نام کاربری شما در ماشین کلاینتی است که \fBfetchmail\fP را اجرا می‌کند. برای شرح کامل به بخش «احراز هویت کاربر» (USER AUTHENTICATION) در ادامه مراجعه کنید. .TP .B \-I | \-\-interface (کلمه کلیدی: interface) .br الزام می‌کند که پیش از شروع بررسی، یک دستگاه رابط (interface) خاص بالا باشد و یک آدرس (یا محدوده آدرس) محلی یا راه دور IPv4 مشخص داشته باشد (IPv6 هنوز توسط این گزینه پشتیبانی نمی‌شود). غالباً \fBfetchmail\fP روی یک پیوند گذرا و نظیر‌به‌نظیر TCP/IP که مستقیماً از طریق SLIP یا PPP به یک سرور نامه برقرار شده است استفاده می‌شود. این یک کانال نسبتاً امن است. اما هنگامی که مسیرهای TCP/IP دیگری به سرور نامه وجود داشته باشد (برای نمونه زمانی که پیوند به یک ISP جایگزین متصل است)، ممکن است نام کاربری و رمز عبور شما در برابر شنود آسیب‌پذیر باشد (به‌ویژه هنگامی که حالت دیمن به صورت خودکار برای دریافت نامه‌ها جستجو می‌کند و رمز عبور واضح و رمزنشده را در فواصل زمانی قابل پیش‌بینی روی شبکه ارسال می‌نماید). گزینه \-\-interface می‌تواند برای جلوگیری از این مشکل استفاده شود. هنگامی که پیوند مشخص‌شده بالا نباشد یا به یک آدرس IP منطبق متصل نباشد، مرحله بررسی انجام نخواهد شد. ساختار به این صورت است: .sp .nf interface/iii.iii.iii.iii[/mmm.mmm.mmm.mmm] .fi .sp فیلد قبل از نخستین اسلش نام رابط است (مانند sl0، ppp0 و غیره). فیلد قبل از اسلش دوم آدرس IP قابل قبول است. فیلد بعد از اسلش دوم یک ماسک است که محدوده‌ای از آدرس‌های IP مورد قبول را مشخص می‌کند. اگر ماسکی وجود نداشته باشد، 255.255.255.255 فرض می‌شود (یعنی تطابق دقیق). این گزینه در حال حاضر تنها تحت لینوکس و FreeBSD پشتیبانی می‌شود. لطفاً برای اطلاعات ویژه FreeBSD به بخش \fBmonitor\fP در زیر مراجعه کنید. .sp توجه داشته باشید که ممکن است این گزینه در نسخه‌های آینده fetchmail حذف شود. .TP .B \-M | \-\-monitor (کلمه کلیدی: monitor) .br حالت دیمن می‌تواند باعث شود پیوندهای گذرایی که پس از یک دوره عدم فعالیت به طور خودکار قطع می‌شوند (مانند پیوندهای PPP)، به طور نامحدود بالا و متصل بمانند. این گزینه یک رابط TCP/IP سیستمی را برای پایش فعالیت مشخص می‌کند. پس از هر بازه بررسی، اگر پیوند برقرار باشد اما هیچ فعالیت دیگری روی آن رخ نداده باشد، آن بررسی نادیده گرفته خواهد شد. با این حال، هنگامی که fetchmail با یک سیگنال بیدار می‌شود، بررسی مانیتور نادیده گرفته شده و عملیات واکشی بدون قید و شرط انجام می‌شود. این گزینه در حال حاضر تنها تحت لینوکس و FreeBSD پشتیبانی می‌شود. برای اینکه گزینه‌های \fBmonitor\fP و \fBinterface\fP برای کاربران غیر ریشه تحت FreeBSD کار کنند، باینری fetchmail باید به صورت setgid kmem نصب شده باشد. این کار می‌توانست یک حفره امنیتی باشد، اما fetchmail شناسه مؤثر GID خود را \fIتنها\fP زمانی روی گروه kmem تنظیم می‌کند که داده‌های رابط در حال جمع‌آوری باشند. .sp توجه داشته باشید که ممکن است این گزینه در نسخه‌های آینده fetchmail حذف شود. .TP .B \-\-auth (کلمه کلیدی: auth[enticate]) .br این گزینه به شما اجازه می‌دهد نوع احراز هویت را مشخص کنید (برای جزئیات به بخش «احراز هویت کاربر» (USER AUTHENTICATION) در زیر مراجعه کنید). مقادیر ممکن عبارتند از: \fBany\fP، \&\fBpassword\fP، \fBkerberos_v5\fP، \fBkerberos\fP (یا برای دقت فوق‌العاده بالا، \fBkerberos_v4\fP)، \fBgssapi\fP، \fBcram\-md5\fP، \fBotp\fP، \fBntlm\fP، \fBmsn\fP (تنها برای POP3)، \fBexternal\fP (تنها IMAP) و \fBimplicit\fP (\fBssh\fP به عنوان نام مستعار برای \fBimplicit\fP شناخته می‌شود). هنگامی که \fBany\fP (پیش‌فرض) مشخص شود، fetchmail ابتدا روش‌هایی را که نیازی به رمز عبور ندارند (EXTERNAL، GSSAPI، KERBEROS\ IV، KERBEROS\ 5) آزمایش می‌کند؛ سپس به دنبال روش‌هایی می‌گردد که رمز عبور شما را بپوشانند و ماسک کنند (CRAM-MD5، NTLM، X\-OTP - توجه داشته باشید که MSN تنها برای POP3 پشتیبانی می‌شود و به صورت خودکار شناسایی نمی‌شود)؛ و تنها در صورتی که سرور از هیچ‌یک از آن‌ها پشتیبانی نکند، رمز عبور شما را بدون رمزگذاری ارسال خواهد کرد. مقادیر دیگر را می‌توان برای اجبار به استفاده از روش‌های احراز هویت گوناگون به کار برد: \fBimplicit\fP احراز هویت را غیرفعال می‌کند و بنابراین برای IMAP PREAUTH مفید است (اگر از یک \-\-plugin امن استفاده می‌کنید، برای نمونه یک ssh به درستی پیکربندی‌شده، ممکن است لازم باشد \-\-sslproto\ '' یا در فایل rcfile گزینه sslproto\ '' را نیز تنظیم کنید تا از مذاکره STARTTLS توسط fetchmail روی بستر SSH جلوگیری شود). \fBexternal\fP احراز هویت را غیرفعال می‌کند و از این رو برای IMAP EXTERNAL کاربرد دارد. هر مقداری به جز \fBpassword\fP، \fBcram\-md5\fP، \fBntlm\fP، \&\fBmsn\fP یا \fBotp\fP درخواست عادی fetchmail برای دریافت رمز عبور را متوقف می‌کند. هنگامی که از یک اتصال امن سرتاسری مانند تونل ssh استفاده می‌کنید، \fBimplicit\fP را مشخص نمایید (در این حالت ممکن است بخواهید \&\fB\-\-sslproto\ ''\fP را نیز مشخص کنید که به آن اشاره شد)؛ هنگامی که از TLS با احراز هویت کلاینت استفاده می‌کنید، \fBexternal\fP را تعیین کنید و در صورتی که از نوعی پروتکل استفاده می‌کنید که GSSAPI یا K4 را به کار می‌برد، \fBgssapi\fP یا \&\fBkerberos_v4\fP را مشخص کنید. انتخاب پروتکل KPOP به صورت خودکار احراز هویت Kerberos را انتخاب می‌کند. این گزینه با ETRN کار نمی‌کند. نام‌های سرویس GSSAPI مطابق با RFC-2743 و ثبت‌های IANA هستند، پیوند زیر را ببینید: .UR https://www.iana.org/assignments/gssapi-service-names نام‌های سرویس رابط برنامه‌نویسی کاربردی سرویس‌های امنیتی عمومی (GSSAPI) / کربروس / لایه احراز هویت ساده و امنیت (SASL) .UE . .SS "گزینه‌های گوناگون (Miscellaneous Options)" .TP .B \-f | \-\-fetchmailrc نامی غیر از نام پیش‌فرض را برای فایل کنترل اجرای \fI~/.fetchmailrc\fP مشخص می‌کند. آرگومان pathname باید "-" (یک خط تیره تنها، به معنای خواندن پیکربندی از ورودی استاندارد) یا یک نام فایل باشد. مگر اینکه گزینه \-\-version نیز فعال باشد، یک فایل نام‌گذاری‌شده نباید مجوزی بازتر از 0700 (u=rwx,g=,o=) داشته باشد یا اینکه باید dev/null/ باشد. .TP .B \-i | \-\-idfile (کلمه کلیدی: idfile) .br یک نام جایگزین برای فایل fetchids. مشخص می‌کند که برای ذخیره UIDهای پیام‌ها استفاده می‌شود. نکته: از نسخه 6.3.0 به بعد fetchmail، دسترسی نوشتن به دایرکتوری حاوی idfile الزامی است، زیرا fetchmail یک فایل موقت می‌نویسد و تنها در صورت موفقیت‌آمیز بودن نوشتن فایل موقت، نام آن را به جای idfile واقعی تغییر می‌دهد. این کار از کوتاه و خراب شدن idfileها در صورت اتمام فضای دیسک جلوگیری می‌کند. .TP .B \--pidfile (کلمه کلیدی: pidfile؛ از نسخه 6.3.4 به بعد fetchmail) .br محل پیش‌فرض فایل PID را که به عنوان یک فایل قفل (lock file) استفاده می‌شود بازنویسی می‌کند. پیش‌فرض: به بخش "ENVIRONMENT" در ادامه مراجعه کنید. توجه داشته باشید که در بسیاری از بخش‌های کد و مستندات، اصطلاح "lock file" به کار رفته است. این فایل شامل شناسه فرآیند (Process ID) برنامه در حال اجرای fetchmail در خط نخست و احتمالاً بازه زمانی دیمن در خط دوم است. .TP .B \-n | \-\-norewrite (کلمه کلیدی: no rewrite) .br به طور معمول، \fBfetchmail\fP هدرهای آدرس RFC-822 (شامل To، From، Cc، Bcc و Reply\-To) را در نامه‌های واکشی‌شده ویرایش می‌کند تا هر شناسه نامه‌ای که متعلق به سرور محلی است به آدرس‌های کامل بسط داده شود (@ و نام میزبان سرور نامه الحاق می‌شوند). این قابلیت باعث می‌شود پاسخ‌ها در کلاینت به درستی آدرس‌دهی شوند (در غیر این صورت برنامه ایمیل شما ممکن است تصور کند نامه‌ها باید برای کاربران محلی روی ماشین کلاینت آدرس‌دهی شوند!). این گزینه بازنویسی را غیرفعال می‌کند. (این گزینه برای آسودگی خاطر افرادی فراهم شده است که در مورد ویرایش هدرهای نامه توسط MTA حساسیت دارند و می‌خواهند بدانند که می‌توانند مانع آن شوند، اما به طور کلی غیرفعال کردن بازنویسی ایده خوبی نیست.) هنگام استفاده از ETRN یا ODMR، گزینه rewrite بی‌تاثیر است. .TP .B \-E | \-\-envelope (کلمه کلیدی: envelope؛ تنها Multidrop) .br در فایل پیکربندی، ساختار نحوی پیشرفته‌تری استفاده می‌شود: .br \fBenvelope [] \fP .sp این گزینه هدری را که \fBfetchmail\fP فرض می‌کند حاوی رونوشتی از آدرس پاکت نامه (envelope address) است، تغییر می‌دهد. به طور معمول این هدر 'X\-Envelope\-To' است. هدرهای متداول دیگری که اطلاعات پاکت را حمل می‌کنند عبارتند از 'X\-Original\-To' و 'Delivered\-To'. از آنجا که این هدرها استانداردسازی نشده‌اند، رویه‌ها متفاوت است. به بحث پیرامون مدیریت آدرس‌های multidrop در ادامه مراجعه کنید. به عنوان یک حالت ویژه، 'envelope "Received"' امکان تجزیه خطوط Received به سبک sendmail را فراهم می‌کند. این حالت پیش‌فرض است، اما توصیه نمی‌شود زیرا کاملاً قابل اعتماد نیست. توجه داشته باشید که fetchmail انتظار دارد خط Received در قالب خاصی باشد: این خط باید شامل "by \fIhost\fP for \fIaddress\fP" باشد که در آن \fIhost\fP باید با یکی از نام‌های سرور نامه‌ای که fetchmail برای حساب کاربری مربوطه می‌شناسد مطابقت داشته باشد. .sp آرگومان اختیاری count (که تنها در فایل پیکربندی در دسترس است) تعیین می‌کند که چه تعداد از خطوط هدر این چنینی نادیده گرفته شوند. مقدار count برابر با ۱ به این معناست: خط اول را نادیده بگیر، خط دوم را بردار. مقدار ۲ یعنی: خطوط اول و دوم را نادیده بگیر، خط سوم را بردار، و الی آخر. .TP .B \-Q | \-\-qvirtual (کلمه کلیدی: qvirtual؛ تنها Multidrop) .br پیشوند رشته‌ای اختصاص‌یافته به این گزینه از نام کاربری یافت‌شده در هدر مشخص‌شده با گزینه \fIenvelope\fP حذف خواهد شد (\fIپیش از\fP انجام نگاشت نام multidrop یا بررسی localdomain، در صورت اعمال هر یک). این گزینه در صورتی مفید است که از \fBfetchmail\fP برای جمع‌آوری نامه‌های یک دامنه کامل استفاده می‌کنید و ISP شما (یا ارائه‌دهنده تغییر مسیر نامه شما) از qmail استفاده می‌کند. یکی از ویژگی‌های اساسی qmail هدر پیام \fIDelivered\-To:\fP است. هر زمان که qmail پیامی را به یک صندوق پستی محلی تحویل می‌دهد، نام کاربری و نام میزبان گیرنده پاکت نامه را در این خط قرار می‌دهد. دلیل اصلی این کار جلوگیری از حلقه‌های نامه است. برای تنظیم qmail جهت دسته‌بندی نامه‌ها برای سایتی که آفلاین است، میزبان نامه ISP معمولاً آن سایت را در فایل کنترل 'Virtualhosts' خود قرار می‌دهد تا یک پیشوند به تمام آدرس‌های نامه این سایت اضافه کند. این امر منجر می‌شود نامه‌هایی که به 'username\&@\&userhost.userdom.dom.com' فرستاده می‌شوند، دارای خط \fIDelivered\-To:\fR به این شکل باشند: .IP Delivered\-To: mbox\-userstr\-username\&@\&userhost.example.com .IP ارائه‌دهنده اینترنت (ISP) می‌تواند پیشوند 'mbox\-userstr\-' را هر چه که بخواهد تعیین کند، اما رشته‌ای که با نام میزبان کاربر مطابقت داشته باشد محتمل‌تر است. با استفاده از گزینه 'envelope Delivered\-To:' می‌توانید کاری کنید که fetchmail گیرنده اصلی پاکت نامه را با قابلیت اطمینان شناسایی کند، اما برای تحویل به کاربر صحیح باید پیشوند 'mbox\-userstr\-' را حذف نمایید. این گزینه دقیقاً برای همین منظور است. .TP .B \-\-configdump فایل \fI~/.fetchmailrc\fP را تجزیه می‌کند، هر گزینه خط فرمان مشخص‌شده‌ای را تفسیر می‌نماید و یک گزارش پیکربندی را در خروجی استاندارد ثبت می‌کند. گزارش پیکربندی یک انتساب ساختار داده در زبان پایتون است. این گزینه برای استفاده در یک ویرایشگر تعاملی \fI~/.fetchmailrc\fP مانند \fBfetchmailconf\fP که به زبان پایتون نوشته شده در نظر گرفته شده است. .TP .B \-y | \-\-yydebug اشکال‌زدایی پارسر را فعال می‌کند، این گزینه تنها برای استفاده توسعه‌دهندگان در نظر گرفته شده است. .SS "گزینه‌های حذف‌شده (Removed Options)" .TP .B \-T | \-\-netsec پیش از نسخه 6.3.0 حذف شد، زیرا کتابخانه زیربنایی مورد نیاز inet6_apps منسوخ شده و دیگر در دسترس نیست. .SH "احراز هویت کاربر و رمزنگاری (USER AUTHENTICATION AND ENCRYPTION)" تمام حالت‌ها به جز ETRN نیازمند احراز هویت کلاینت در سرور هستند. احراز هویت عادی کاربر در \fBfetchmail\fP بسیار شبیه سازوکار احراز هویت .BR ftp (1) است. شناسه کاربری (user-id) و گذرواژه صحیح به سیستم امنیتی زیربنایی در سرور ایمیل بستگی دارد. .PP اگر سرور ایمیل یک ماشین یونیکس باشد که در آن حساب کاربری معمولی دارید، همان نام کاربری و گذرواژه عادی شما در .BR fetchmail استفاده می‌شود. اگر از نام کاربری یکسانی در هر دو ماشین سرور و کلاینت استفاده می‌کنید، نیازی به تعیین شناسه کاربری با گزینه .B \-u ندارید -- رفتار پیش‌فرض این است که از نام کاربری شما در ماشین کلاینت به عنوان شناسه کاربری در ماشین سرور استفاده شود. اگر از نام کاربری متفاوتی در ماشین سرور استفاده می‌کنید، آن نام کاربری را با گزینه .B \-u مشخص کنید. به عنوان مثال، اگر نام کاربری شما 'jsmith' در ماشینی به نام 'mailgrunt' است، برنامه \fBfetchmail\fP را به شکل زیر اجرا می‌کنید: .IP fetchmail \-u jsmith mailgrunt .PP رفتار پیش‌فرض \fBfetchmail\fP این است که پیش از برقراری اتصال، گذرواژه سرور ایمیل را از شما بپرسد. این امن‌ترین روش برای استفاده از \fBfetchmail\fP است و تضمین می‌کند که گذرواژه شما فاش نخواهد شد. همچنین می‌توانید گذرواژه خود را در فایل \fI~/.fetchmailrc\fP تعیین کنید. این کار هنگام استفاده از \fBfetchmail\fP در حالت دیمن یا همراه با اسکریپت‌ها مناسب است. .SS "استفاده از فایل‌های netrc (Using netrc files)" اگر گذرواژه‌ای تعیین نکنید و \fBfetchmail\fP نتواند آن را از فایل \fI~/.fetchmailrc\fP شما استخراج کند، پیش از درخواست تعاملی آن، به دنبال فایل \fI~/.netrc\fP در دایرکتوری خانگی شما می‌گردد؛ اگر ورودی منطبق با سرور ایمیل در آن فایل یافت شود، از آن گذرواژه استفاده خواهد شد. برنامه fetchmail ابتدا به دنبال تطابق بر اساس نام poll می‌گردد؛ اگر موردی نیافت، تطابق بر اساس نام via را بررسی می‌کند. برای نشان دادن یک مثال کاربردی، فایل netrc. ممکن است به این شکل باشد: .IP .nf machine hermes.example.org login joe password topsecret .fi .PP در صورت نیاز به ارائه بیش از یک گذرواژه، می‌توانید این بلوک را با اطلاعات کاربری مختلف تکرار کنید. .PP این قابلیت به شما امکان می‌دهد از تکرار اطلاعات گذرواژه در بیش از یک فایل جلوگیری کنید. .PP فایل netrc شامل اطلاعات ورود به سیستمی است که در اصل برای .BR ftp (1) تنظیم شده بود، اما fetchmail ساختارهای معمول این فایل را برای استفاده از گذرواژه‌ها درک می‌کند. قواعد نحوی شامل نشانه‌ها (معمولاً به صورت جفت همراه با رشته‌ها) است. رشته‌ها می‌توانند داخل علامت نقل‌قول تکی یا دوتایی قرار گیرند (مانند "quoted string") تا امکان گنجاندن فاصله‌های خالی وجود داشته باشد، و یک بک‌اسلش (\\) در یک رشته نقل‌قول‌شده، کاراکتر بعدی را اسکیپ می‌کند تا گذرواژه بتواند خودش حاوی علامت‌های نقل‌قول باشد. نشانه‌ها با فاصله‌ها، تب‌ها یا کاراکترهای خط جدید از یکدیگر جدا می‌شوند. این نشانه‌ها پشتیبانی می‌شوند: .TP .BI "machine " name نام رایانه راه دور را که نشانه‌های بعدی برای آن اعمال می‌شوند، مشخص می‌کند. این نام باید با نام \fBpoll\fR یا \fBvia\fR در fetchmail مطابقت داشته باشد. .TP .BI "login " name نام کاربری را مشخص می‌کند که fetchmail هنگام جستجوی ورودی‌ها با آن مطابقت می‌دهد. برنامه Fetchmail نام‌های با طول صفر یا ورودی‌های فاقد \fBlogin\fR را نادیده می‌گیرد. .TP .BI "password " string گذرواژه‌ای را مشخص می‌کند که fetchmail هنگام تطابق machine و login با نام poll/via و نام کاربری از آن استفاده خواهد کرد. .TP .B default این نشانه شبیه به \fBmachine\fR است، اما با هر نامی مطابقت دارد. برنامه Fetchmail آن را نادیده می‌گیرد. پس از این نشانه، بخش‌های \fBmachine\fR دیگری مجاز نیستند. .TP .BI "account " string برنامه Fetchmail این جفت نشانه/رشته را نادیده می‌گیرد. .TP .BI "macdef " macro\_name برنامه Fetchmail این تعریف ماکرو را نادیده می‌گیرد، به این معنی که این خط، باقی‌مانده خطوط و تمام خطوط بعدی تا رسیدن به یک خط خالی (یعنی دو کاراکتر متوالی خط جدید) نادیده گرفته می‌شوند. سپس تجزیه netrc. از سر گرفته می‌شود. .PP در سرورهای ایمیلی که حساب‌های کاربری عادی ارائه نمی‌دهند، شناسه کاربری و گذرواژه شما معمولاً هنگام درخواست صندوق پستی در سرور، توسط مدیر سرور اختصاص داده می‌شود. اگر شناسه کاربری و گذرواژه صحیح صندوق پستی خود را نمی‌دانید، با مدیر سرور خود تماس بگیرید. .SS "لایه‌های سوکت امن (SSL) و امنیت لایه انتقال (TLS) (Secure Socket Layers (SSL) and Transport Layer Security (TLS))" تمامی پروتکل‌های دریافت می‌توانند از پوشش SSL یا TLS برای انتقال داده استفاده کنند. علاوه بر این، دریافت POP3 و IMAP نیز می‌تواند از طریق STARTTLS (یا STLS) پروتکل SSL/TLS را مذاکره کند. .PP می‌توانید با مشخص کردن گزینه‌هایی که با .B \-\-ssl شروع می‌شوند (مانند .BR \-\-ssl , .BR \-\-sslproto , .B \-\-nosslcertck و سایر موارد) به سرویس‌های رمزنگاری‌شده با TLS دسترسی پیدا کنید. همچنین می‌توانید این کار را با استفاده از گزینه‌های کاربری متناظر در فایل .B .fetchmailrc انجام دهید. برخی سرویس‌ها، مانند POP3 و IMAP، درگاه‌های شناخته‌شده متفاوتی برای سرویس‌های رمزنگاری‌شده با SSL تعریف کرده‌اند. درگاه‌های رمزنگاری‌شده زمانی که SSL فعال باشد و درگاه صریحی مشخص نشده باشد، به طور خودکار انتخاب خواهند شد. همچنین، گزینه خط فرمان .B \-\-sslcertck یا گزینه فایل کنترل اجرای .B sslcertck باید حداقل در مستندات برای اجبار به بررسی دقیق گواهی در نسخه‌های قدیمی‌تر fetchmail استفاده شود - توضیحات زیر را ببینید. .PP اگر TLS یا SSL پیکربندی نشده باشد، fetchmail معمولاً همچنان تلاش می‌کند از STARTTLS استفاده کند. در عمل، TLS یا SSL همچنان الزامی است زیرا .B \-\-sslcertck یک تنظیم پیش‌فرض است و به طور ضمنی نیازمند STARTTLS است. .PP پروتکل STARTTLS می‌تواند با استفاده از .B \-\-sslproto\~auto اجباری شود و با استفاده از .B \-\-sslproto\~'' غیرفعال گردد. اتصالات STARTTLS از همان درگاه نسخه رمزنگاری‌نشده پروتکل استفاده می‌کنند و TLS را از طریق دستور ویژه‌ای مذاکره می‌نمایند. گزینه خط فرمان .B \-\-sslcertck یا گزینه فایل کنترل اجرای .B sslcertck باید برای اجبار به بررسی دقیق گواهی استفاده شود - توضیحات زیر را ببینید. .PP .B استفاده از \-\-sslcertck توصیه می‌شود: هنگام اتصال به یک سرور رمزنگاری‌شده با SSL یا TLS، سرور گواهی‌ای را برای اعتبارسنجی به کلاینت ارائه می‌دهد. گواهی بررسی می‌شود تا اطمینان حاصل شود نام عمومی (common name) در گواهی با نام سروری که با آن تماس گرفته شده مطابقت دارد و تاریخ‌های شروع و انقضا در گواهی نشان می‌دهند که در حال حاضر معتبر است. اگر هر یک از این بررسی‌ها ناموفق باشد، یک پیام هشدار چاپ می‌شود، اما اتصال ادامه می‌یابد. گواهی سرور نیازی ندارد توسط مرجع صدور گواهی (CA) خاصی امضا شده باشد و می‌تواند یک گواهی «خودامضا» (self-signed) باشد. اگر گزینه خط فرمان .B \-\-sslcertck یا گزینه فایل کنترل اجرای .B sslcertck استفاده شود، در صورت ناموفق بودن هر یک از این بررسی‌ها، fetchmail عملیات را متوقف می‌کند، زیرا در این سناریو باید فرض کند حمله مرد میانی (man-in-the-middle) رخ داده است؛ بنابراین fetchmail نباید گذرواژه‌های متن‌ساده را فاش کند. از این رو استفاده از گزینه sslcertck یا .B \-\-sslcertck توصیه می‌شود؛ این گزینه در نسخه 6.4.0 fetchmail به حالت پیش‌فرض تبدیل شده است. .PP برخی سرورهای رمزنگاری‌شده با SSL ممکن است گواهی سمت کلاینت درخواست کنند. می‌توان گواهی عمومی SSL و کلید خصوصی SSL سمت کلاینت را مشخص کرد. در صورت درخواست سرور، گواهی کلاینت برای اعتبارسنجی به سرور ارسال می‌شود. برخی سرورها ممکن است به گواهی معتبر کلاینت نیاز داشته باشند و در صورت عدم ارائه گواهی یا نامعتبر بودن آن، اتصال را رد کنند. برخی سرورها ممکن است نیاز داشته باشند که گواهی‌های سمت کلاینت توسط یک مرجع صدور گواهی شناخته‌شده امضا شده باشند. فرمت فایل‌های کلید و فایل‌های گواهی همان فرمتی است که کتابخانه‌های زیربنایی SSL (در حالت کلی OpenSSL) نیاز دارند. .PP نکته‌ای احتیاطی درباره استفاده از SSL: در حالی که پیکربندی ذکرشده در بالا با گواهی‌های خودامضای سرور که از طریق شبکه دریافت می‌شوند می‌تواند از شما در برابر شنود غیرفعال محافظت کند، در برابر یک مهاجم فعال کمکی نمی‌کند. این روش قطعاً نسبت به ارسال گذرواژه‌ها به صورت متن‌ساده یک پیشرفت است، اما باید آگاه باشید که حمله مرد میانی به سادگی امکان‌پذیر است (به ویژه با ابزارهایی مانند .UR "https://monkey.org/~dugsong/dsniff" dsniff .UE ). اگر به امنیت صندوق پستی و گذرواژه‌های خود اهمیت جدی می‌دهید، استفاده از بررسی دقیق گواهی با یک مرجع صدور گواهی که توسط سرور و کلاینت شناخته شده باشد، یا شاید استفاده از یک تونل SSH (برای برخی مثال‌ها به ادامه مراجعه کنید) ارجحیت دارد. .SH "گونه‌های POP3 (POP3 VARIANTS)" نسخه‌های اولیه POP3 (شامل RFC1081 و RFC1225) از شکل ابتدایی احراز هویت مستقل با استفاده از فایل \fI.rhosts\fP در سمت سرور ایمیل پشتیبانی می‌کردند. در این گونه RPOP، یک شناسه کاربری ثابت معادل گذرواژه به صورت متن‌ساده از طریق پیوندی به یک درگاه رزروشده ارسال می‌شد و از دستور RPOP به جای PASS استفاده می‌گردید تا به سرور هشدار دهد که باید بررسی ویژه‌ای انجام دهد. قابلیت RPOP توسط \fBfetchmail\fP پشتیبانی می‌شود (می‌توانید 'protocol RPOP' را مشخص کنید تا برنامه به جای 'PASS' مقدار 'RPOP' را ارسال کند)، اما استفاده از آن به شدت منع می‌شود و پشتیبانی از آن در نسخه‌های آینده fetchmail حذف خواهد شد. این سازوکار در برابر جعل هویت (spoofing) آسیب‌پذیر بود و در RFC1460 کنار گذاشته شد. .PP سند RFC1460 احراز هویت APOP را معرفی کرد. در این گونه از POP3، شما یک گذرواژه APOP در هاست سرور خود ثبت می‌کنید (در برخی سرورها، برنامه‌ای که این کار را انجام می‌دهد \fBpopauth\fP(8) نام دارد). همان گذرواژه را در فایل \fI~/.fetchmailrc\fP خود قرار می‌دهید. هر بار که \fBfetchmail\fP وارد سیستم می‌شود، یک هش MD5 از گذرواژه شما و زمان خوش‌آمدگویی سرور را به سرور ارسال می‌کند که سرور می‌تواند با بررسی پایگاه داده احراز هویت خود، آن را اعتبارسنجی کند. \fBتوجه داشته باشید که APOP دیگر در برابر حملات مرد میانی مقاوم در نظر گرفته نمی‌شود.\fP .SS "دستورات RETR یا TOP (RETR or TOP)" برنامه \fBfetchmail\fP تلاش‌هایی انجام می‌دهد تا سرور تصور کند پیام‌ها دریافت نشده‌اند؛ این کار در صورت امکان با استفاده از دستور TOP همراه با تعداد زیادی خط انجام می‌شود. دستور TOP دستوری است که سرآیند کامل و تعداد مشخصی از خطوط بدنه تعیین‌شده توسط \fBfetchmail\fP را دریافت می‌کند. این دستور اختیاری است و بنابراین توسط همه سرورها پیاده‌سازی نشده است، و مشخص شده که برخی سرورها آن را به درستی پیاده‌سازی نمی‌کنند. با این حال، در بسیاری از سرورها دستور RETR که کل پیام را همراه با سرآیند و بدنه دریافت می‌کند، فلگ "دیده شده" (seen) را (مثلاً در رابط وب) تنظیم می‌کند، در حالی که دستور TOP این کار را انجام نمی‌دهد. .PP اگر "fetchall" تنظیم شده باشد، \fBfetchmail\fP همیشه از دستور RETR استفاده خواهد کرد. همچنین اگر "keep" تنظیم شده و "uidl" تنظیم نشده باشد، \fBfetchmail\fP از دستور RETR استفاده خواهد کرد. در نهایت، \fBfetchmail\fP در سرورهای Maillennium POP3/PROXY (مورد استفاده توسط Comcast) از دستور RETR استفاده می‌کند تا از تفسیر نادرست عمدی TOP در این سرور که باعث خرابی پیام می‌شود، جلوگیری کند. .PP در تمام موارد دیگر، \fBfetchmail\fP از دستور TOP استفاده خواهد کرد. این بدان معناست که در پیکربندی‌های "keep"، در صورتی که استفاده از "TOP" مد نظر باشد، باید "uidl" تنظیم شود. .PP \fBتوجه داشته باشید\fP که این توضیحات برای نسخه فعلی fetchmail صادق است، اما این رفتار ممکن است در نسخه‌های آینده تغییر کند. به طور خاص، fetchmail ممکن است دستور RETR را ترجیح دهد زیرا دستور TOP در برخی سرورها مشکلات زیادی ایجاد می‌کند و تنها اختیاری است. .SH "شیوه‌ها و روش‌های احراز هویت جایگزین (ALTERNATE AUTHENTICATION FORMS/METHODS)" اگر \fBfetchmail\fP شما با پشتیبانی از Kerberos کامپایل شده باشد و احراز هویت Kerberos را مشخص کنید (یا با .B \-\-auth یا با گزینه \fBauthenticate kerberos_v4\fP در فایل \fI.fetchmailrc\fP)، در ابتدای هر پرس‌وجو تلاش خواهد کرد یک بلیت Kerberos از سرور ایمیل دریافت کند. نکته: اگر نام pollname یا via برابر با 'hesiod' باشد، fetchmail تلاش می‌کند از Hesiod برای جستجوی سرور ایمیل استفاده کند. .PP اگر از POP3 یا IMAP همراه با احراز هویت GSSAPI استفاده کنید، \fBfetchmail\fP انتظار دارد سرور قابلیت GSSAPI منطبق با RFC1731 یا RFC1734 را داشته باشد و از آن استفاده خواهد کرد. در حال حاضر این قابلیت فقط روی Kerberos\ 5 آزمایش شده است، بنابراین انتظار می‌رود شما از قبل یک بلیت اعطای بلیت (TGT) داشته باشید. می‌توانید با استفاده از دستور استاندارد \fB\-\-user\fP یا با گزینه \fBuser\fP در فایل \fI.fetchmailrc\fP نام کاربری متفاوتی از نام اصلی (principal) خود ارسال کنید. .PP اگر دیمن IMAP شما پاسخ PREAUTH را در خط خوش‌آمدگویی خود بازگرداند، fetchmail متوجه این موضوع شده و مرحله احراز هویت عادی را نادیده می‌گیرد. این امر می‌تواند مفید باشد، مثلاً اگر imapd را به صراحت با استفاده از ssh اجرا کنید. در این حالت می‌توانید مقدار احراز هویت را در ورودی آن سایت برابر با 'implicit' قرار دهید تا هنگام شروع به کار \fI.fetchmail\fP از شما گذرواژه درخواست نشود. .PP اگر از احراز هویت کلاینت با \fITLS1\fP استفاده می‌کنید و دیمن IMAP شما پاسخ \fIAUTH=EXTERNAL\fP را بازمی‌گرداند، fetchmail متوجه این موضوع شده و از میان‌بر احراز هویت استفاده می‌کند و عبارت عبور را ارسال نخواهد کرد. در این حالت می‌توانید مقدار احراز هویت را در آن سایت برابر با 'external' قرار دهید تا هنگام شروع به کار \fBfetchmail\fP از شما گذرواژه درخواست نشود. .PP اگر از POP3 استفاده می‌کنید و سرور یک چالش گذرواژه یک‌بارمصرف منطبق با RFC1938 صادر کند، \fBfetchmail\fP از گذرواژه شما به عنوان عبارت عبور برای تولید پاسخ مورد نیاز استفاده می‌کند. این کار از ارسال اطلاعات محرمانه به صورت رمزنگاری‌نشده در شبکه جلوگیری می‌کند. .PP احراز هویت RPA شرکت Compuserve پشتیبانی می‌شود. اگر این پشتیبانی را کامپایل کرده باشید، در صورتی که \fBfetchmail\fP عبارت "@compuserve.com" را در نام هاست تشخیص دهد، تلاش می‌کند به جای ارسال گذرواژه به صورت رمزنگاری‌نشده، یک احراز هویت عبارت عبور RPA انجام دهد. .PP اگر از IMAP استفاده می‌کنید، احراز هویت NTLM مایکروسافت (مورد استفاده در Microsoft Exchange) پشتیبانی می‌شود. اگر این پشتیبانی را کامپایل کرده باشید، هر زمان که سرور پاسخ AUTH=NTLM را در قابلیت‌های خود بازگرداند، \fBfetchmail\fP تلاش خواهد کرد یک احراز هویت NTLM (به جای ارسال گذرواژه به صورت رمزنگاری‌نشده) انجام دهد. مقدار گزینه کاربری را به صورت \&'user@domain' مشخص کنید: بخش سمت چپ @ به عنوان نام کاربری و بخش سمت راست به عنوان دامنه NTLM ارسال خواهد شد. .SS "احراز هویت ESMTP (ESMTP AUTH)" برنامه \fBfetchmail\fP همچنین از احراز هویت در سرور ESMTP در سمت کلاینت طبق RFC 4952 پشتیبانی می‌کند. سازوکارهای احراز هویت پشتیبانی‌شده عبارتند از CRAM-MD5، PLAIN و در نسخه 6.5.X fetchmail روش منسوخ‌شده LOGIN. می‌توانید یک جفت نام/گذرواژه را برای استفاده با کلیدواژه‌های 'esmtpname' و 'esmtppassword' تعیین کنید؛ اولی به طور پیش‌فرض روی نام کاربری کاربر فراخواننده تنظیم می‌شود. .SH "حالت دیمن (DAEMON MODE)" .SS "معرفی حالت دیمن (Introducing the daemon mode)" در حالت دیمن، \fBfetchmail\fP خود را در پس‌زمینه قرار می‌دهد و به طور مداوم اجرا می‌شود، هر هاست مشخص‌شده را بررسی کرده و سپس برای یک بازه زمانی مشخص به خواب می‌رود. .SS "شروع حالت دیمن (Starting the daemon mode)" چندین راه برای اجرای fetchmail در حالت دیمن وجود دارد. در خط فرمان، گزینه \fB\-\-daemon\ \fP یا \fB\-d\ \fP برنامه \fBfetchmail\fP را در حالت دیمن اجرا می‌کند. باید یک آرگومان عددی مشخص کنید که بازه بررسی (مدت زمان انتظار پس از تکمیل یک چرخه کامل بررسی با آخرین سرور و قبل از شروع چرخه بعدی با اولین سرور) بر حسب ثانیه است. .PP مثال: اجرای ساده دستور .IP fetchmail \-d 900 .PP باعث می‌شود تمام هاست‌های توصیف‌شده در فایل \fI~/.fetchmailrc\fP شما (به جز مواردی که با عبارت 'skip' صراحتاً مستثنی شده‌اند) با فاصله‌ای کمی کمتر از یک بار در هر ۱۵ دقیقه (دقیقاً: ۱۵ دقیقه + زمانی که بررسی طول می‌کشد) بررسی شوند. .PP همچنین می‌توان با نوشتن عبارت 'set\ daemon\ ' در فایل \fI~/.fetchmailrc\fP یک بازه زمانی بررسی تنظیم کرد، که در آن یک عدد صحیح بر حسب ثانیه است. اگر این کار را انجام دهید، fetchmail همیشه در حالت دیمن شروع به کار می‌کند، مگر اینکه با گزینه خط فرمان .B \-\-daemon 0 یا .B \-d0 آن را لغو کنید. .PP برای هر کاربر تنها یک فرایند دیمن مجاز است؛ در حالت دیمن، \fBfetchmail\fP یک فایل قفل برای هر کاربر ایجاد می‌کند تا این موضوع را تضمین کند. (البته می‌توانید با تنظیم متغیر محیطی FETCHMAILHOME این محدودیت را دور بزنید، اما در این صورت، مسئولیت اطمینان از اینکه یک سرور را با دو فرایند به طور همزمان بررسی نمی‌کنید بر عهده خودتان است.) .SS "بیدار کردن دیمن پس‌زمینه (Awakening the background daemon)" به طور معمول، فراخوانی fetchmail در حالی که یک دیمن در پس‌زمینه در حال اجراست، یک سیگنال بیدارباش به دیمن ارسال کرده و بدون چاپ خروجی خارج می‌شود. دیمن پس‌زمینه سپس بلافاصله چرخه بررسی بعدی خود را آغاز می‌کند. سیگنال بیدارباش، SIGUSR1، را می‌توان به صورت دستی نیز ارسال کرد. عمل بیدارباش همچنین تمام فلگ‌های 'wedged' را که نشان‌دهنده گیر کردن اتصالات به دلیل شکست در احراز هویت یا اتمام زمان‌های مکرر هستند، پاک می‌کند. .SS "خاتمه دادن به دیمن پس‌زمینه (Terminating the background daemon)" گزینه .B \-q یا .B \-\-quit به جای بیدار کردن دیمن، فرایند دیمن در حال اجرا را متوقف می‌کند (اگر چنین فرایندی وجود نداشته باشد، \fBfetchmail\fP به شما اطلاع خواهد داد). اگر گزینه .B \-\-quit به عنوان آخرین گزینه در خط فرمان ظاهر شود، \fBfetchmail\fP فرایند دیمن در حال اجرا را متوقف کرده و سپس خارج می‌شود. در غیر این صورت، \fBfetchmail\fP ابتدا فرایند دیمن در حال اجرا را متوقف می‌کند و سپس با سایر گزینه‌ها به اجرای خود ادامه می‌دهد. .SS "گزینه‌های مفید برای حالت دیمن (Useful options for daemon mode)" گزینه .B \-L یا .B \-\-logfile (کلیدواژه: set logfile) تنها زمانی مؤثر است که fetchmail جدا شده و در حالت دیمن باشد. توجه داشته باشید که \fBفایل گزارش (logfile) باید قبل از\fP اجرای fetchmail وجود داشته باشد؛ می‌توانید از دستور .BR touch (1) با نام فایل به عنوان تنها آرگومان آن برای ایجاد فایل استفاده کنید. .br این گزینه به شما امکان می‌دهد پیام‌های وضعیت را به یک فایل گزارش مشخص هدایت کنید (نام فایل گزارش را بعد از گزینه بیاورید). فایل گزارش در حالت الحاق (append) باز می‌شود، بنابراین پیام‌های قبلی حذف نمی‌شوند. این کار در درجه اول برای اشکال‌زدایی پیکربندی‌ها مفید است. توجه داشته باشید که fetchmail چرخش (rotate) فایل گزارش را تشخیص نمی‌دهد؛ فایل گزارش تنها یک بار هنگام شروع fetchmail باز می‌شود. لازم است پس از چرخاندن فایل گزارش و قبل از فشرده‌سازی آن (در صورت وجود)، fetchmail را مجدداً راه‌اندازی کنید. .br از نسخه 6.5.0، فایل گزارش با برچسب‌های زمانی، در زمان محلی و با فرمت "Jun 20 23:45:01 fetchmail: " پیشوندگذاری می‌شود. این فرمت از طریق متغیرهای محیطی LC_TIME (یا LC_ALL) و TZ بومی‌سازی خواهد شد. .PP گزینه .B \-\-syslog (کلیدواژه: set syslog) به شما امکان می‌دهد پیام‌های وضعیت و خطای صادرشده را در صورت در دسترس بودن به دیمن سیستمی .BR syslog (3) هدایت کنید. پیام‌ها با شناسه \fBfetchmail\fP، بخش \fBLOG_MAIL\fP و اولویت‌های \fBLOG_ERR\fP، \fBLOG_ALERT\fP یا \fBLOG_INFO\fP ثبت می‌شوند. این گزینه برای ثبت پیام‌های وضعیت و خطا در نظر گرفته شده است که وضعیت دیمن و نتایج دریافت ایمیل از سرور(ها) را نشان می‌دهند. پیام‌های خطای مربوط به گزینه‌های خط فرمان و تجزیه فایل \fI.fetchmailrc\fP همچنان در stderr یا در فایل گزارش مشخص‌شده نوشته می‌شوند. گزینه .B \-\-nosyslog استفاده از .BR syslog (3) را خاموش می‌کند، با این فرض که در فایل \fI~/.fetchmailrc\fP روشن شده باشد. این گزینه در شرایط خاصی توسط \fB\-\-logfile\fP (که توضیح داده شد) نادیده گرفته می‌شود. .PP گزینه .B \-N یا .B \-\-nodetach از رفتن به پس‌زمینه و جدا شدن فرایند دیمن از ترمینال کنترلی آن جلوگیری می‌کند. این قابلیت برای اشکال‌زدایی یا زمانی که fetchmail به عنوان فرزند یک فرایند ناظر مانند .BR init (8) یا .BR runit (8) اثر Gerrit Pape اجرا می‌شود، مفید است. توجه داشته باشید که این کار همچنین باعث نادیده گرفته شدن گزینه logfile می‌شود. .PP توجه داشته باشید که هنگام اجرا در حالت دیمن و بررسی یک سرور POP2 یا IMAP2bis، خطاهای گذرا (مانند خرابی‌های DNS یا عدم پذیرش تحویل توسط sendmail) ممکن است گزینه fetchall را برای مدت چرخه بررسی بعدی اجباری کنند. این یک ویژگی برای افزایش پایداری است؛ به این معنی که اگر پیامی دریافت شود (و در نتیجه توسط سرور ایمیل به عنوان دیده‌شده علامت‌گذاری شود) اما به دلیل یک خطای گذرا به صورت محلی تحویل داده نشود، در طول چرخه بررسی بعدی دوباره دریافت خواهد شد. (منطق IMAP پیام‌ها را تا زمانی که تحویل داده نشوند حذف نمی‌کند، بنابراین این مشکل در آن رخ نمی‌دهد.) .PP اگر فایل \fI~/.fetchmailrc\fP را در حالی که fetchmail در حالت دیمن در حال اجراست تغییر دهید یا دستور touch روی آن اجرا کنید، این تغییر در ابتدای چرخه بررسی بعدی تشخیص داده می‌شود. هنگامی که تغییر فایل \fI~/.fetchmailrc\fP تشخیص داده شود، fetchmail آن را مجدداً می‌خواند و از ابتدا راه‌اندازی می‌شود (با استفاده از exec(2)؛ هیچ اطلاعات وضعیتی در نمونه جدید حفظ نمی‌شود). توجه داشته باشید که اگر fetchmail نیاز به درخواست گذرواژه داشته باشد، یا اگر ساختار دستوری فایل \fI~/.fetchmailrc\fP را خراب کنید، نمونه جدید هنگام راه‌اندازی به آرامی و بدون صدا ناپدید خواهد شد. .SH "گزینه‌های مدیریتی (ADMINISTRATIVE OPTIONS)" گزینه .B \-\-postmaster (کلیدواژه: set postmaster) نام کاربری آخرین راهکار را مشخص می‌کند که در صورت عدم یافتن گیرنده محلی منطبق، ایمیل‌های multidrop باید به آن ارسال شوند. همچنین در صورتی که گزینه عمومی 'bouncemail' خاموش باشد به عنوان مقصد ایمیل‌های غیرقابل تحویل، و علاوه بر این در صورتی که گزینه عمومی 'bouncemail' خاموش و گزینه عمومی 'spambounce' روشن باشد برای ایمیل‌های مسدودشده توسط هرزنامه استفاده می‌شود. این گزینه به طور پیش‌فرض روی کاربری که \fBfetchmail\fP را اجرا کرده تنظیم می‌شود. اگر کاربر اجراکننده root باشد، پیش‌فرض این گزینه کاربر 'postmaster' است. تنظیم postmaster به یک رشته خالی باعث دور ریخته شدن چنین ایمیل‌هایی می‌شود - با این حال این کار معمولاً ایده بدی است. همچنین توضیحات مربوط به متغیر محیطی 'FETCHMAILUSER' را در بخش ENVIRONMENT در ادامه ببینید. .PP گزینه .B \-\-nobounce مشابه گزینه عمومی "set no bouncemail" رفتار می‌کند، که به آن ارجاع داده شده است. .PP گزینه .B \-\-invisible (کلیدواژه: set invisible) تلاش می‌کند fetchmail را نامرئی کند. به طور معمول، fetchmail مانند هر MTA دیگری رفتار می‌کند -- یک سرآیند Received در هر پیام ایجاد می‌کند که جایگاه آن را در زنجیره انتقال توصیف می‌نماید، و به MTAای که ایمیل را به آن فوروارد می‌کند اعلام می‌دارد که ایمیل از ماشینی که خود fetchmail روی آن اجرا می‌شود آمده است. اگر گزینه invisible روشن باشد، سرآیند Received حذف می‌شود و fetchmail تلاش می‌کند MTAای را که ایمیل را به آن فوروارد می‌کند فریب دهد تا فکر کند مستقیماً از هاست سرور ایمیل آمده است. .PP گزینه .B \-\-showdots (کلیدواژه: set showdots) برنامه fetchmail را مجبور می‌کند تا نقطه‌های پیشرفت را نشان دهد حتی اگر خروجی به یک فایل برود یا fetchmail در حالت پرحرف (verbose) نباشد. برنامه Fetchmail به طور پیش‌فرض هنگامی که در حالت .B \-\-verbose اجرا شود \fIو\fP خروجی به کنسول برود، نقطه‌ها را نشان می‌دهد. این گزینه در حالت .B \-\-silent نادیده گرفته می‌شود. .PP با مشخص کردن گزینه .B \-\-tracepolls می‌توانید از fetchmail بخواهید اطلاعاتی را به شکل "polling {label} account {user}" به سرآیند Received اضافه کند، که در آن {label} برچسب حساب کاربری (از rcfile مشخص‌شده، معمولاً ~/.fetchmailrc) و {user} نام کاربری است که برای ورود به سرور ایمیل استفاده می‌شود. این سرآیند می‌تواند برای فیلتر کردن ایمیل‌ها در جایی که اطلاعات سرآیند مفید در دسترس نیست و می‌خواهید ایمیل‌های حساب‌های مختلف در صندوق‌های پستی جداگانه مرتب شوند استفاده شود (این مورد می‌تواند، به عنوان مثال، زمانی رخ دهد که حسابی روی همان سروری که یک لیست پستی را اجرا می‌کند داشته باشید و با استفاده از آن حساب در لیست عضو شده باشید). پیش‌فرض این است که چنین سرآیندی اضافه نشود. در .IR .fetchmailrc ، این مورد 'tracepolls' نامیده می‌شود. .SH "حالت‌های شکست در دریافت (RETRIEVAL FAILURE MODES)" پروتکل‌هایی که \fBfetchmail\fP برای برقراری ارتباط با سرورهای ایمیل استفاده می‌کند تقریباً بی‌نقص و ضدگلوله هستند. در عملکرد عادی هنگام فوروارد به درگاه 25، هیچ پیامی هرگز روی هاست حذف نمی‌شود (یا حتی برای حذف علامت‌گذاری نمی‌شود) تا زمانی که شنونده SMTP در سمت کلاینت به \fBfetchmail\fP تأیید کند که پیام یا برای تحویل پذیرفته شده یا به دلیل مسدودسازی هرزنامه رد شده است. .PP با این حال، هنگام فوروارد به یک MDA، احتمال بروز خطا بیشتر است. برخی MDAها 'امن' هستند و در صورت بروز هرگونه خطای تحویل (حتی خطای ناشی از محدودیت‌های موقت منابع)، وضعیت غیرصفر را با قابلیت اطمینان بالا بازمی‌گردانند. برنامه .BR maildrop (1) از این نوع است؛ اکثر برنامه‌هایی که به عنوان عامل انتقال ایمیل طراحی شده‌اند، مانند .BR sendmail (1) (شامل پوشش sendmail در Postfix) و .BR exim (1) نیز همین‌طور هستند. این برنامه‌ها تأییدیه مثبت و قابل اعتمادی ارائه می‌دهند و می‌توان بدون خطر از دست رفتن ایمیل، از آنها با گزینه mda استفاده کرد. با این حال، MDAهای ناامن ممکن است حتی در صورت شکست تحویل، مقدار 0 را بازگردانند. اگر این اتفاق بیفتد، ایمیل‌ها را از دست خواهید داد. .PP حالت عادی \fBfetchmail\fP این است که تلاش کند فقط پیام‌های 'جدید' را دانلود کند و پیام‌هایی را که قبلاً مستقیماً روی سرور خوانده‌اید (یا با دستور قبلی \fIfetchmail \-\-keep\fP دریافت کرده‌اید) دست‌نخورده (و حذف‌نشده) باقی بگذارد. اما ممکن است متوجه شوید پیام‌هایی که قبلاً روی سرور خوانده‌اید، حتی زمانی که .B \-\-all را مشخص نکرده‌اید، دریافت (و حذف) می‌شوند. دلایل متعددی برای بروز این اتفاق وجود دارد. .PP یک دلیل می‌تواند این باشد که از POP2 استفاده می‌کنید. پروتکل POP2 هیچ نمایشی از وضعیت 'جدید' یا 'قدیمی' در پیام‌ها ندارد، بنابراین \fBfetchmail\fP باید تمام پیام‌ها را همیشه به عنوان جدید تلقی کند. اما POP2 منسوخ شده است، بنابراین این امر بعید است. .PP یک مشکل بالقوه در POP3 ممکن است سرورهایی باشند که پیام‌ها را در وسط صندوق‌های پستی درج می‌کنند (شایعه شده است که برخی پیاده‌سازی‌های ایمیل در VMS این کار را انجام می‌دهند). کد \fBfetchmail\fP فرض می‌کند پیام‌های جدید به انتهای صندوق پستی اضافه می‌شوند؛ وقتی این فرض درست نباشد، ممکن است برخی پیام‌های قدیمی را به عنوان جدید و برعکس در نظر بگیرد. استفاده از UIDL در حالی که fastuidl روی 0 تنظیم شده باشد ممکن است این مشکل را برطرف کند، در غیر این صورت، تغییر پروتکل به IMAP را مد نظر قرار دهید. .PP یکی دیگر از مشکلات POP3 این است که اگر سرورها نتوانند فایل‌های موقت در دایرکتوری خانگی کاربر ایجاد کنند، برخی سرورهای POP3 پاسخ مستندنشده‌ای بازمی‌گردانند که باعث می‌شود fetchmail به اشتباه گزارش "No mail" بدهد. .PP کد IMAP از وجود یا عدم وجود فلگ سرور \eSeen برای تصمیم‌گیری در مورد جدید بودن یا نبودن پیام استفاده می‌کند. این کار روش مناسبی نیست؛ fetchmail باید UIDVALIDITY را بررسی کرده و از UID استفاده کند، اما هنوز این کار را انجام نمی‌دهد. تحت یونیکس، fetchmail به سرور IMAP شما متکی است تا فلگ‌های Status به سبک BSD را که توسط عوامل کاربری ایمیل تنظیم شده‌اند تشخیص دهد و در صورت لزوم فلگ \eSeen را از روی آن‌ها تنظیم کند. تمام سرورهای IMAP یونیکس که می‌شناسیم این کار را انجام می‌دهند، هرچند این موضوع توسط RFCهای IMAP مشخص نشده است. اگر زمانی با سروری برخورد کردید که این کار را انجام نمی‌دهد، نشانه آن این خواهد بود که پیام‌هایی که قبلاً در هاست خود خوانده‌اید برای سرور جدید به نظر می‌رسند. در این حالت (بعید)، تنها پیام‌هایی که با \fIfetchmail \-\-keep\fP دریافت کرده‌اید هم حذف نمی‌شوند و هم به عنوان قدیمی علامت‌گذاری می‌گردند. .PP در حالت‌های ETRN و ODMR، برنامه \fBfetchmail\fP در واقع پیام‌ها را دریافت نمی‌کند؛ در عوض، از شنونده SMTP سرور می‌خواهد تا تخلیه صف را از طریق SMTP به کلاینت آغاز کند. بنابراین تنها پیام‌های تحویل‌نشده را ارسال می‌کند. .SH "فیلتر هرزنامه (SPAM FILTERING)" بسیاری از شنوندگان SMTP به مدیران اجازه می‌دهند 'فیلترهای هرزنامه' تنظیم کنند که ایمیل‌های ناخواسته را از دامنه‌های مشخص‌شده مسدود می‌کنند. خط MAIL FROM یا DATA که این ویژگی را فعال کند پاسخی از SMTP به همراه خواهد داشت که (متأسفانه) بر اساس نوع شنونده متفاوت است. .PP نسخه‌های جدیدتر \fBsendmail\fP کد خطای 571 را بازمی‌گردانند. .PP طبق RFC2821، پاسخ صحیح در این وضعیت کد 550 با پیام "Requested action not taken: mailbox unavailable" است (پیش‌نویس عبارت "[E.g., mailbox not found, no access, or command rejected for policy reasons]." را اضافه می‌کند). .PP نسخه‌های قدیمی‌تر MTA برنامه \fBexim\fP کد 501 با پیام "Syntax error in parameters or arguments" را بازمی‌گردانند. .PP برنامه MTA \fBpostfix\fP کد 554 را به عنوان پاسخ ضد هرزنامه ارسال می‌کند. .PP برنامه \fBZmailer\fP ممکن است کد را با پاسخ 500 رد کند (به همراه یک کد وضعیت پیشرفته که حاوی اطلاعات بیشتری است). .PP کدهای بازگشتی که \fBfetchmail\fP آن‌ها را به عنوان پاسخ‌های ضد هرزنامه در نظر می‌گیرد و پیام را دور می‌ریزد، می‌توانند با گزینه 'antispam' تنظیم شوند. این یکی از \fIتنها\fP سه وضعیتی است که در آن fetchmail ایمیل را دور می‌ریزد (موارد دیگر خطاهای 552 و 553 هستند که در ادامه توضیح داده شده‌اند، و جلوگیری از دریافت پیام‌های چندمقصدی با شناسه پیامی که قبلاً دیده شده است). .PP اگر \fBfetchmail\fP در حال دریافت از یک سرور IMAP باشد، پاسخ ضد هرزنامه تشخیص داده شده و پیام بلافاصله پس از دریافت سرآیندها، بدون خواندن بدنه پیام رد خواهد شد. بنابراین، هزینه‌ای برای دانلود بدنه پیام‌های هرزنامه پرداخت نخواهید کرد. .PP به طور پیش‌فرض، فهرست پاسخ‌های ضد هرزنامه خالی است. .PP اگر گزینه عمومی \fIspambounce\fP روشن باشد، ایمیلی که به دلیل هرزنامه مسدود شده است یک پیام برگشتی (bounce) منطبق با RFC1892/RFC1894 ایجاد می‌کند و به فرستنده اطلاع می‌دهد که ما ایمیلی از آن نمی‌پذیریم. همچنین بخش BUGS را ببینید. .SH "مدیریت خطاهای SMTP/ESMTP (SMTP/ESMTP ERROR HANDLING)" علاوه بر مسدودسازی هرزنامه که در بالا توضیح داده شد، fetchmail در مواجهه با کدهای پاسخ خطای SMTP/ESMTP زیر اقدامات ویژه‌ای انجام می‌دهد \(em که ممکن است با گزینه .B \-\-softbounce تغییر کند \(em: .TP 5 452 (فضای ذخیره‌سازی ناکافی سیستم) پیام را برای دریافت بعدی در صندوق پستی سرور باقی می‌گذارد. .TP 5 552 (پیام از حداکثر اندازه مجاز پیام بیشتر است) پیام را از سرور حذف می‌کند. پیام برگشتی (bounce-mail) به فرستنده ارسال می‌کند. .TP 5 553 (دامنه ارسال‌کننده نامعتبر است) پیام را از سرور حذف می‌کند. حتی تلاشی برای ارسال پیام برگشتی به فرستنده انجام نمی‌دهد. .PP سایر خطاهای بزرگ‌تر یا مساوی 500 باعث ارسال ایمیل برگشتی به فرستنده می‌شوند، مگر اینکه توسط .B \-\-softbounce مهار شده باشند. همچنین بخش BUGS را ببینید. .SH "فایل کنترل اجرا (THE RUN CONTROL FILE)" روش ترجیحی برای تنظیم fetchmail، نوشتن یک فایل \&\fI.fetchmailrc\fP در دایرکتوری خانگی شما است (می‌توانید این کار را مستقیماً با یک ویرایشگر متن یا به صورت غیرمستقیم از طریق \fBfetchmailconf\fP انجام دهید). هنگامی که تعارضی بین آرگومان‌های خط فرمان و آرگومان‌های موجود در این فایل وجود داشته باشد، آرگومان‌های خط فرمان اولویت دارند. .PP برای محافظت از امنیت گذرواژه‌های شما، فایل \fI~/.fetchmailrc\fP معمولاً نباید مجوزی بیش از 0700 (u=rwx,g=,o=) داشته باشد؛ در غیر این صورت \fBfetchmail\fP خطا داده و خارج می‌شود (این بررسی زمانی که .B \-\-version روشن باشد نادیده گرفته می‌شود). .PP می‌توانید فایل \fI.fetchmailrc\fP را به عنوان فهرستی از دستورات بخوانید که وقتی \fBfetchmail\fP بدون هیچ آرگومانی فراخوانی می‌شود اجرا می‌گردند. .SS "قواعد نحوی کنترل اجرا (Run Control Syntax)" توضیحات با یک '#' شروع شده و تا انتهای خط ادامه می‌یابند. در غیر این صورت، فایل شامل مجموعه‌ای از ورودی‌های سرور یا دستورات گزینه‌های عمومی در یک ساختار نحوی آزاد و مبتنی بر نشانه است. .PP چهار نوع نشانه وجود دارد: کلیدواژه‌های دستوری، اعداد (یعنی دنباله‌ای از ارقام ده‌دهی)، رشته‌های بدون نقل‌قول و رشته‌های داخل نقل‌قول. یک رشته داخل نقل‌قول با علامت‌های نقل‌قول دوتایی احاطه می‌شود و می‌تواند شامل فاصله‌های خالی باشد (و ارقام داخل نقل‌قول به عنوان یک رشته در نظر گرفته می‌شوند). توجه داشته باشید که رشته‌های داخل نقل‌قول اگر روی دو یا چند خط امتداد یابند، حاوی کاراکترهای خط جدید (line feed) نیز خواهند بود، مگر اینکه از یک بک‌اسلش برای پیوند دادن خطوط استفاده کنید (به ادامه مراجعه فرمایید). یک رشته بدون نقل‌قول هر نشانه‌ای است که با فاصله خالی جدا شده و نه عددی است، نه داخل نقل‌قول است و نه شامل کاراکترهای ویژه ','، ';'، \&':' یا '=' می‌باشد. .PP هر مقدار فاصله خالی نشانه‌ها را در ورودی‌های سرور از یکدیگر جدا می‌کند، اما در غیر این صورت نادیده گرفته می‌شود. می‌توانید از دنباله‌های اسکیپ بک‌اسلش (\en برای LF، \&\et برای HT، \eb برای BS، \er برای CR، \e\fInnn\fP برای ده‌دهی (که در آن nnn نمی‌تواند با 0 شروع شود)، \e0\fIooo\fP برای هشت‌هشتی، و \ex\fIhh\fP برای هگزادسیمال) برای گنجاندن کاراکترهای غیرقابل چاپ یا جداکننده‌های رشته در رشته‌ها استفاده کنید. در رشته‌های داخل نقل‌قول، یک بک‌اسلش در انتهای خط باعث می‌شود که خود بک‌اسلش و کاراکتر خط جدید (LF یا NL) نادیده گرفته شوند تا بتوانید رشته‌های طولانی را بشکنید. بدون بک‌اسلش در انتهای خط، کاراکتر خط جدید بخشی از رشته خواهد شد. .PP \fBهشدار:\fP اگرچه این دنباله‌ها شبیه به دنباله‌های اسکیپ به سبک C هستند، اما یکسان نیستند. برنامه fetchmail تنها از این هشت سبک پشتیبانی می‌کند. زبان C از دنباله‌های اسکیپ بیشتری که شامل بک‌اسلش (\e) و یک کاراکتر منفرد هستند پشتیبانی می‌کند، اما از کدهای ده‌دهی پشتیبانی نمی‌کند و نیازی به 0 ابتدایی در نماد هشت‌هشتی ندارد. مثال: برنامه fetchmail عبارت \e233 را همانند \exE9 (حرف لاتین کوچک e با اکسان اکیو) تفسیر می‌کند، در حالی که C عبارت \e233 را به عنوان هشت‌هشتی 0233 = \ex9B (CSI، معرفی‌کننده دنباله کنترل) تفسیر می‌کند. .PP هر ورودی سرور شامل یکی از کلیدواژه‌های 'poll' یا 'skip' است که به دنبال آن یک نام سرور، سپس گزینه‌های سرور، سپس هر تعداد توصیف کاربر (یا نام کاربری) و در نهایت گزینه‌های کاربر می‌آید. نکته: شایع‌ترین علت خطاهای نحوی، مخلوط کردن گزینه‌های کاربر و سرور یا قرار دادن گزینه‌های کاربر قبل از توصیف‌های کاربر است. .PP برای سازگاری با گذشته، کلمه 'server' مترادفی برای 'poll' است. .PP می‌توانید از کلیدواژه‌های پرکننده (noise keywords) شامل 'and'، 'with'، \&'has'، 'wants' و 'options' در هر جای ورودی استفاده کنید تا آن را شبیه به زبان انگلیسی کنید. این کلمات نادیده گرفته می‌شوند، اما می‌توانند خواندن ورودی‌ها را در یک نگاه بسیار آسان‌تر کنند. علائم نگارشی ':'، ';' و \&',' نیز نادیده گرفته می‌شوند. .SS "بررسی در برابر نادیده‌گیری (Poll versus Skip)" فعل 'poll' به fetchmail می‌گوید که هنگام اجرا بدون هیچ آرگومانی، این هاست را بررسی کند. فعل 'skip' به \fBfetchmail\fP می‌گوید که این هاست را بررسی نکند مگر اینکه صراحتاً در خط فرمان نام برده شود. (فعل 'skip' به شما امکان می‌دهد تا ورودی‌های آزمایشی را با اطمینان آزمایش کنید، یا به راحتی ورودی‌های مربوط به هاست‌هایی را که موقتاً از دسترس خارج شده‌اند غیرفعال کنید.) .SH "خلاصه کلیدواژه‌ها و گزینه‌ها (KEYWORD/OPTION SUMMARY)" در اینجا گزینه‌های معتبر آورده شده‌اند. پسوندهای کلیدواژه که در کروکه‌ها قرار دارند اختیاری هستند. مواردی که با گزینه‌های کوتاه خط فرمان مطابقت دارند با '\-' و حرف گزینه مناسب دنبال می‌شوند. اگر گزینه‌ای تنها مربوط به یک حالت خاص عملیاتی باشد، با \&'s' یا 'm' به ترتیب برای حالت تک‌مقصدی (singledrop) یا چندمقصدی (multidrop) مشخص می‌شود. در اینجا گزینه‌های معتبر سراسری آورده شده‌اند: .TS l l l lw34. کلیدواژه گزینه حالت عملکرد _ set daemon \-d \& T{ تنظیم فاصله زمانی بررسی پس‌زمینه بر حسب ثانیه. T} set postmaster \& \& T{ تعیین نام دریافت‌کننده نهایی ایمیل در صورت نبود گیرنده مشخص (پیش‌فرض: کاربری که fetchmail را اجرا می‌کند، "postmaster" در صورت اجرا با کاربر ریشه) T} set bouncemail \& \& T{ هدایت ایمیل‌های خطادار به فرستنده (پیش‌فرض) T} set no bouncemail \& \& T{ هدایت ایمیل‌های خطادار به مدیر محلی ایمیل (مطابق گزینه سراسری 'postmaster' در بالا). T} set no spambounce \& \& T{ برنگرداندن (بونس نکردن) ایمیل‌های مسدودشده به عنوان هرزنامه (پیش‌فرض). T} set spambounce \& \& T{ برگرداندن ایمیل‌های هرزنامه مسدودشده (مطابق گزینه کاربری 'antispam') به مقصد تعیین‌شده در گزینه سراسری 'bouncemail'. هشدار: از این گزینه برای بازگرداندن هرزنامه به فرستنده استفاده نکنید - بیشتر هرزنامه‌ها با آدرس فرستنده جعلی فرستاده می‌شوند و این کار به افراد بی‌گناه آسیب می‌زند. T} set no softbounce \& \& T{ حذف ایمیل‌هایی که تحویل دائمی آن‌ها ناممکن است. توصیه می‌شود در صورت آزمایش کامل پیکربندی، از این گزینه استفاده شود. T} set softbounce \& \& T{ نگه‌داشتن ایمیل‌هایی که تحویل دائمی آن‌ها ناممکن است، به گونه‌ای که گویی خطایی موقت رخ داده است (پیش‌فرض). T} set logfile \-L \& T{ نام فایلی که پیام‌های خطا و وضعیت به آن اضافه می‌شوند. فقط در حالت دیمن و در صورت جدا شدن fetchmail از ترمینال مؤثر است. در صورت فعال بودن، بر \fBset syslog\fP اولویت دارد. T} set pidfile \-p \& T{ نام فایل شناسه فرآیند (PID). T} set idfile \-i \& T{ نام فایلی که فهرست‌های UID در آن ذخیره می‌شوند. T} set syslog \& \& T{ ثبت لاگ خطاها از طریق syslog(3). ممکن است توسط \fBset logfile\fP لغو شود. T} set no syslog \& \& T{ غیرفعال کردن ثبت لاگ خطا از طریق syslog(3) (پیش‌فرض). T} set properties \& \& T{ مقدار رشته‌ای که توسط fetchmail نادیده گرفته می‌شود (ممکن است توسط اسکریپت‌های افزونه استفاده شود). T} .TE در اینجا گزینه‌های معتبر سرور آورده شده‌اند: .TS l l l lw34. کلیدواژه گزینه حالت عملکرد _ via \& \& T{ تعیین نام DNS کارگزار ایمیل، با اولویت بر نام poll T} proto[col] \-p \& T{ تعیین پروتکل (غیرحساس به حروف کوچک و بزرگ): POP2، POP3، IMAP، APOP، KPOP T} local[domains] \& m T{ تعیین دامنه(هایی) که باید محلی در نظر گرفته شوند T} port \& \& T{ تعیین پورت سرویس TCP/IP (منسوخ شده، به جای آن از 'service' استفاده کنید). T} service \-P \& T{ تعیین نام سرویس (مقدار عددی نیز مجاز است و پورت TCP/IP در نظر گرفته می‌شود). T} auth[enticate] \& \& T{ تنظیم نوع احراز هویت (پیش‌فرض 'any') T} timeout \-t \& T{ مهلت زمان عدم فعالیت سرور بر حسب ثانیه (پیش‌فرض ۳۰۰) T} envelope \-E m T{ تعیین نام هدر آدرس پاکت (envelope-address) T} no envelope \& m T{ غیرفعال کردن جستجو برای آدرس پاکت T} qvirtual \-Q m T{ پیشوند دامنه مجازی Qmail برای حذف از نام کاربری T} aka \& m T{ تعیین نام‌های جایگزین DNS برای کارگزار ایمیل T} interface \-I \& T{ تعیین رابط(های) IP که برای انجام poll کارگزار باید فعال باشند T} monitor \-M \& T{ تعیین آدرس IP برای نظارت بر فعالیت T} plugin \& \& T{ تعیین دستوری که اتصال به کارگزار از طریق آن برقرار شود. T} plugout \& \& T{ تعیین دستوری که اتصال به شنونده از طریق آن برقرار شود. T} dns \& m T{ فعال‌سازی جستجوی DNS برای حالت چندمقصدی (پیش‌فرض) T} no dns \& m T{ غیرفعال کردن جستجوی DNS برای حالت چندمقصدی T} checkalias \& m T{ انجام مقایسه بر اساس آدرس IP برای حالت چندمقصدی T} no checkalias \& m T{ انجام مقایسه بر اساس نام برای حالت چندمقصدی (پیش‌فرض) T} uidl \-U \& T{ اجبار POP3 به استفاده از UIDLهای سمت کلاینت (توصیه‌شده) T} no uidl \& \& T{ غیرفعال کردن استفاده POP3 از UIDLهای سمت کلاینت (پیش‌فرض) T} interval \& \& T{ بررسی این سایت فقط در هر N چرخه poll؛ N یک آرگومان عددی است. T} tracepolls \& \& T{ افزودن اطلاعات ردگیری poll به هدر Received T} principal \& \& T{ تنظیم شناسه کاربری (principal) کربروس (فقط با IMAP و kerberos کاربرد دارد) T} esmtpname \& \& T{ تنظیم نام برای احراز هویت RFC2554 به کارگزار ESMTP. T} esmtppassword \& \& T{ تنظیم گذرواژه برای احراز هویت RFC2554 به کارگزار ESMTP. T} bad-header \& \& T{ نحوه برخورد با پیام‌های دارای هدر نادرست. می‌تواند reject (پیش‌فرض) یا accept باشد. T} idletimeout \& \& T{ مهلت زمان انتظار بیکار (به ثانیه)، به --idle رجوع کنید. T} .TE در اینجا توصیف‌ها و گزینه‌های معتبر کاربر آورده شده‌اند: .TS l l l lw34. کلیدواژه گزینه حالت عملکرد _ user[name] \-u \& T{ این توصیف کاربر است و باید در ابتدا پس از توصیف سرور و گزینه‌های احتمالی سرور، و پیش از گزینه‌های کاربر قرار گیرد. در صورت ذکر به تنهایی یا همراه با 'there'، نام کاربری دوردست را تعیین می‌کند، و اگر همراه با 'here' بیاید، نام کاربری محلی را مشخص می‌سازد. T} is \& \& T{ پیوند دادن نام‌های کاربری محلی و دوردست T} to \& \& T{ پیوند دادن نام‌های کاربری محلی و دوردست T} pass[word] \& \& T{ تعیین گذرواژه حساب دوردست T} ssl \& \& T{ اتصال به کارگزار از طریق پروتکل پایه مشخص‌شده با استفاده از رمزنگاری SSL T} sslcert \& \& T{ تعیین فایل گواهی عمومی SSL \fBسمت کلاینت\fP T} sslcertck \& \& T{ فعال‌سازی بررسی دقیق گواهی و قطع اتصال در صورت عدم تأیید. پیش‌فرض از نسخه fetchmail v6.4.0. T} no sslcertck \& \& T{ غیرفعال کردن بررسی دقیق گواهی و اجازه ادامه اتصال در صورت شکست اعتبارسنجی. توصیه نمی‌شود. فقط باید همراه با sslfingerprint استفاده شود. T} sslcertfile \& \& T{ تعیین فایل حاوی گواهی‌های CA مورد اعتماد T} sslcertpath \& \& T{ تعیین دایرکتوری ایجادشده با c_rehash حاوی گواهی‌های CA مورد اعتماد. T} sslcommonname \& \& T{ تعیین نام عمومی (common name) مورد انتظار در گواهی کارگزار برای تطبیق. T} sslfingerprint \& \& T{ تعیین اثرانگشت مورد انتظار گواهی سرور از هش MD5. در صورت عدم تطابق، Fetchmail اتصال را قطع کرده و خطا ثبت می‌کند. T} sslkey \& \& T{ تعیین فایل کلید خصوصی SSL \fBسمت کلاینت\fP T} sslproto \& \& T{ اجبار پروتکل ssl برای اتصال T} folder \-r \& T{ تعیین پوشه دوردست برای پرس‌وجو T} smtphost \-S \& T{ تعیین میزبان(های) smtp برای بازفرستادن T} fetchdomains \& m T{ تعیین دامنه‌هایی که ایمیل‌های آن‌ها باید واکشی شوند T} smtpaddress \-D \& T{ تعیین دامنه‌ای که در خطوط RCPT TO قرار می‌گیرد T} smtpname \& \& T{ تعیین کاربر و دامنه‌ای که در خطوط RCPT TO قرار می‌گیرند T} antispam \-Z \& T{ تعیین اینکه کدام پاسخ‌های بازگشتی SMTP به عنوان مسدودی‌های خط‌مشی ضد هرزنامه تفسیر شوند T} mda \-m \& T{ تعیین MDA برای تحویل محلی T} bsmtp \& \& T{ تعیین فایل دسته‌ای BSMTP برای افزودن به آن T} preconnect \& \& T{ دستوری که قبل از هر اتصال اجرا می‌شود T} postconnect \& \& T{ دستوری که بعد از هر اتصال اجرا می‌شود T} keep \-k \& T{ حذف نکردن پیام‌های دیده‌شده از سرور (برای POP3، استفاده از uidl توصیه می‌شود) T} flush \-F \& T{ تخلیه تمام پیام‌های دیده‌شده پیش از پرس‌وجو (خطرناک) T} limitflush \& \& T{ تخلیه تمام پیام‌های با حجم بیش از حد مجاز پیش از پرس‌وجو T} fetchall \-a \& T{ واکشی تمام پیام‌ها چه دیده‌شده باشند و چه نباشند T} rewrite \& \& T{ بازنویسی آدرس‌های مقصد برای پاسخ (پیش‌فرض) T} stripcr \& \& T{ حذف carriage return از انتهای خطوط T} forcecr \& \& T{ اجبار carriage return در انتهای خطوط T} pass8bits \& \& T{ اجبار ارسال BODY=8BITMIME به شنونده ESMTP T} dropstatus \& \& T{ حذف خطوط Status و X-Mozilla-Status از ایمیل‌های دریافتی T} dropdelivered \& \& T{ حذف خطوط Delivered-To از ایمیل‌های دریافتی T} mimedecode \& \& T{ تبدیل quoted-printable به داده‌های ۸ بیتی در پیام‌های MIME T} idle \& \& T{ انتظار در حالت بیکار برای دریافت پیام‌های جدید پس از هر poll (فقط IMAP) T} forceidle \& \& T{ انتظار در حالت بیکار برای دریافت پیام‌های جدید پس از هر poll (فقط IMAP، اجباری) T} no keep \-K \& T{ حذف پیام‌های دیده‌شده از سرور (پیش‌فرض) T} no flush \& \& T{ تخلیه نکردن پیام‌های دیده‌شده پیش از پرس‌وجو (پیش‌فرض) T} no fetchall \& \& T{ تنها دریافت پیام‌های جدید (پیش‌فرض) T} no rewrite \& \& T{ بازنویسی نکردن هدرها T} no stripcr \& \& T{ حذف نکردن carriage return (پیش‌فرض) T} no forcecr \& \& T{ اجبار نکردن carriage return در انتهای خط (پیش‌فرض) T} no pass8bits \& \& T{ اجبار نکردن ارسال BODY=8BITMIME به شنونده ESMTP (پیش‌فرض) T} no dropstatus \& \& T{ حذف نکردن هدرهای Status (پیش‌فرض) T} no dropdelivered \& \& T{ حذف نکردن هدرهای Delivered\-To (پیش‌فرض) T} no mimedecode \& \& T{ عدم تبدیل quoted-printable به ۸ بیت در پیام‌های MIME (پیش‌فرض) T} no idle \& \& T{ عدم انتظار در حالت بیکار برای پیام‌های جدید پس از هر poll (فقط IMAP) T} limit \-l \& T{ تعیین حد مجاز اندازه پیام T} warnings \-w \& T{ تعیین فاصله زمانی هشدار اندازه پیام T} batchlimit \-b \& T{ حداکثر تعداد پیام برای ارسال در یک اتصال T} fetchlimit \-B \& T{ حداکثر تعداد پیام برای واکشی در یک اتصال T} fetchsizelimit \& \& T{ حداکثر تعداد اندازه‌های پیام برای واکشی در یک تراکنش T} fastuidl \& \& T{ استفاده از جستجوی دودویی برای یافتن اولین پیام دیده‌نشده (فقط POP3) T} expunge \-e \& T{ انجام پاکسازی قطعی (expunge) در هر #امین پیام (فقط IMAP و POP3) T} properties \& \& T{ مقدار رشته‌ای توسط fetchmail نادیده گرفته می‌شود (ممکن است توسط اسکریپت‌های افزونه استفاده شود) T} .TE .PP تمام گزینه‌های کاربر باید با توصیف کاربر (گزینه user یا username) آغاز شده و \fIپس از\fP تمامی توصیف‌ها و گزینه‌های سرور قرار گیرند. .PP در فایل ‎.fetchmailrc‎، آرگومان رشته‌ای 'envelope' می‌تواند با یک عدد که با فاصله از آن جدا شده همراه شود. این عدد، در صورت تعیین، نشان‌دهنده تعداد هدرهایی از این نوع است که باید نادیده گرفته شوند (یعنی آرگومان ۱، دومین هدر از نوع موردنظر را انتخاب می‌کند). این ویژگی گاهی برای نادیده گرفتن هدرهای پاکت جعلی ایجادشده توسط عامل تحویل محلی ISP یا فورواردهای داخلی (مثلاً از طریق سیستم‌های بازرسی ایمیل) مفید است. .SS "کلیدواژه‌های فاقد سوییچ‌های متناظر (Keywords Not Corresponding To Option Switches)" گزینه‌های 'folder' و 'smtphost' (برخلاف معادل‌های خط فرمان خود) می‌توانند فهرستی از نام‌ها را که با فاصله یا کاما از یکدیگر جدا شده‌اند به عنوان ورودی بپذیرند. .PP تمامی گزینه‌ها با آرگومان‌های واضح خط فرمان مطابقت دارند، به جز موارد زیر: \&'via'، 'interval'، 'aka'، 'is'، 'to'، 'dns'/'no dns'، \&'checkalias'/'no checkalias'، 'password'، 'preconnect'، 'postconnect'، \&'localdomains'، 'stripcr'/'no stripcr'، 'forcecr'/'no forcecr'، \&'pass8bits'/'no pass8bits'، 'dropstatus/no dropstatus'، \&'dropdelivered/no dropdelivered'، 'mimedecode/no mimedecode'، 'no idle' و 'no envelope'. .PP گزینه 'via' برای مواقعی است که می‌خواهید بیش از یک پیکربندی با اشاره به یک سایت داشته باشید. اگر این گزینه وجود داشته باشد، آرگومان رشته‌ای آن به عنوان نام واقعی DNS میزبان کارگزار ایمیل برای پرس‌وجو در نظر گرفته خواهد شد. این گزینه بر آرگومان poll اولویت دارد، که می‌تواند صرفاً برچسبی مجزا برای پیکربندی باشد (مثلاً آنچه در خط فرمان برای پرس‌وجوی صریح این میزبان وارد می‌کردید). .PP گزینه 'interval' (که یک آرگومان عددی می‌گیرد) به شما اجازه می‌دهد سرور را در فواصل زمانی کمتری نسبت به فاصله زمانی پایه poll بررسی کنید. اگر عبارت 'interval N' را قید کنید، سروری که این گزینه به آن متصل است تنها در هر N دور چرخه poll بررسی خواهد شد. .SS "گزینه‌های تک‌مقصدی در برابر چندمقصدی (Singledrop versus Multidrop options)" لطفاً در صورتی که قصد استفاده از حالت چندمقصدی را دارید، اطمینان حاصل کنید که بخش با عنوان \fBTHE USE AND ABUSE OF MULTIDROP MAILBOXES \fP را مطالعه کرده‌اید. .PP کلیدواژه‌های 'is' یا 'to' نام(های) محلی (کلاینت) زیر (یا نگاشت‌های نام سرور به نام کلاینت که با = جدا شده‌اند) را با نام کاربری کارگزار ایمیل در مدخل مرتبط می‌سازند. اگر یک فهرست is/to علامت '*' را به عنوان آخرین نام خود داشته باشد، نام‌های ناشناخته به سادگی عبور داده می‌شوند. توجه داشته باشید که تا نسخه 6.3.4 \fBfetchmail\fP (شامل آن)، این فهرست‌ها تنها می‌توانستند شامل بخش‌های محلی نام‌های کاربری باشند (fetchmail تنها بخش قبل از علامت @ را بررسی می‌کرد). نسخه‌های 6.3.5 و جدیدتر \fBfetchmail\fP از آدرس‌های کامل در سمت چپ این نگاشت‌ها پشتیبانی می‌کنند و این نگاشت‌ها بر هرگونه نگاشت 'localdomains'، 'aka'، 'via' یا موارد مشابه اولویت دارند. .PP یک نام محلی واحد می‌تواند برای هدایت ایمیل شما در زمانی که نام کاربری شما در دستگاه کلاینت با نام شما در کارگزار ایمیل متفاوت است، استفاده شود. هنگامی که تنها یک نام محلی وجود دارد، ایمیل بدون توجه به هدرهای Received، To، Cc و Bcc پیام، به آن نام کاربری محلی فوروارد می‌شود. در این حالت، \fBfetchmail\fP هرگز جستجوهای DNS را انجام نمی‌دهد. .PP هنگامی که بیش از یک نام محلی (یا نگاشت نام) وجود داشته باشد، \fBfetchmail\fP ابتدا به هدر پاکت (در صورت پیکربندی) و در غیر این صورت به هدرهای Received، To، Cc و Bcc ایمیل‌های دریافت‌شده نگاه می‌کند (این همان «حالت چندمقصدی» است). این برنامه به دنبال آدرس‌هایی می‌گردد که بخش نام میزبان آن‌ها با نام poll شما یا گزینه‌های 'via'، 'aka' یا 'localdomains' مطابقت داشته باشد، و معمولاً به دنبال بخش‌هایی از نام میزبان می‌گردد که DNS آن‌ها را به عنوان نام‌های مستعار کارگزار ایمیل معرفی می‌کند. برای جزئیات در مورد نحوه مدیریت آدرس‌های منطبق، به توضیحات 'dns'، 'checkalias'، 'localdomains' و 'aka' مراجعه کنید. .PP اگر \fBfetchmail\fP نتواند هیچ نام کاربری کارگزار ایمیل یا آدرس localdomain منطبقی پیدا کند، ایمیل پس زده (بونس) خواهد شد. به طور معمول، ایمیل به فرستنده بازگردانده می‌شود، اما اگر گزینه سراسری 'bouncemail' خاموش باشد، ایمیل به جای آن به مدیر محلی ایمیل (postmaster) تحویل داده خواهد شد. (به گزینه سراسری 'postmaster' نگاه کنید). همچنین به BUGS مراجعه کنید. .PP گزینه 'dns' (که به طور پیش‌فرض روشن است) نحوه بررسی آدرس‌ها از صندوق‌های پستی چندمقصدی را کنترل می‌کند. روشن بودن آن، منطقی را فعال می‌کند که هر آدرس میزبان را که با اعلان‌های 'aka' یا 'localdomains' مطابقت ندارد، از طریق DNS جستجو و بررسی نماید. هنگامی که یک نام کاربری کارگزار ایمیل متصل به یک بخش منطبق از نام میزبان شناسایی شود، نگاشت محلی آن به فهرست دریافت‌کنندگان محلی افزوده می‌شود. .PP گزینه 'checkalias' (به طور پیش‌فرض خاموش) جستجوهای انجام‌شده توسط کلیدواژه 'dns' را در حالت چندمقصدی گسترش می‌دهد و راهکاری برای مدیریت MTAهای دوردستی فراهم می‌کند که خود را با نام متعارفشان (canonical name) معرفی می‌کنند، در حالی که با یک نام مستعار poll می‌شوند. هنگامی که چنین سروری poll می‌شود، بررسی‌ها برای استخراج آدرس پاکت با شکست مواجه شده و \fBfetchmail\fP به تحویل از طریق هدرهای To/Cc/Bcc بازمی‌گردد (به بخش «هدر در برابر آدرس‌های پاکت» در زیر مراجعه کنید). تعیین این گزینه به \fBfetchmail\fP دستور می‌دهد تا تمام آدرس‌های IP مرتبط با هر دو نام poll و نام مورداستفاده توسط MTA دوردست را دریافت کرده و آدرس‌های IP را با یکدیگر مقایسه کند. این قابلیت در شرایطی که سرور دوردست تغییرات مکرر نام متعارف را تجربه می‌کند و در غیر این صورت نیازمند تغییرات مداوم در rcfile است، بسیار مفید واقع می‌شود. در صورت تعیین 'no dns' در rcfile، گزینه 'checkalias' هیچ اثری نخواهد داشت. .PP گزینه 'aka' برای استفاده با صندوق‌های پستی چندمقصدی است. این گزینه به شما امکان می‌دهد فهرستی از نام‌های مستعار DNS را برای یک سرور از پیش اعلان کنید. این یک راهکار بهینه‌سازی است که به شما امکان می‌دهد فضا را با سرعت معاوضه کنید. هنگامی که \fBfetchmail\fP در حین پردازش یک صندوق پستی چندمقصدی، هدرهای پیام را برای یافتن نام‌های کارگزار ایمیل جستجو می‌کند، اعلان پیشاپیش نام‌های رایج می‌تواند آن را از انجام جستجوهای DNS بی‌نیاز کند. توجه: نام‌هایی که به عنوان آرگومان به 'aka' می‌دهید به عنوان پسوند مطابقت داده می‌شوند -- اگر (مثلاً) عبارت 'aka netaxs.com' را مشخص کنید، این نه تنها با نام میزبان netaxs.com، بلکه با هر نام میزبانی که به '‎.netaxs.com‎' ختم شود مطابقت خواهد داشت؛ مانند pop3.netaxs.com و mail.netaxs.com. .PP گزینه 'localdomains' به شما امکان می‌دهد فهرستی از دامنه‌هایی را اعلان کنید که fetchmail باید آن‌ها را محلی در نظر بگیرد. هنگامی که fetchmail در حال تجزیه خطوط آدرس در حالت‌های چندمقصدی است و بخش پایانی یک نام میزبان با یک دامنه محلی اعلان‌شده مطابقت دارد، آن آدرس بدون تغییر به شنونده یا MDA تحویل داده می‌شود (نگاشت‌های نام محلی اعمال \fIنمی‌شوند\fP). .PP اگر از 'localdomains' استفاده می‌کنید، ممکن است لازم باشد 'no envelope' را نیز مشخص کنید که تلاش معمول \fBfetchmail\fP برای استنتاج آدرس پاکت از خط Received یا هدر X-Envelope-To یا هر هدری که قبلاً توسط 'envelope' تنظیم شده است را غیرفعال می‌کند. اگر 'no envelope' را در مدخل پیش‌فرض‌ها تنظیم کرده باشید، می‌توانید با استفاده از 'envelope ' آن را در مدخل‌های جداگانه لغو کنید. به عنوان یک حالت خاص، عبارت 'envelope "Received"' تجزیه پیش‌فرض خطوط Received را بازیابی می‌کند. .PP گزینه \fBpassword\fP نیازمند یک آرگومان رشته‌ای است که گذرواژه مورداستفاده برای سرور این مدخل می‌باشد. .PP کلیدواژه 'preconnect' به شما امکان می‌دهد یک دستور شل را مشخص کنید تا دقیقاً قبل از هر بار برقراری اتصال به کارگزار ایمیل توسط \fBfetchmail\fP اجرا شود. این قابلیت در صورتی که در تلاش برای راه‌اندازی اتصالات امن POP با کمک .BR ssh (1) باشید، می‌تواند بسیار مفید باشد. اگر دستور وضعیتی غیرصفر برگرداند، بررسی (poll) آن کارگزار ایمیل لغو خواهد شد. .PP به طور مشابه، کلیدواژه 'postconnect' به شما امکان می‌دهد یک دستور شل را مشخص کنید تا دقیقاً پس از هر بار قطع اتصال به کارگزار ایمیل اجرا شود. .PP گزینه 'forcecr' کنترل می‌کند که آیا خطوطی که فقط با LF خاتمه یافته‌اند، پیش از فوروارد با CRLF خاتمه داده شوند یا خیر. از نظر فنی و دقیق RFC821 این مورد را الزامی می‌داند، اما MTAهای کمی این الزام را اعمال می‌کنند، بنابراین این گزینه معمولاً خاموش است (تنها یک MTA از این دست، یعنی qmail، در زمان نگارش این متن کاربرد چشمگیری دارد). .PP گزینه 'stripcr' کنترل می‌کند که آیا کاراکترهای carriage return قبل از فوروارد شدن ایمیل واکشی‌شده، از آن حذف شوند یا خیر. معمولاً نیازی به تنظیم این گزینه نیست، زیرا در صورت اعلان یک MDA به صورت پیش‌فرض 'روشن' (حذف CR فعال) و در صورت فوروارد از طریق SMTP به صورت پیش‌فرض 'خاموش' (حذف CR غیرفعال) است. اگر هر دو گزینه 'stripcr' و 'forcecr' روشن باشند، 'stripcr' اولویت خواهد داشت. .PP گزینه 'pass8bits' برای مقابله با برنامه‌های ایمیل مایکروسافت وجود دارد که با بی‌دقتی هدر "Content-Transfer-Encoding: 7bit" را روی همه پیام‌ها می‌چسبانند. در صورت خاموش بودن این گزینه (پیش‌فرض) و وجود چنین هدری، \fBfetchmail\fP مقدار BODY=7BIT را به یک شنونده دارای قابلیت ESMTP اعلان می‌کند؛ این امر باعث ایجاد مشکل برای پیام‌هایی می‌شود که واقعاً از مجموعه‌های نویسه ۸ بیتی ISO یا KOI-8 استفاده می‌کنند، و با حذف بیت‌های بالایی تمام کاراکترها مخدوش خواهند شد. اگر \&'pass8bits' روشن باشد، \fBfetchmail\fP مجبور می‌شود مقدار BODY=8BITMIME را به هر شنونده دارای قابلیت ESMTP اعلان کند. اگر شنونده با داده‌های ۸ بیتی سازگار باشد (همان‌طور که همه شنونده‌های اصلی امروزه این‌گونه هستند)، احتمالاً نتیجه مطلوب حاصل خواهد شد. .PP گزینه 'dropstatus' کنترل می‌کند که آیا خطوط غیرخالی Status و X-Mozilla-Status در ایمیل‌های واکشی‌شده باقی بمانند (پیش‌فرض) یا دور ریخته شوند. نگه‌داشتن آن‌ها به MUA شما اجازه می‌دهد ببیند چه پیام‌هایی (در صورت وجود) در سرور به عنوان دیده‌شده علامت‌گذاری شده بودند. از سوی دیگر، این کار می‌تواند برخی از برنامه‌های اعلان ایمیل جدید را سردرگم کند، چرا که آن‌ها فرض می‌کنند هر چیزی که خط Status دارد قبلاً دیده شده است. (توجه: خطوط خالی Status درج‌شده توسط برخی سرورهای معیوب POP بدون قید و شرط دور ریخته می‌شوند.) .PP گزینه 'dropdelivered' کنترل می‌کند که آیا هدرهای Delivered\-To در ایمیل‌های واکشی‌شده حفظ شوند (پیش‌فرض) یا دور ریخته شوند. این هدرها توسط کارگزارهای ایمیل qmail و Postfix به منظور جلوگیری از ایجاد حلقه‌های ایمیل اضافه می‌شوند، اما اگر بخواهید یک سرور ایمیل را در همان دامنه "آینه‌سازی" کنید، ممکن است مانع کار شما شوند. با احتیاط استفاده کنید. .PP گزینه 'mimedecode' کنترل می‌کند که آیا پیام‌های MIME که از کدگذاری quoted-printable استفاده می‌کنند به صورت خودکار به داده‌های خالص ۸ بیتی تبدیل شوند یا خیر. اگر در حال تحویل ایمیل به یک شنونده سازگار با داده‌های ۸ بیتی و دارای قابلیت ESMTP هستید (که شامل تمام MTAهای اصلی مانند sendmail می‌شود)، این گزینه هدرها و داده‌های پیام quoted-printable را به طور خودکار به داده‌های ۸ بیتی تبدیل کرده و خواندن ایمیل را آسان‌تر می‌سازد. اگر برنامه‌های ایمیل شما نحوه کار با پیام‌های MIME را می‌دانند، به این گزینه نیازی نیست. گزینه mimedecode به طور پیش‌فرض خاموش است، زیرا انجام تبدیل RFC2047 روی هدرها اطلاعات مجموعه نویسه‌ها را دور می‌ریزد و اگر کدگذاری هدرها با کدگذاری بدنه متفاوت باشد، می‌تواند منجر به نتایج نامطلوب شود. .PP گزینه 'idle' برای استفاده با سرورهای IMAP در نظر گرفته شده است که از افزونه دستور IDLE طبق RFC2177 پشتیبانی می‌کنند، اما به طور اکید به آن نیازمند نیست. در صورت فعال بودن، و در صورتی که fetchmail تشخیص دهد IDLE پشتیبانی می‌شود، در پایان هر poll دستور IDLE صادر خواهد شد. این به سرور IMAP می‌گوید که اتصال را باز نگه دارد و هنگام در دسترس بودن ایمیل جدید به کلاینت اطلاع دهد. اگر IDLE پشتیبانی نشود، fetchmail با ارسال دوره‌ای دستور NOOP آن را شبیه‌سازی خواهد کرد. اگر نیاز به بررسی مکرر یک پیوند دارید، IDLE می‌تواند با حذف اتصالات TCP/IP و توالی‌های LOGIN/LOGOUT در پهنای باند صرفه‌جویی کند. از سوی دیگر، یک اتصال IDLE تقریباً تمام زمان fetchmail شما را مصرف خواهد کرد، زیرا هرگز اتصال را قطع نمی‌کند و اجازه نمی‌دهد pollهای دیگر رخ دهند مگر اینکه سرور مهلت IDLE را به پایان برساند. همچنین این گزینه با چندین پوشه کار نمی‌کند؛ تنها اولین پوشه مورد بررسی قرار خواهد گرفت. .PP گزینه 'properties' یک مکانیزم توسعه است. این گزینه یک آرگومان رشته‌ای می‌گیرد که توسط خود fetchmail نادیده گرفته می‌شود. آرگومان رشته‌ای می‌تواند برای ذخیره اطلاعات پیکربندی برای اسکریپت‌هایی که به آن نیاز دارند استفاده شود. به طور ویژه، خروجی گزینه '\-\-configdump' ویژگی‌های مرتبط با یک مدخل کاربر را به راحتی در دسترس یک اسکریپت پایتون قرار می‌دهد. .SS "سایر گزینه‌های کنترل اجرا (Miscellaneous Run Control Options)" کلمات 'here' و 'there' معنای شبیه به زبان انگلیسی و مفیدی دارند. به طور معمول عبارت 'user eric is esr' به این معنی است که ایمیل برای کاربر دوردست 'eric' باید به 'esr' تحویل داده شود، اما می‌توانید با گفتن 'user eric there is esr here' این موضوع را روشن‌تر کنید، یا با گفتن 'user esr here is eric there' آن را معکوس نمایید. .PP شناسه‌های معتبر پروتکل برای استفاده با کلیدواژه 'protocol' عبارتند از: .sp .nf auto (یا AUTO) (منسوخ، در نسخه‌های آینده حذف می‌شود) pop2 (یا POP2) (منسوخ، در نسخه‌های آینده حذف می‌شود) pop3 (یا POP3) sdps (یا SDPS) imap (یا IMAP) apop (یا APOP) kpop (یا KPOP) .fi .sp .PP انواع معتبر احراز هویت عبارتند از 'any'، 'password'، 'kerberos'، \&'kerberos_v4'، 'kerberos_v5' و 'gssapi'، 'cram\-md5'، 'otp'، 'msn' (تنها برای POP3)، 'ntlm'، 'implicit'، 'external' (تنها برای IMAP). نوع 'password' احراز هویت را از طریق ارسال معمول یک گذرواژه مشخص می‌کند (گذرواژه می‌تواند متن ساده یا مشمول رمزنگاری ویژه پروتکل مانند CRAM-MD5 باشد)؛ \&'kerberos' به \fBfetchmail\fP می‌گوید که به جای آن در شروع هر پرس‌وجو سعی کند یک بلیت Kerberos دریافت کرده و یک رشته دلخواه را به عنوان گذرواژه ارسال کند؛ و 'gssapi' به fetchmail می‌گوید که از احراز هویت GSSAPI استفاده کند. برای اطلاعات بیشتر به توضیحات کلیدواژه 'auth' مراجعه کنید. .PP تعیین 'kpop' پروتکل POP3 را روی پورت 1109 با احراز هویت Kerberos V4 تنظیم می‌کند. این پیش‌فرض‌ها ممکن است توسط گزینه‌های بعدی لغو شوند. .PP چندین عبارت گزینه سراسری وجود دارد: عبارت 'set logfile' همراه با یک رشته، همان متغیر سراسری مشخص‌شده توسط ‎\-\-logfile‎ را تنظیم می‌کند. گزینه خط فرمان ‎\-\-logfile‎ بر این مقدار اولویت خواهد داشت. توجه داشته باشید که ‎\-\-logfile‎ تنها در صورتی مؤثر است که fetchmail خود را از ترمینال جدا کند و فایل لاگ قبل از اجرای fetchmail از پیش موجود باشد، و در این حالت بر ‎\-\-syslog‎ اولویت دارد. همچنین، عبارت 'set daemon' فاصله زمانی poll را مانند ‎\-\-daemon‎ تنظیم می‌کند. این مقدار می‌تواند توسط گزینه خط فرمان ‎\-\-daemon‎ لغو شود؛ به ویژه ‎\-\-daemon\~0‎ می‌تواند برای اجبار به اجرای پیش‌زمینه استفاده شود. عبارت 'set postmaster' آدرسی را تعیین می‌کند که در صورت عدم وجود تطابق محلی، ایمیل‌های چندمقصدی به طور پیش‌فرض به آن ارسال می‌شوند. در نهایت، 'set syslog' پیام‌های لاگ را به syslogd(8) می‌فرستد. .SH "اشکال‌زدایی FETCHMAIL (DEBUGGING FETCHMAIL)" .SS "کرش کردن و توقف ناگهانی Fetchmail (Fetchmail crashing)" روش‌های گوناگونی وجود دارد که در آن‌ها fetchmail ممکن است "کرش کند"، یعنی عملکرد آن به طور ناگهانی و غیرمنتظره متوقف شود. یک "کرش" معمولاً به وضعیت خطایی اشاره دارد که نرم‌افزار خود قادر به مدیریت آن نبوده است. یک حالت شکست شناخته‌شده "خطای قطعه‌بندی حافظه" (segmentation fault) یا "سیگنال ۱۱" یا "SIGSEGV" یا به اختصار "segfault" است. این موارد می‌توانند ناشی از مشکلات سخت‌افزاری یا نرم‌افزاری باشند. خطاهای segfault ناشی از نرم‌افزار معمولاً به راحتی و در همان نقطه قابل بازتولید هستند، در حالی که خطاهای segfault ناشی از سخت‌افزار ممکن است با راه‌اندازی مجدد رایانه یا خاموش کردن آن برای چند ساعت برطرف شوند و حتی اگر از نرم‌افزار به همان شکل استفاده کنید، می‌توانند در مکان‌های تصادفی رخ دهند. برای رفع segfaultهای ناشی از سخت‌افزار، قطعه معیوب را پیدا کرده و آن را تعمیر یا تعویض کنید. .UR https://www.bitwizard.nl/sig11 پرسش‌های متداول Sig11 .UE ممکن است در جزئیات به شما کمک کند. برای رفع segfaultهای ناشی از نرم‌افزار، توسعه‌دهندگان ممکن است به یک "ردگیری پشته" (stack backtrace) نیاز داشته باشند. .SS "فعال‌سازی دامپ هسته fetchmail (Enabling fetchmail core dumps)" به طور پیش‌فرض، fetchmail از ایجاد دامپ‌های هسته (core dumps) جلوگیری می‌کند زیرا این فایل‌ها ممکن است حاوی گذرواژه‌ها و سایر اطلاعات حساس باشند. برای اشکال‌زدایی کرش‌های fetchmail، به دست آوردن "ردگیری پشته" از یک دامپ هسته اغلب سریع‌ترین راه برای حل مشکل است، و هنگام ارسال مشکل خود در یک لیست پستی، توسعه‌دهندگان ممکن است از شما یک "backtrace" بخواهند. ۱. برای دریافت backtraceهای مفید، fetchmail باید بدون حذف نمادهای کامپایل (strip) نصب شده باشد. متأسفانه، بیشتر بسته‌های باینری که نصب می‌شوند stripped هستند و فایل‌های هسته حاصل از برنامه‌های بدون نماد بی‌ارزش هستند. بنابراین ممکن است لازم باشد fetchmail را دوباره کامپایل کنید. در بسیاری از سیستم‌ها، می‌توانید دستور زیر را تایپ کنید: .sp .nf file `which fetchmail` .fi .sp تا متوجه شوید که آیا نمادهای fetchmail حذف شده‌اند یا خیر. اگر برنامه شما فاقد حذف نماد (unstripped) بود، مشکلی نیست و ادامه دهید؛ اگر stripped بود، ابتدا باید کد منبع را دوباره کامپایل کنید. معمولاً برای اشکال‌زدایی fetchmail نیازی به نصب آن ندارید. ۲. محیط شل که fetchmail را اجرا می‌کند باید تولید دامپ‌های هسته را فعال کند. نکته کلیدی "حداکثر اندازه فایل هسته" است که معمولاً با ابزاری به نام "limit" یا "ulimit" قابل پیکربندی است. برای جزئیات به مستندات شل خود مراجعه کنید. در شل محبوب bash، دستور "ulimit \-Sc unlimited" اجازه ایجاد دامپ هسته را می‌دهد. ۳. شما باید به fetchmail نیز بگویید که اجازه ایجاد دامپ‌های هسته را بدهد. برای انجام این کار، fetchmail را با گزینه‌های \fB\-d0 \-v\fP اجرا کنید. اغلب آسان‌تر است که \fB\-\-nosyslog \-N\fP را نیز اضافه کنید. در نهایت، باید کرش را بازتولید کنید. می‌توانید به سادگی fetchmail را از دایرکتوری محل کامپایل با تایپ \fB./fetchmail\fP اجرا کنید، بنابراین خط فرمان کامل با \fB./fetchmail \-Nvd0 \&\-\-nosyslog\fP آغاز شده و احتمالاً سایر گزینه‌های شما را فهرست می‌کند. پس از کرش، اشکال‌زدای خود را برای دریافت دامپ هسته اجرا کنید. اشکال‌زدا اغلب GNU GDB خواهد بود؛ سپس می‌توانید (با تنظیم مسیرها در صورت نیاز) دستور \fBgdb ./fetchmail fetchmail.core\fP را وارد کرده و پس از بالا آمدن GDB و خواندن تمام فایل‌هایش، عبارت \fBbacktrace full\fP را تایپ کنید، خروجی را ذخیره نمایید (کپی و پیست کافی است، backtrace توسط یک انسان خوانده خواهد شد) و سپس \fBquit\fP را برای خروج از gdb تایپ کنید. \fBتوجه:\fP در برخی سیستم‌ها، فایل‌های هسته نام‌های متفاوتی دارند؛ ممکن است به جای نام برنامه حاوی یک عدد، یا شماره و نام باشند، اما معمولاً کلمه "core" را به عنوان بخشی از نام خود خواهند داشت. .SH "تعامل با RFC 822 (INTERACTION WITH RFC 822)" هنگام تلاش برای تعیین آدرس مبدأ یک پیام، fetchmail هدرها را به ترتیب زیر بررسی می‌کند: .sp .nf Return-Path: Resent-Sender: (در صورتی که حاوی @ یا ! نباشد نادیده گرفته می‌شود) Sender: (در صورتی که حاوی @ یا ! نباشد نادیده گرفته می‌شود) Resent-From: From: Reply-To: Apparently-From: .fi .sp آدرس مبدأ برای ثبت لاگ و تنظیم آدرس MAIL FROM هنگام فوروارد به SMTP استفاده می‌شود. این ترتیب برای مدیریت مناسب دریافت پیام‌های لیست پستی در حالت چندمقصدی طراحی شده است. هدف این است که اگر آدرس محلی وجود نداشته باشد، پیام برگشتی (bounce) بدون بررسی به نویسنده یا خود لیست بازگردانده نشود، بلکه به مدیر لیست ارسال گردد (که آزاردهندگی کمتری دارد). در حالت چندمقصدی، هدرهای مقصد به شرح زیر پردازش می‌شوند: ابتدا، fetchmail به دنبال هدر مشخص‌شده توسط گزینه 'envelope' می‌گردد تا آدرس گیرنده محلی را تعیین کند. اگر ایمیل به بیش از یک گیرنده ارسال شده باشد، خط Received حاوی هیچ اطلاعاتی در مورد آدرس‌های گیرندگان نخواهد بود. سپس fetchmail به دنبال خطوط :Resent-To، :Resent-Cc و :Resent-Bcc می‌گردد. اگر آن‌ها وجود داشته باشند، باید حاوی گیرندگان نهایی باشند و بر همتایان To:/Cc:/Bcc: خود اولویت دارند. اگر خطوط ‎Resent\-*‎ وجود نداشته باشند، خطوط :To، :Cc، :Bcc و :Apparently-To جستجو می‌شوند. (وجود یک :Resent\-To به این معنا تلقی می‌شود که فرد مورد اشاره در آدرس :To قبلاً نسخه اصلی ایمیل را دریافت کرده است.) .SH "مثال‌های پیکربندی (CONFIGURATION EXAMPLES)" توجه داشته باشید که هرچند در بسیاری از مثال‌های زیر اعلان گذرواژه آمده است، این کار عمدتاً برای مقاصد آموزشی است. پیشنهاد ما این است که جفت‌های نام‌کاربری/گذرواژه را در فایل $HOME/.netrc خود ذخیره کنید، جایی که نه تنها توسط fetchmail بلکه توسط .BR ftp (1) و برنامه‌های دیگر نیز قابل استفاده باشد. قالب کلی به این صورت است: .IP poll \fISERVERNAME\fP protocol \fIPROTOCOL\fP username \fINAME\fP password \fIPASSWORD\fP .PP مثال: .IP .nf poll pop.provider.net protocol pop3 username "jsmith" password "secret1" .fi .PP یا با استفاده از برخی اختصارات: .IP .nf poll pop.provider.net proto pop3 user "jsmith" password "secret1" .fi .PP می‌توان چندین سرور را فهرست کرد: .IP .nf poll pop.provider.net proto pop3 user "jsmith" pass "secret1" poll other.provider.net proto pop2 user "John.Smith" pass "My^Hat" .fi .PP در اینجا همان نسخه با فاصله‌گذاری بیشتر و برخی کلمات اختیاری (noise words) آورده شده است: .IP .nf poll pop.provider.net proto pop3 user "jsmith", with password secret1, is "jsmith" here; poll other.provider.net proto pop2: user "John.Smith", with password "My^Hat", is "John.Smith" here; .fi .PP اگر نیاز دارید در یک رشته پارامتر فاصله خالی بگنجانید یا آن را با عدد شروع کنید، رشته را درون علامت نقل‌قول دوتایی قرار دهید. به این صورت: .IP .nf poll mail.provider.net with proto pop3: user "jsmith" there has password "4u but u cannot krak this" is jws here and wants mda "/bin/mail" .fi .PP می‌توانید یک توصیف سرور اولیه داشته باشید که به جای 'poll' و نام سرور، با کلمه کلیدی \&'defaults' آغاز شود. چنین رکوردی به عنوان مقادیر پیش‌فرض برای استفاده در تمام پرس‌وجوها تفسیر می‌شود و می‌تواند با توضیحات اختصاصی هر سرور بازنویسی شود. بنابراین می‌توانید بنویسید: .IP .nf defaults proto pop3 user "jsmith" poll pop.provider.net pass "secret1" poll mail.provider.net user "jjsmith" there has password "secret2" .fi .PP امکان تعیین بیش از یک کاربر برای هر سرور وجود دارد. کلمه کلیدی 'user' ابتدای توصیف یک کاربر می‌آید و هر مشخصه کاربری در یک مدخل چندکاربره باید شامل آن باشد. این هم یک مثال: .IP .nf poll pop.provider.net proto pop3 port 3111 user "jsmith" with pass "secret1" is "smith" here user jones with pass "secret2" is "jjones" here keep .fi .PP این پیکربندی نام کاربری محلی 'smith' را به نام کاربری 'jsmith' در سرور pop.provider.net و نام کاربری محلی 'jjones' را به نام کاربری 'jones' در سرور pop.provider.net مرتبط می‌کند. نامه‌های مربوط به 'jones' پس از بارگیری روی سرور باقی می‌مانند. .PP در اینجا ظاهر یک پیکربندی ساده برای واکشی از صندوق پستی چندمقصدی (multidrop) آورده شده است: .IP .nf poll pop.provider.net: user maildrop with pass secret1 to golux 'hurkle'='happy' snark here .fi .PP این دستور مشخص می‌کند که صندوق پستی حساب 'maildrop' روی سرور یک صندوق چندمقصدی است، و پیام‌های درون آن باید برای یافتن نام‌های کاربری سرور شامل 'golux' ،'hurkle' و 'snark' تجزیه شوند. همچنین تعیین می‌کند که 'golux' و 'snark' روی کلاینت همان نام روی سرور را دارند، اما نامه‌های مربوط به کاربر 'hurkle' روی سرور باید به کاربر 'happy' در کلاینت تحویل داده شوند. .PP \fBتوجه داشته باشید\fP که \fBfetchmail\fP تا نسخه ۶.۳.۴ اجازه استفاده از مشخصات کامل user@domain را در اینجا نمی‌داد و این موارد هرگز مطابقت پیدا نمی‌کردند. \fIFetchmail\fP نسخه ۶.۳.۵ و جدیدتر از مشخصات user@domain در سمت چپ نگاشت کاربر پشتیبانی می‌کنند. .PP در اینجا نمونه‌ای از نوع دیگری از اتصال چندمقصدی آورده شده است: .IP .nf poll pop.provider.net localdomains loonytoons.org toons.org envelope X-Envelope-To user maildrop with pass secret1 to * here .fi .PP این نیز نشان می‌دهد که صندوق پستی حساب 'maildrop' روی سرور یک صندوق چندمقصدی است. این پیکربندی به fetchmail می‌گوید که هر نشانی در دامنه‌های loonytoons.org یا toons.org (از جمله نشانی‌های زیردامنه مانند \&'joe@daffy.loonytoons.org') باید بدون تغییر به شنونده محلی SMTP ارسال شود. در صورت انجام این کار، مراقب حلقه‌های ایمیلی (mail loops) باشید! .PP این نمونه‌ای از پیکربندی با استفاده از ssh و گزینه plugin است. پرس‌وجوها مستقیماً روی stdin و stdout برنامه imapd از طریق ssh انجام می‌شوند. توجه داشته باشید که در این پیکربندی، احراز هویت IMAP را می‌توان نادیده گرفت. .IP .nf poll mailhost.net with proto imap: plugin "ssh %h /usr/sbin/imapd" auth implicit; user esr is esr here .fi .SH "استفاده و سوءاستفاده از صندوق‌های پستی چندمقصدی (THE USE AND ABUSE OF MULTIDROP MAILBOXES)" از ویژگی چند گیرنده محلی با احتیاط استفاده کنید؛ ممکن است به شما ضربه بزند. تمامی ویژگی‌های چندمقصدی (multidrop) در حالت‌های ETRN و ODMR بی‌اثر هستند. همچنین توجه داشته باشید که در حالت چندمقصدی ممکن است نامه‌های تکراری حذف شوند. یک نامه در صورتی تکراری در نظر گرفته می‌شود که نشانی گیرنده پاکت (envelope) قابل تشخیصی نداشته باشد، هدری دقیقاً مشابه پیام ماقبل خود داشته باشد و دارای بیش از یک مخاطب باشد. چنین توالی‌هایی از پیام‌ها ممکن است زمانی تولید شوند که نسخه‌هایی از یک پیام که به چندین کاربر ارسال شده است، به یک صندوق چندمقصدی تحویل داده شوند. (دقیق‌تر بگوییم، fetchmail نسخه‌های ۶.۲.۵ تا 6.4.X از هش MD5 هدر خام پیام استفاده می‌کنند و فقط fetchmail نسخه 6.4.16+ این موضوع را به درستی مستند کرده است. نسخه 5.0.8 (۱۹۹۹-۰۹-۱۴) تا ۶.۲.۴ فقط از هدر Message-ID استفاده می‌کردند. نسخه‌های ۵.۰.۷ و قدیمی‌تر نامه‌های تکراری را حذف نمی‌کردند.) توجه داشته باشید که این کد حذف تکرارها با بررسی کل هدر بسیار سخت‌گیرانه عمل می‌کند و ممکن است در عمل بسیاری از تکرارها را حذف نکند — برای مثال، اگر هدرهای X-Original-To یا Delivered-To متفاوتی وجود داشته باشد. این رفتار در چنین موقعیت‌هایی عمدی و درست است: هر جا اطلاعات پاکت در دسترس باشد، باید برای تحویل مطمئن پیام‌های لیست پستی و رونوشت پنهان (Bcc) استفاده شود. برای پیشنهادات به زیربخش «حذف ایمیل‌های تکراری در حالت چندمقصدی» در زیر مراجعه کنید. .SS "نشانی‌های هدر در برابر نشانی‌های پاکت (Header versus Envelope addresses)" مشکل بنیادین این است که با انداختن نامه‌های چندین نفر توسط سرور ایمیل درون یک صندوق پستی واحد، ممکن است اطلاعات بالقوه حیاتی درباره اینکه هر نامه واقعاً به چه کسی ارسال شده بود را دور ریخته باشید (یعنی «نشانی پاکت» یا envelope address، در مقابل نشانی‌های هدر در خطوط RFC822 To/Cc — زیرا اطلاعات Bcc در سمت گیرنده در دسترس نیست). این «نشانی پاکت» همان نشانی‌ای است که برای بازهدایت صحیح ایمیل به آن نیاز دارید. .PP گاهی اوقات \fBfetchmail\fP می‌تواند نشانی پاکت را استنتاج کند. اگر MTA سرور ایمیل \fBsendmail\fP باشد و پیام فقط یک گیرنده داشته باشد، MTA یک عبارت 'by/for' را در هدر Received ثبت کرده است که گیرنده پاکت را مشخص می‌کند. اما این روش برای سایر MTAها یا در صورتی که بیش از یک گیرنده وجود داشته باشد به طور مطمئن کار نمی‌کند. به طور پیش‌فرض، \fBfetchmail\fP در این خطوط به دنبال نشانی‌های پاکت می‌گردد؛ می‌توانید این پیش‌فرض را با \&\-E "Received" یا 'envelope Received' بازیابی کنید. .PP \fBبه عنوان یک جایگزین بهتر،\fP برخی از شنوندگان SMTP و/یا سرورهای ایمیل هدری را در هر پیام درج می‌کنند که حاوی نسخه‌ای از نشانی‌های پاکت است. این هدر (در صورت وجود) اغلب 'X\-Original\-To' ،'Delivered\-To' یا \&'X\-Envelope\-To' است. پیش‌فرض fetchmail در این مورد را می‌توان با گزینه \-E یا 'envelope' تغییر داد. توجه داشته باشید که نوشتن چنین هدر پاکتی نام گیرندگان (شامل گیرندگان رونوشت پنهان) را برای تمام دریافت‌کنندگان پیام فاش می‌کند، بنابراین سرور بالادست باید به ازای هر گیرنده یک نسخه از پیام ذخیره کند تا مشکل حریم خصوصی ایجاد نشود. .PP برنامه Postfix، از نسخه ۲.۰ به بعد، یک هدر X\-Original\-To: می‌نویسد که حاوی نسخه‌ای از پاکت به همان شکلی است که دریافت شده بود. .PP برنامه‌های Qmail و Postfix عموماً هنگام تحویل پیام به صف محلی، هدر 'Delivered\-To' را می‌نویسند و از آن برای جلوگیری از حلقه‌های ایمیلی استفاده می‌کنند. با این حال، دامنه‌های مجازی Qmail نام کاربری را با رشته‌ای که معمولاً با دامنه کاربر مطابقت دارد پیشوند می‌زنند. برای حذف این پیشوند می‌توانید از گزینه \-Q یا 'qvirtual' استفاده کنید. .PP متأسفانه گاهی هیچ‌یک از این روش‌ها کارساز نیست. این نقطه‌ای است که باید با ارائه‌دهنده اینترنت (ISP) خود تماس بگیرید و از آن‌ها بخواهید چنین هدر پاکتی را ارائه دهند، و در این وضعیت نباید از صندوق چندمقصدی استفاده کنید. وقتی همه این‌ها شکست بخورند، fetchmail باید به محتویات هدرهای To/Cc متوسل شود (هدرهای Bcc در دسترس نیستند - پایین را ببینید) تا گیرندگان را تشخیص دهد -- و این روش نامطمئن است. به ویژه، نرم‌افزارهای فهرست پستی اغلب نامه‌ها را تنها با نشانی پخش همگانی لیست در هدر To: ارسال می‌کنند. .PP \fBتوجه داشته باشید که نسخه آینده \fBfetchmail\fP ممکن است پردازش هدرهای To/Cc را حذف کند!\fP .PP وقتی \fBfetchmail\fP نتواند یک نشانی گیرنده محلی را استنتاج کند، و نشانی گیرنده مورد نظر فردی غیر از کاربر اجراکننده fetchmail باشد، \fBنامه گم خواهد شد.\fP این همان چیزی است که استفاده از ویژگی چندمقصدی را بدون اطلاعات پاکت مناسب پرریسک می‌کند. .PP مشکل مرتبط دیگر این است که وقتی پیامی را به صورت رونوشت پنهان (Bcc) ارسال می‌کنید، اطلاعات Bcc \fIتنها\fP به عنوان نشانی پاکت منتقل می‌شود (توسط سرور ایمیل فرستنده از هدرها حذف می‌شود، بنابراین fetchmail تنها در صورتی می‌تواند آن را ببیند که هدر X\-Envelope\-To وجود داشته باشد). بنابراین، ارسال رونوشت پنهان به شخصی که نامه‌هایش را از طریق پیوند چندمقصدی fetchmail دریافت می‌کند ناموفق خواهد بود مگر اینکه سرور ایمیل به طور مرتب هدر X\-Envelope\-To یا معادل آن را درون پیام‌های صندوق پستی شما بنویسد. .PP \fBدر نتیجه، فهرست‌های پستی و نامه‌های دارای Bcc تنها در صورتی به درستی کار می‌کنند که سروری که از آن دریافت می‌کنید:\fP .IP (1) \fBبه ازای هر گیرنده در دامنه شما، یک نسخه از پیام را ذخیره کند و\fP .IP (2) \fBاطلاعات پاکت را در یک هدر ویژه (X\-Original\-To، Delivered\-To، X\-Envelope\-To) ثبت نماید.\fP .SS "روش‌های مناسب استفاده از صندوق‌های پستی چندمقصدی (Good Ways To Use Multidrop Mailboxes)" از چندین نام محلی می‌توان برای مدیریت یک لیست پستی از سمت کلاینت در یک جمع‌آوری \fBfetchmail\fP استفاده کرد. فرض کنید نام کاربری شما \&'esr' است و می‌خواهید هم نامه‌های خود را تحویل بگیرید و هم یک لیست پستی به نام (مثلاً) "fetchmail-friends" را نگهداری کنید، و می‌خواهید لیست نام‌های مستعار (alias) را روی سیستم کلاینت خود نگه دارید. .PP روی سرور خود می‌توانید نام مستعار 'fetchmail\-friends' را به 'esr' ارجاع دهید؛ سپس در فایل \fI.fetchmailrc\fP خود عبارت 'to esr fetchmail\-friends here' را اعلام کنید. سپس، وقتی نامه‌ای شامل 'fetchmail\-friends' به عنوان یک نشانی محلی واکشی می‌شود، نام لیست به انتهای لیست گیرندگانی که شنونده SMTP شما می‌بیند افزوده خواهد شد. بنابراین فرایند بسط نام مستعار به صورت محلی انجام می‌شود. حتماً نام 'esr' را در بسط محلی نام‌های مستعار fetchmail\-friends بگنجانید، در غیر این صورت نامه‌هایی را که فقط به لیست ارسال شده‌اند هرگز نخواهید دید. همچنین مطمئن شوید که شنونده شما گزینه "me-too" را فعال کرده باشد (گزینه خط فرمان \-oXm در sendmail یا اعلان OXm) تا نام شما از بسط نام‌های مستعار در پیام‌هایی که ارسال می‌کنید حذف نشود. .PP با این حال، این ترفند بدون مشکل نیست. وقتی پیامی وارد شود که فقط به یک لیست پستی ارسال شده باشد و شما آن را به عنوان یک نام محلی تعریف \fIنکرده\fP باشید، متوجه مشکل خواهید شد. هر یک از این پیام‌ها دارای یک هدر 'X\-Fetchmail\-Warning' خواهند بود که به این دلیل ایجاد می‌شود که fetchmail نمی‌تواند یک نام محلی معتبر در نشانی‌های گیرنده پیدا کند. چنین پیام‌هایی به طور پیش‌فرض (همان‌طور که در بالا توضیح داده شد) برای کاربر محلی اجراکننده \fBfetchmail\fP ارسال می‌شوند، اما برنامه راهی ندارد که بداند آیا این کار واقعاً درست است یا خیر. .SS "روش‌های نامناسب و سوءاستفاده از صندوق‌های پستی چندمقصدی (Bad Ways To Abuse Multidrop Mailboxes)" صندوق‌های پستی چندمقصدی و اجرای \fBfetchmail\fP برای سرویس‌دهی به چندین کاربر در حالت دیمن (daemon) با یکدیگر سازگار نیستند. مشکل بار دیگر نامه‌های دریافتی از لیست‌های پستی است که معمولاً نشانی گیرنده فردی روی آن‌ها درج نشده است. مگر اینکه \fBfetchmail\fP بتواند نشانی پاکت را استنتاج کند، چنین نامه‌هایی فقط به حسابی که fetchmail را اجرا می‌کند (احتمالاً root) تحویل داده می‌شوند. همچنین کاربرانی که رونوشت پنهان (Bcc) دریافت کرده‌اند به احتمال زیاد اصلاً نامه‌های خود را نخواهند دید. .PP اگر وسوسه شده‌اید که از \fBfetchmail\fP برای دریافت ایمیل چندین کاربر از یک صندوق پستی واحد از طریق POP یا IMAP استفاده کنید، دوباره فکر کنید (و بخش مربوط به نشانی‌های هدر و پاکت را در بالا مجدداً مطالعه کنید). هوشمندانه‌تر این است که اجازه دهید ایمیل‌ها در صف سرور ایمیل باقی بمانند و از حالت‌های ETRN یا ODMR در fetchmail برای راه‌اندازی دوره‌ای ارسال SMTP استفاده کنید (البته این بدان معناست که باید با فاصله‌های زمانی کوتاه‌تر از مدت زمان انقضای سرور، عمل بررسی را انجام دهید). اگر نمی‌توانید این سازوکار را ترتیب دهید، راه‌اندازی فید UUCP را امتحان کنید. .PP اگر کاملاً \fIمجبورید\fP از صندوق چندمقصدی برای این منظور استفاده کنید، مطمئن شوید که سرور ایمیل شما هدر نشانی پاکت را می‌نویسد به طوری که fetchmail بتواند آن را ببیند. در غیر این صورت، قطعاً نامه‌ها را \fIاز دست خواهید داد\fP و این مسئله برایتان دردسرساز \fIخواهد شد\fP. .SS "افزایش سرعت بررسی صندوق‌های چندمقصدی (Speeding Up Multidrop Checking)" به طور معمول، هنگامی که چندین کاربر تعریف می‌شوند، \fBfetchmail\fP نشانی‌های گیرنده را همان‌طور که در بالا شرح داده شد استخراج می‌کند و بخش میزبان (host part) هر کدام را از طریق DNS بررسی می‌کند تا ببیند آیا نام مستعاری از سرور ایمیل است یا خیر. در صورت تطابق، نگاشت نام‌ها طبق اعلان "to ... here" انجام شده و نامه به صورت محلی تحویل داده می‌شود. .PP این روش راحت اما کند است. برای افزایش سرعت، نام‌های مستعار سرور ایمیل را از قبل با 'aka' اعلان کنید؛ این نام‌ها قبل از انجام جستجوهای DNS بررسی می‌شوند. اگر مطمئن هستید که فهرست aka شما شامل \fBتمام\fP نام‌های مستعار DNS سرور ایمیل (و تمام رکوردهای MX که به آن اشاره دارند - توجه داشته باشید که این ممکن است در نسخه آینده تغییر کند) است، می‌توانید 'no dns' را اعلام کنید تا جستجوهای DNS کاملاً غیرفعال شوند و \fIتنها\fP با فهرست aka مطابقت داده شود. .SS "حذف ایمیل‌های تکراری در حالت چندمقصدی (Duplicate suppression on multidrop)" اگر کد حذف تکراری‌های fetchmail برای حساب چندمقصدی شما فعال نمی‌شود، گزینه‌های دیگر استفاده از sieve یا به عنوان مثال بسته maildrop از Courier (و به ویژه برنامه reformail آن با گزینه \-D) به عنوان عامل تحویل (MDA) است (چه از طریق fetchmail و چه از طریق سرور ایمیل محلی شما که fetchmail نامه‌ها را به آن تزریق می‌کند). .SH "پروتکل ساکس (SOCKS)" پشتیبانی از socks4/5 یک گزینه پیکربندی در \fBزمان کامپایل\fP است. پس از کامپایل، fetchmail همیشه از کتابخانه‌ها و پیکربندی socks موجود در سیستم شما استفاده خواهد کرد و هیچ سوئیچ زمان اجرایی در fetchmail برای آن وجود ندارد - اما همچنان می‌توانید SOCKS را پیکربندی کنید: می‌توانید مشخص کنید کدام فایل پیکربندی SOCKS استفاده شود با قرار دادن آن در متغیر محیطی \fBSOCKS_CONF\fP. برای مثال، اگر می‌خواهید پراکسی SOCKS را کاملاً دور بزنید و fetchmail مستقیماً متصل شود، می‌توانید SOCKS_CONF=/dev/null را در محیط ارسال کنید، به عنوان مثال (گزینه‌های معمول خط فرمان خود را - در صورت وجود - به انتهای این خط اضافه کنید): .nf env SOCKS_CONF=/dev/null fetchmail .fi .SH "کدهای خروج (EXIT CODES)" برای تسهیل استفاده از \fBfetchmail\fP در اسکریپت‌های شل، یک کد وضعیت خروج بازگردانده می‌شود تا نشان دهد در طول یک اتصال معین چه اتفاقی رخ داده است. .PP کدهای خروج بازگردانده‌شده توسط \fBfetchmail\fP به شرح زیر است: .IP 0 یک یا چند پیام با موفقیت دریافت شدند (یا اگر گزینه \-c انتخاب شده بود، پیام‌ها در انتظار یافت شدند اما دریافت نشدند). .IP 1 هیچ نامه‌ای در انتظار دریافت نبود. (ممکن است نامه‌های قدیمی همچنان روی سرور وجود داشته باشند ولی برای دریافت انتخاب نشده باشند.) اگر نمی‌خواهید وضعیت «نبود نامه» به عنوان یک خطا تلقی شود (مثلاً برای کارهای cron)، از یک شل سازگار با POSIX استفاده کنید و عبارت زیر را: .nf || [ $? \-eq 1 ] .fi به انتهای خط فرمان fetchmail اضافه کنید. توجه داشته باشید که این کار مقدار ۰ را دست‌نخورده باقی می‌گذارد، ۱ را به ۰ نگاشت می‌کند و سایر کدها را به ۱ تبدیل می‌کند. همچنین مورد #C8 را در FAQ ببینید. .IP 2 هنگام تلاش برای باز کردن یک سوکت جهت دریافت ایمیل، خطایی رخ داد. اگر نمی‌دانید سوکت چیست، نگران نباشید -- فقط آن را به عنوان یک «خطای غیرقابل جبران» در نظر بگیرید. این خطا همچنین می‌تواند به دلیل عدم درج پروتکل مورد نظر fetchmail در /etc/services باشد. .IP 3 مرحله احراز هویت کاربر ناموفق بود. این معمولاً به این معنی است که نام کاربری، گذرواژه یا شناسه APOP نادرست مشخص شده است. یا ممکن است به این معنی باشد که سعی کرده‌اید fetchmail را در شرایطی اجرا کنید که ورودی استاندارد به یک ترمینال متصل نبوده و نتوانسته گذرواژه گم‌شده را درخواست کند. .IP 4 نوعی خطای مهلک در پروتکل شناسایی شد. .IP 5 یک خطای نحوی در آرگومان‌های داده‌شده به \fBfetchmail\fP وجود داشت، یا یک دستور قبل یا بعد از اتصال (pre- یا post-connect) با شکست مواجه شد. .IP 6 فایل کنترل اجرا دسترسی‌ها و مجوزهای نادرستی داشت. .IP 7 یک وضعیت خطا توسط سرور گزارش شد. همچنین در صورتی که \fBfetchmail\fP هنگام انتظار برای سرور دچار اتمام مهلت زمانی (timeout) شود، ممکن است این کد فعال شود. .IP 8 خطای انحصار در سمت کلاینت. این بدان معنی است که \fBfetchmail\fP یا نسخه دیگری از خود را در حال اجرا پیدا کرده است، یا به شکلی دچار شکست شده که مطمئن نیست آیا نسخه دیگری در حال اجراست یا خیر. .IP 9 مرحله احراز هویت کاربر ناموفق بود زیرا سرور با "lock busy" پاسخ داد. پس از یک مکث کوتاه دوباره تلاش کنید! این خطا برای همه پروتکل‌ها یا همه سرورها پیاده‌سازی نشده است. اگر برای سرور شما پیاده‌سازی نشده باشد، به جای آن کد "3" بازگردانده می‌شود (بالا را ببینید). ممکن است هنگام گفتگو با qpopper یا سایر سرورهایی که با "lock busy" یا متنی مشابه شامل کلمه "lock" پاسخ می‌دهند، برگردانده شود. .IP 10 اجرای \fBfetchmail\fP هنگام تلاش برای باز کردن پورت SMTP یا انجام یک تراکنش با شکست مواجه شد. .IP 11 خطای مهلک DNS. برنامه Fetchmail هنگام انجام جستجوی DNS در هنگام راه‌اندازی با خطا مواجه شد و نتوانست ادامه دهد. .IP 12 فایل دسته‌ای BSMTP باز نشد. .IP 13 فرآیند واکشی به دلیل محدودیت تعداد دریافت خاتمه یافت (گزینه \-\-fetchlimit را ببینید). .IP 14 نشان‌دهنده مشغول بودن سرور (Server busy). .IP 23 خطای داخلی. باید پیامی با جزئیات را در خروجی خطای استاندارد مشاهده کنید. .IP "24 - 26, 28, 29" این‌ها کدهای داخلی هستند و نباید به صورت بیرونی ظاهر شوند. .PP هنگامی که \fBfetchmail\fP از بیش از یک میزبان پرس‌وجو می‌کند، در صورتی که \fIهر\fP پرس‌وجویی با موفقیت ایمیل را دریافت کند، وضعیت بازگشتی 0 خواهد بود. در غیر این صورت، وضعیت خطای بازگردانده‌شده مربوط به آخرین میزبانی است که از آن پرس‌وجو شده است. .SH "فایل‌ها (FILES)" .TP 5 ~/.fetchmailrc, $HOME/.fetchmailrc, $HOME_ETC/.fetchmailrc, \ $FETCHMAILHOME/fetchmailrc فایل پیش‌فرض کنترل اجرا (مکان را می‌توان با متغیرهای محیطی تغییر داد) .TP 5 ~/.fetchids, $HOME/.fetchids, $HOME_ETC/.fetchids, $FETCHMAILHOME/.fetchids مکان پیش‌فرض فایل ثبت آخرین شناسه‌های یکتای پیام (UID) دیده شده به ازای هر میزبان. (مکان را می‌توان با متغیرهای محیطی تغییر داد) .TP 5 ~/.fetchmail.pid, $HOME/.fetchmail.pid, $HOME_ETC/.fetchmail.pid, \ $FETCHMAILHOME/fetchmail.pid مکان پیش‌فرض فایل قفل (که گاهی pidfile یا فایل PID نامیده می‌شود، گزینه pidfile را ببینید) برای کمک به جلوگیری از اجراهای همزمان (حالت غیر root). (مکان را می‌توان با متغیرهای محیطی تغییر داد) .TP 5 ~/.netrc, $HOME/.netrc, $HOME_ETC/.netrc فایل کنترل اجرای FTP شما که (در صورت وجود) به عنوان آخرین راهکار قبل از درخواست تعاملی، برای یافتن گذرواژه‌ها جستجو می‌شود. (مکان را می‌توان با متغیرهای محیطی تغییر داد) .TP 5 /var/run/fetchmail.pid فایل قفل (pidfile) برای کمک به جلوگیری از اجراهای همزمان (حالت root، سیستم‌های لینوکس). .TP 5 /etc/fetchmail.pid فایل قفل (pidfile) برای کمک به جلوگیری از اجراهای همزمان (حالت root، سیستم‌های بدون /var/run). .SH "محیط (ENVIRONMENT)" رفتار Fetchmail را می‌توان با ارائه متغیرهای محیطی به آن تغییر داد. برخی ممکن است عملکرد کتابخانه‌هایی را که fetchmail با آن‌ها پیوند خورده است، مانند OpenSSL، تغییر دهند. توجه داشته باشید که در حالت دیمن، باید پردازش پس‌زمینه دیمن را متوقف کرده و یک دیمن جدید fetchmail را اجرا کنید تا تغییرات محیطی اعمال شوند. .IP \fBFETCHMAILHOME\fP اگر این متغیر محیطی روی یک نام دایرکتوری معتبر و موجود تنظیم شده باشد، fetchmail فایل‌های $FETCHMAILHOME/fetchmailrc (در این حالت نقطه وجود ندارد)، $FETCHMAILHOME/.fetchids (با حفظ نقطه) و $FETCHMAILHOME/fetchmail.pid (بدون نقطه) را به جای دایرکتوری خانگی کاربر می‌خواند. فایل .netrc بدون توجه به تنظیم FETCHMAILHOME، همیشه در دایرکتوری خانگی کاربر فراخوان (یا $HOME_ETC) جستجو می‌شود. .IP \fBFETCHMAILUSER\fP اگر این متغیر محیطی تنظیم شده باشد، به عنوان نام کاربر فراخوان (نام محلی پیش‌فرض) برای مقاصدی مانند ارسال اعلان‌های خطا از طریق ایمیل استفاده می‌شود. در غیر این صورت، اگر متغیر LOGNAME یا USER به درستی تنظیم شده باشد (مثلاً UID مربوطه با شناسه کاربری نشست مطابقت داشته باشد)، از آن نام به عنوان نام محلی پیش‌فرض استفاده می‌شود. در غیر این صورت \fBgetpwuid\fP(3) باید بتواند یک مدخل گذرواژه برای شناسه نشست بازیابی کند (این منطق دقیق به گونه‌ای طراحی شده است که حالت چند نام به ازای یک شناسه کاربری را به خوبی مدیریت کند). .IP \fBFETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE\fP (از نسخه ۶.۳.۲۲): اگر این متغیر محیطی تنظیم شده و خالی نباشد، fetchmail اقدام متقابل در برابر حمله SSL CBC IV را غیرفعال می‌کند (با تنظیم SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS). این یک ریسک امنیتی است، اما ممکن است برای اتصال به برخی سرورهای ناسازگار با استانداردها ضروری باشد. برای جزئیات به فایل NEWS و fetchmail-SA-2012-01.txt مراجعه کنید. نسخه‌های قدیمی‌تر fetchmail (نسخه ۶.۳.۲۱ و قدیمی‌تر) این اقدام متقابل را غیرفعال می‌کردند، اما نسخه ۶.۳.۲۲ به عنوان یک اقدام احتیاطی ایمنی دیگر این کار را انجام نمی‌دهد. .IP \fBFETCHMAIL_POP3_FORCE_RETR\fP (از نسخه ۶.۳.۹): اگر این متغیر محیطی اصلاً تعریف شده باشد (حتی اگر خالی باشد)، fetchmail از دستور POP3 TOP صرف‌نظر کرده و همیشه از RETR استفاده می‌کند. این می‌تواند به عنوان یک راهکار موقت در زمانی که TOP به درستی کار نمی‌کند استفاده شود. .IP \fBFETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS\fP (از نسخه ۶.۳.۱۷): اگر این متغیر محیطی تنظیم شده و خالی نباشد، fetchmail همیشه مکان‌های گواهی مورد اعتماد X.509 پیش‌فرض را برای گواهی‌های مرجع صدور گواهی (CA) در SSL/TLS بارگیری می‌کند، حتی اگر \fB\-\-sslcertfile\fP و \fB\-\-sslcertpath\fP داده شده باشند. مکان‌های اخیر بر مکان‌های پیش‌فرض سیستم اولویت دارند. این گزینه در صورتی مفید است که گواهی‌های خراب در دایرکتوری‌های سیستم وجود داشته باشد و کاربر مجوزهای سرپرست برای رفع مشکل را نداشته باشد. .IP \fBFETCHMAIL_WOLFSSL_DEBUG\fP (از نسخه ۶.۴.۲۵): اگر fetchmail با wolfSSL کامپایل و پیوند شده باشد، اگر wolfSSL با \-\-enable\-debug ساخته شده باشد، و اگر این متغیر محیطی تنظیم شده و خالی نباشد، حالت اشکال‌زدایی wolfSSL فعال می‌شود. این کار مقادیر زیادی خروجی اشکال‌زدایی را به stderr ارسال می‌کند. .IP \fBHOME\fP (مستندشده از نسخه ۶.۴.۱): این متغیر معمولاً روی دایرکتوری خانگی کاربر تنظیم می‌شود. اگر روی دایرکتوری متفاوتی نسبت به آنچه در پایگاه‌داده گذرواژه است تنظیم شود، HOME اولویت دارد. .IP \fBHOME_ETC\fP (مستندات اصلاح شده تا با رفتار کد از نسخه ۶.۴.۱ مطابقت داشته باشد): اگر متغیر HOME_ETC تنظیم شده باشد، دیدگاه fetchmail از $HOME را بازنویسی می‌کند، یعنی fetchmail فایل‌های .fetchmailrc ،.fetchids ،.fetchmail.pid و .netrc را از $HOME_ETC به جای $HOME می‌خواند (یا اگر HOME نیز تنظیم نشده باشد، از مکان دایرکتوری خانگی در فایل passwd). اگر هم HOME_ETC و هم FETCHMAILHOME تنظیم شده باشند، FETCHMAILHOME اولویت دارد و HOME_ETC نادیده گرفته می‌شود. .IP \fBSOCKS_CONF\fP (تنها در صورتی که پشتیبانی از SOCKS در برنامه کامپایل شده باشد) این متغیر توسط کتابخانه socks استفاده می‌شود تا بفهمد کدام فایل پیکربندی را باید بخواند. این متغیر را روی /dev/null تنظیم کنید تا پراکسی SOCKS دور زده شود. .IP \fBSSL_CERT_DIR\fP (با کتابخانه‌ای که کاملاً با OpenSSL 3.0 سازگار باشد): دیدگاه OpenSSL از دایرکتوری یا مسیر پیش‌فرض اعتماد (که شامل فایل‌های گواهی جداگانه و پیوندهای نمادین هش‌شده است) را بازنویسی می‌کند، برای جزئیات به صفحه راهنمای SSL_CTX_set_default_verify_paths(3) مراجعه کنید که ممکن است در بسته توسعه openssl باشد. در صورت استفاده از رابط سازگاری OpenSSL در کتابخانه‌ای دیگر، ممکن است این ویژگی کار نکند. از آنجا که این متغیر فقط یک مقدار پیش‌فرض را مشخص می‌کند، در صورت ارائه، گزینه \-\-sslcertpath اولویت خواهد داشت. .IP \fBSSL_CERT_FILE\fP (با کتابخانه‌ای که کاملاً با OpenSSL 3.0 سازگار باشد): دیدگاه OpenSSL از فایل بسته گواهی‌های مورد اعتماد پیش‌فرض (که حاوی ادغام گواهی‌های با کدگذاری base64 در قالب PEM است) را بازنویسی می‌کند، برای جزئیات به صفحه راهنمای SSL_CTX_set_default_verify_paths(3) مراجعه کنید که ممکن است در بسته توسعه openssl باشد. در صورت استفاده از رابط سازگاری OpenSSL در کتابخانه‌ای دیگر، ممکن است این ویژگی کار نکند. از آنجا که این متغیر فقط یک مقدار پیش‌فرض را مشخص می‌کند، در صورت ارائه، گزینه \-\-sslcertfile اولویت خواهد داشت. .IP "سایر متغیرهای پیش‌فرض سیستم" مانند TZ یا متغیرهای محلی LC_XXX، بر رفتار برنامه نیز تأثیر خواهند گذاشت. .SH "سیگنال‌ها (SIGNALS)" اگر یک دیمن \fBfetchmail\fP با دسترسی root در حال اجرا باشد، سیگنال SIGUSR1 آن را از مرحله خواب بیدار کرده و بررسی همه سرورهای نادیده‌گرفته‌نشده را اجبار می‌کند. به دلایل سازگاری، SIGHUP نیز می‌تواند در نسخه‌های 6.3.X استفاده شود اما ممکن است در نسخه‌های آینده fetchmail در دسترس نباشد. .PP اگر \fBfetchmail\fP در حالت دیمن با دسترسی غیر root در حال اجرا باشد، از SIGUSR1 برای بیدار کردن آن استفاده کنید (این به این دلیل است که SIGHUP ناشی از خروج از سیستم بتواند عمل پیش‌فرض خود یعنی خاتمه دادن به برنامه را حفظ کند). .PP اجرای \fBfetchmail\fP در پیش‌زمینه هنگامی که یک نسخه پس‌زمینه fetchmail در حال اجراست، هر کدام از این اقدامات را که برای بیدار کردن آن مناسب باشد انجام خواهد داد. .SH "باگ‌ها، محدودیت‌ها و مشکلات شناخته‌شده (BUGS, LIMITATIONS, AND KNOWN PROBLEMS)" لطفاً فایل \fBNEWS\fP همراه fetchmail را برای باگ‌های شناخته‌شده بیشتر از موارد فهرست‌شده در اینجا بررسی کنید. .PP برنامه Fetchmail نمی‌تواند نام‌های کاربری حاوی فاصله بعد از نویسه "@" را پردازش کند، به عنوان مثال "demonstr@ti on". این موارد نسبتاً نادر هستند و فقط هنگام استفاده از ساختارهای مبتنی بر UID به همراه \-\-keep مشکل‌ساز می‌شوند، بنابراین نسخه‌های 6.X.Y این برنامه اصلاح نخواهند شد. .PP برنامه Fetchmail نمی‌تواند پیکربندی‌هایی را مدیریت کند که در آن‌ها چندین حساب از یک نام سرور و یک لاگین یکسان استفاده می‌کنند. هر ترکیب user@server باید یکتا باشد. .PP فرض‌هایی که گزینه‌های DNS و به ویژه checkalias در نظر می‌گیرند اغلب پایدار نیستند. به عنوان مثال، هم‌اکنون این که یک سرور MX هم‌زمان سرور POP3 یا IMAP باشد غیرمعمول شده است. بنابراین جستجوهای MX ممکن است در نسخه‌های آینده حذف شوند. .PP گزینه‌های mda و plugin تداخل نامناسبی با هم دارند. به منظور جمع‌آوری وضعیت خطا از MDA، برنامه fetchmail باید مدیریت سیگنال عادی خود را تغییر دهد تا فرایندهای مرده افزونه تا پایان چرخه نظرسنجی پاکسازی نشوند. این می‌تواند در صورت انباشته شدن بیش از حد فرآیندهای زامبی (zombie) باعث کمبود منابع شود. بنابراین یا از طریق افزونه‌ها به MDA تحویل ندهید یا ریسک روبرو شدن با انبوهی از پردازش‌های نامرده را بپذیرید. .PP گزینه \-\-interface از IPv6 پشتیبانی نمی‌کند و بعید است که هرگز پشتیبانی کند، زیرا هیچ روش قابل حمل برای پرس‌وجوی نشانی‌های IPv6 رابط شبکه وجود ندارد. .PP تجزیه‌کننده نشانی RFC822 که در حالت چندمقصدی استفاده می‌شود، در برخی از نشانی‌های دارای @ که از نظر فنی مجاز اما نامتعارف هستند دچار اختلال می‌شود. کاربردهای عجیب از نقل‌قول‌ها و کامنت‌های توکار احتمالاً آن را سردرگم می‌کند. .PP در پیامی با چندین هدر پاکت، تنها آخرین هدر پردازش‌شده برای fetchmail قابل مشاهده خواهد بود. .PP استفاده از برخی از این پروتکل‌ها نیازمند این است که برنامه گذرواژه‌های رمزگذاری‌نشده را از طریق اتصال TCP/IP به سرور ایمیل ارسال کند. این خطر ایجاد می‌کند که جفت‌های نام/گذرواژه با یک شنودکننده بسته (packet sniffer) یا نرم‌افزارهای نظارتی پیشرفته‌تر به سرقت بروند. در لینوکس و FreeBSD، می‌توان از گزینه \-\-interface برای محدود کردن بررسی به در دسترس بودن یک دستگاه رابط خاص با یک نشانی IP محلی یا راه دور خاص استفاده کرد، اما شنود همچنان امکان‌پذیر است اگر (الف) هر یک از میزبان‌ها یک دستگاه شبکه داشته باشد که بتوان آن را در حالت بی‌قید (promiscuous mode) باز کرد، یا (ب) پیوند شبکه میانی بتواند شنود شود. ما استفاده از تونل‌زنی .BR ssh (1) را پیشنهاد می‌کنیم تا نه تنها گذرواژه‌های شما پنهان شوند بلکه کل مکالمه رمزگذاری گردد. .PP استفاده از کدهای گریز %F یا %T در گزینه mda می‌تواند یک روزنه امنیتی باز کند، زیرا متنی را که توسط مهاجم قابل دستکاری است به یک دستور شل ارسال می‌کند. کاراکترهای احتمالی شل قبل از اجرا با '_' جایگزین می‌شوند. این حفره با این واقعیت که fetchmail موقتاً هرگونه امتیاز set-uid را که ممکن است هنگام اجرای MDA داشته باشد کنار می‌گذارد، بیشتر کاهش می‌یابد. با این حال، برای حداکثر ایمنی، هنگامی که fetchmail از خود حساب root اجرا می‌شود، از دستور mda حاوی %F یا %T استفاده نکنید. .PP روش Fetchmail برای ارسال پیام‌های برگشتی به دلیل خطا یا مسدود کردن هرزنامه و برگشت‌های هرزنامه نیازمند این است که پورت ۲۵ لوکال‌هاست برای ارسال ایمیل از طریق SMTP در دسترس باشد. .PP اگر فایل \fI~/.fetchmailrc\fP را در حالی که یک نمونه پس‌زمینه در حال اجراست تغییر دهید و نحو آن را خراب کنید، نمونه پس‌زمینه در سکوت متوقف خواهد شد. متأسفانه نمی‌تواند با ایجاد سر و صدا خاموش شود زیرا هنوز نمی‌دانیم آیا syslog باید فعال باشد یا خیر. در برخی سیستم‌ها، fetchmail حتی در صورت عدم وجود خطای نحوی نیز در سکوت خاموش می‌شود؛ به نظر می‌رسد این موضوع با کد دارای باگ ioctl ترمینال در هسته ارتباط دارد. .PP گزینه \-f\~\- (خواندن پیکربندی از ورودی استاندارد stdin) با گزینه plugin ناسازگار است. .PP گزینه 'principal' فقط پروتکل Kerberos IV را مدیریت می‌کند، نه نسخه V. .PP گذرواژه‌هایی که به صورت تعاملی وارد می‌شوند پس از ۶۳ کاراکتر کوتاه می‌شوند. اگر واقعاً نیاز به استفاده از گذرواژه طولانی‌تری دارید، باید از فایل پیکربندی استفاده کنید. .PP کاراکتر بک‌اسلش به عنوان آخرین کاراکتر یک فایل پیکربندی به جای نادیده گرفته شدن، به عنوان خطای نحوی علامت‌گذاری خواهد شد. .PP مدیریت خطای BSMTP عملاً وجود ندارد و ممکن است پیام‌های معیوب را باقی بگذارد. .PP نظرات، گزارش باگ‌ها، انتقادات و موارد مشابه را به .UR "mailto:fetchmail-devel@lists.sourceforge.net" فهرست fetchmail-devel .UE ارسال کنید. .PP یک .UR "https://fetchmail.sourceforge.io/fetchmail-FAQ.html" پرسش و پاسخ متداول (FAQ) مربوط به fetchmail (در قالب HTML) .UE در صفحه خانگی fetchmail موجود است و همچنین باید همراه با نصب شما ارائه شود. .SH "نویسنده (AUTHOR)" برنامه Fetchmail در حال حاضر توسط Matthias Andree و Rob Funk با کمک‌های عمده از Sunil Shetye (برای کد) و Rob MacGregor (برای لیست‌های پستی) نگهداری می‌شود. .PP بخش عمده کد توسط .UR "mailto:esr@snark.thyrsus.com" Eric S. Raymond .UE نوشته شده است. افراد بسیار زیاد دیگری که نام بردن از آن‌ها در اینجا ممکن نیست، در ارائه کد و پچ‌ها مشارکت داشته‌اند. .PP این برنامه برگرفته از و جایگزین برنامه .BR popclient اثر .UR "mailto:ceharris@mal.com" Carl Harris .UE است؛ ساختار درونی آن بسیار متفاوت شده است، اما بخشی از طراحی رابط کاربری آن مستقیماً برگرفته از آن برنامه نیاکان است. .PP این صفحه راهنما توسط Matthias Andree ،R.\ Hannes Beinert و H\['e]ctor Garc\['i]a بهبود یافته است. .SH "همچنین ببینید (SEE ALSO)" .BR README , .BR README.SSL , .BR README.SSL-SERVER , .UR "https://www.fetchmail.info/fetchmail-FAQ.html" The Fetchmail FAQ .UE , .BR mutt (1), .BR elm (1), .BR mail (1), .BR sendmail (8), .BR popd (8), .BR imapd (8), .BR netrc (5), .UR "https://www.fetchmail.info" صفحه خانگی fetchmail .UE , .UR "https://fetchmail.sourceforge.io" (آدرس اینترنتی جایگزین) .UE ; .UR "https://www.courier-mta.org/maildrop" صفحه خانگی maildrop .UE .SH "استانداردهای کاربردی (APPLICABLE STANDARDS)" توجه داشته باشید که این فهرست تنها مجموعه‌ای از مراجع است و بیانیه‌ای در مورد انطباق واقعی پروتکل یا الزامات در fetchmail نیست. .TP 5 SMTP/ESMTP: RFC 821, RFC 2821, RFC 1869, RFC 1652, RFC 1870, RFC 1983, RFC 1985, RFC 2554. .TP 5 mail: RFC 822, RFC 2822, RFC 1123, RFC 1892, RFC 1894. .TP 5 POP2: RFC 937 .TP 5 POP3: RFC 1081, RFC 1225, RFC 1460, RFC 1725, RFC 1734, RFC 1939, RFC 1957, RFC 2195, RFC 2449. .TP 5 APOP: RFC 1939. .TP 5 RPOP: RFC 1081, RFC 1225. .TP 5 IMAP2/IMAP2BIS: RFC 1176, RFC 1732. .TP 5 IMAP4/IMAP4rev1: RFC 1730, RFC 1731, RFC 1732, RFC 2060, RFC 2061, RFC 2195, RFC 2177, RFC 2683. .TP 5 ETRN: RFC 1985. .TP 5 ODMR/ATRN: RFC 2645. .TP 5 OTP: RFC 1938. .TP 5 LMTP: RFC 2033. .TP 5 GSSAPI: RFC 1508, RFC 1734, .UR https://www.iana.org/assignments/gssapi-service-names Generic Security Service Application Program Interface (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) Service Names .UE . .TP 5 TLS: RFC 2595. \" LocalWords: TP smtphost smtp br fetchmail IPv4 IPv6 TLS STARTTLS \" LocalWords: 'localhost LMTP IMAP server1 server2 server3 EE ODMR \" LocalWords: notls hostname localhost starttls EHLO sslcertck tls \" LocalWords: nosslcertck tlsproto PROTO sslproto servername SNI \" LocalWords: smtpaddress smtpname esmtpname authid AUTH loopback \" LocalWords: esmtppassword