شروع سریع (QUICKSTART)

۱. یک سرور ایمیل محلی SMTP، یا یک عامل تحویل ایمیل خط فرمانی (MDA) مانند maildrop یا dovecot-lda را راه‌اندازی، پیکربندی، آزمایش و اشکال‌زدایی کنید. اطمینان حاصل کنید که ایمیلی که از طریق آن برای خود ارسال می‌کنید به مقصد درست می‌رسد. تا زمانی که این بخش به درستی کار نکرده است ادامه ندهید، در غیر این صورت خطر از دست رفتن ایمیل‌ها وجود دارد!

۲. یک فایل .fetchmailrc در پوشه خانگی خود ایجاد کنید که برای بازیابی‌های POP3 ساختاری شبیه به این داشته باشد:

poll mailserver.example.org proto POP3 uidl
user joe.sixpack
keep ssl

شما باید چندین عنصر را در اینجا تنظیم کنید: mailserver.example.org نام سرور است. joe.sixpack نام کاربری مورد استفاده برای اتصال به سرور است. گزینه keep مشخص می‌کند که پیام‌ها باید به جای حذف شدن، روی سرور باقی بمانند. گزینه ssl مشخص می‌کند که اتصال باید رمزگذاری شود. اگر به جای POP3 نیاز به استفاده از IMAP دارید، عبارت "proto POP3 uidl" را به "proto IMAP" تغییر دهید.

اگر تصمیم گرفتید تحویل ایمیل را از طریق یک برنامه خط فرمانی انجام دهید، یک گزینه mda اضافه کنید، به عنوان مثال:

mda "/usr/bin/maildrop -d %T"

۳. سپس اطمینان حاصل کنید که فایل ~/.fetchmailrc برای هیچ‌کس جز خودتان قابل خواندن یا نوشتن نباشد:

chmod 0600 ~/.fetchmailrc

۴. در نهایت، fetchmail را در حالت پرجزئیات (verbose) اجرا کرده و بررسی کنید که درست کار می‌کند. برای محدود کردن اثرات احتمالی در صورت بروز مشکل، ابتدا فقط دریافت دو پیام را امتحان می‌کنیم:

fetchmail -v --fetchlimit 2

اگر سپس سرور POP3 از UIDL پشتیبانی نکرد، نمی‌توانید از گزینه "keep" روی آن سرور استفاده کنید و باید گزینه‌های uidl و keep را حذف کنید؛ اما توجه داشته باشید که در این حالت fetchmail پیام‌هایی را که با موفقیت تحویل داده است از روی سرور حذف خواهد کرد.

گزینه‌های عمومی (General Options)

-? | --help

نمایش راهنمای گزینه‌ها.

-V | --version

اطلاعات نسخه نسخه نصب‌شده fetchmail شما را نمایش می‌دهد. هیچ عملیات بازیابی ایمیلی انجام نمی‌شود. در عوض، برای هر سرور مشخص‌شده، تمامی اطلاعات گزینه‌هایی که در صورت اتصال fetchmail به آن سرور محاسبه می‌شدند نمایش داده می‌شوند. هرگونه نویسه غیرقابل چاپ در گذرواژه‌ها یا نام‌های رشته‌ای دیگر به صورت توالی‌های گریز شبیه زبان C با بک‌اسلش نمایش داده می‌شوند. این گزینه برای بررسی اینکه آیا گزینه‌های شما به همان شکلی که می‌خواهید تنظیم شده‌اند یا خیر مفید است.

-c | --check

یک کد وضعیت برمی‌گرداند تا مشخص کند آیا ایمیلی در انتظار است یا خیر، بدون اینکه واقعاً ایمیلی را بازیابی یا حذف کند (بخش کدهای خروج در ادامه را ببینید). این گزینه حالت دیمن را غیرفعال می‌کند (که در آن بی‌فایده خواهد بود). این گزینه با استعلام از چندین سایت به خوبی کار نمی‌کند و با ETRN یا ODMR نیز کارایی ندارد. اگر ایمیل‌های خوانده‌شده اما حذف‌نشده را در صندوق پستی سرور خود باقی بگذارید و پروتکل بازیابی شما نتواند پیام‌های نگه‌داشته‌شده را از پیام‌های جدید تشخیص دهد، نتیجه مثبت کاذب برمی‌گرداند. این بدان معناست که با IMAP کار می‌کند، با POP2 کار نمی‌کند و ممکن است گهگاه تحت POP3 دچار اختلال شود.

-s | --silent

حالت خاموش (بی‌صدا). تمام پیام‌های پیشرفت/وضعیت را که معمولاً در حین بازیابی در خروجی استاندارد چاپ می‌شوند سرکوب می‌کند (اما پیام‌های خطای واقعی را سرکوب نمی‌کند). گزینه --verbose بر این گزینه اولویت دارد.

-v | --verbose

حالت پرجزئیات. تمام پیام‌های کنترلی رد و بدل شده میان fetchmail و سرور ایمیل در خروجی استاندارد (stdout) چاپ می‌شوند. بر گزینه --silent اولویت دارد. تکرار دوگانه این گزینه (-v -v) باعث چاپ اطلاعات تشخیصی اضافی می‌شود.

--nosoftbounce

(از نسخه 6.3.10، کلمه کلیدی: set no softbounce، از نسخه 6.3.10)
حالت برگشت سخت (Hard bounce). تمام خطاهای دائمی تحویل باعث حذف پیام‌ها از سرور بالادستی می‌شوند، بخش "no softbounce" را در ادامه ببینید.

--softbounce

(از نسخه 6.3.10، کلمه کلیدی: set softbounce، از نسخه 6.3.10)
حالت برگشت نرم (Soft bounce). تمام خطاهای دائمی تحویل باعث می‌شوند در صورت پشتیبانی پروتکل، پیام‌ها روی سرور بالادستی باقی بمانند. این گزینه به طور پیش‌فرض فعال است تا با مستندات تاریخی fetchmail مطابقت داشته باشد، و در انتشار بعدی fetchmail به حالت hard bounce تغییر خواهد کرد.

گزینه‌های نحوه برخورد با پیام‌ها (Disposal Options)

-a | --all | (از نسخه 6.3.3) --fetchall

(کلمه کلیدی: fetchall، از نسخه 3.0)
بازیابی هر دو دسته پیام‌های قدیمی (دیده‌شده) و جدید از سرور ایمیل. حالت پیش‌فرض، بازیابی پیام‌هایی است که سرور آن‌ها را دیده‌شده علامت‌گذاری نکرده است. تحت POP3، این گزینه همچنین استفاده از دستور RETR را به جای TOP اجباری می‌کند. توجه داشته باشید که بازیابی POP2 رفتاری شبیه به فعال بودن دائمی --all دارد (بخش حالت‌های شکست در بازیابی در ادامه را ببینید) و این گزینه با ETRN یا ODMR کار نمی‌کند. اگرچه گزینه‌های خط فرمانی -a و --all و گزینه fetchall در فایل rc از دیرباز پشتیبانی می‌شدند، گزینه خط فرمانی --fetchall در نسخه 6.3.3 اضافه شد.

-k | --keep

(کلمه کلیدی: keep)
نگه‌داشتن پیام‌های بازیابی‌شده روی سرور ایمیل راه دور. به طور معمول، پیام‌ها پس از بازیابی از پوشه موجود در سرور ایمیل حذف می‌شوند. تعیین گزینه keep باعث می‌شود پیام‌های بازیابی‌شده در پوشه شما روی سرور ایمیل باقی بمانند. این گزینه با ETRN یا ODMR کار نمی‌کند. در صورت استفاده با POP3، توصیه می‌شود گزینه --uidl یا کلمه کلیدی uidl را نیز مشخص کنید.

-K | --nokeep

(کلمه کلیدی: nokeep)
حذف پیام‌های بازیابی‌شده از سرور ایمیل راه دور. این گزینه حذف ایمیل‌های بازیابی‌شده را اجباری می‌کند. اگر در فایل .fetchmailrc خود حالت پیش‌فرض را روی keep تنظیم کرده باشید، این گزینه می‌تواند مفید باشد. این گزینه در ETRN و ODMR به صورت اجباری فعال است.

--moveto <folder>

(کلمه کلیدی: moveto)
در حالت IMAP، به جای پاکسازی (flush) پیام، آن را به پوشه IMAP مشخص‌شده منتقل می‌کند. این قابلیت برای جلوگیری از دست رفتن داده‌ها هنگام آزمایش مفید است و روش ترجیحی برای حذف ایمیل‌ها در برخی پیاده‌سازی‌هاست؛ برای نمونه، گوگل از شما می‌خواهد ایمیل‌ها را با انتقال به [Gmail]/Trash حذف کنید. فقط برای سرورهای IMAP در دسترس است. این گزینه تنها با --proto imap پذیرفته می‌شود، اما در صورتی که IMAP به طور خودکار انتخاب شده باشد پذیرفته نمی‌شود. در صورت فعال بودن --keep بی‌اثر است.

-F | --flush

(کلمه کلیدی: flush)
فقط POP3/IMAP. این یک گزینه خطرناک است و در صورت استفاده نادرست می‌تواند باعث از دست رفتن ایمیل‌ها شود. این گزینه پیام‌های قدیمی (دیده‌شده) را قبل از بازیابی پیام‌های جدید از سرور ایمیل حذف می‌کند. هشدار: اگر ایمیل خود را با کلاینت‌هایی غیر از fetchmail بررسی کنید، این گزینه می‌تواند باعث از دست رفتن ایمیل‌ها شود و باعث شود fetchmail پیامی را که هرگز قبلاً دریافت نکرده بود حذف کند. همچنین اگر سرور ایمیل پیام را پس از بازیابی دیده‌شده علامت‌گذاری کند (سرورهای IMAP2) می‌تواند باعث از دست رفتن ایمیل شود. احتمالاً نباید از این گزینه در فایل پیکربندی خود استفاده کنید. اگر از آن با POP3 استفاده می‌کنید، باید از گزینه 'uidl' استفاده نمایید. آنچه احتمالاً می‌خواهید تنظیمات پیش‌فرض است: اگر '-k' را مشخص نکنید، fetchmail به طور خودکار پیام‌ها را پس از تحویل موفق حذف خواهد کرد.

--limitflush

فقط POP3/IMAP، از نسخه 6.3.0. حذف پیام‌های با حجم بیش از حد مجاز از سرور ایمیل قبل از بازیابی پیام‌های جدید. حد مجاز اندازه باید به طور جداگانه با گزینه --limit مشخص شود. این گزینه با ETRN یا ODMR کار نمی‌کند.

گزینه‌های پروتکل و پرس‌وجو (Protocol and Query Options)

-p <proto> | --proto <proto> | --protocol <proto>

(کلمه کلیدی: proto[col])
مشخص کردن پروتکل مورد استفاده هنگام برقراری ارتباط با سرور ایمیل راه دور. اگر پروتکلی مشخص نشود، مقدار پیش‌فرض AUTO است. proto می‌تواند یکی از موارد زیر باشد:

تمام این گزینه‌ها اساساً به یک شیوه عمل می‌کنند (ارتباط با دیمن‌های استاندارد سرور برای بازیابی ایمیل‌هایی که قبلاً به صندوق پستی روی سرور تحویل داده شده‌اند)، به جز ETRN و ODMR. حالت ETRN به شما امکان می‌دهد از یک سرور ESMTP سازگار (مانند BSD sendmail در نسخه 8.8.0 یا بالاتر) بخواهید بلافاصله یک اتصال فرستنده SMTP به دستگاه کلاینت شما برقرار کرده و فوروارد تمامی مواردی را که در صف ایمیل‌های تحویل‌نشده سرور به مقصد دستگاه کلاینت شما قرار دارند آغاز کند. حالت ODMR نیازمند سروری با قابلیت ODMR است و مشابه ETRN عمل می‌کند، با این تفاوت که نیازی به داشتن DNS ایستا برای دستگاه کلاینت ندارد.

-U | --uidl

(کلمه کلیدی: uidl)
اجبار به استفاده از UIDL (فقط با POP3 موثر است). اجبار به ردیابی وضعیت «جدید بودن» پیام‌ها در سمت کلاینت (UIDL مخفف "unique ID listing" است و در RFC1939 شرح داده شده است). برای استفاده از صندوق پستی به عنوان یک دریافت‌کننده اخبار کوچک برای گروهی از کاربران به همراه 'keep' استفاده می‌شود. این واقعیت که پیام‌های دیده‌شده نادیده گرفته می‌شوند ثبت می‌شود، مگر اینکه ثبت خطای گزارش‌ها در حین اجرا در حالت دیمن از طریق syslog انجام شود. توجه داشته باشید که fetchmail ممکن است بسته به قابلیت‌های سرور بالادستی این گزینه را به طور خودکار فعال کند. همچنین توجه داشته باشید که این گزینه ممکن است در نسخه بعدی fetchmail حذف شده و استفاده از آن اجباری شود. همچنین ببینید: --idfile.

--idle (از نسخه 6.3.3)

(کلمه کلیدی: idle، از قبل از نسخه 6.0.0)
فعال کردن استفاده از IDLE (فقط با IMAP موثر است). توجه داشته باشید که این گزینه در یک زمان مشخص فقط با یک حساب کاربری و یک پوشه کار می‌کند؛ هنگامی که idle فعال باشد سایر پوشه‌ها یا حساب‌ها استعلام نخواهند شد! اگرچه کلمه کلیدی idle در فایل rc از دیرباز پشتیبانی می‌شد، گزینه خط فرمانی --idle در نسخه 6.3.3 اضافه شد. استفاده از IDLE به این معنی است که fetchmail به سرور IMAP اعلام می‌کند تا اطلاعیه پیام‌های جدید را ارسال کند، تا بتوان آن‌ها را زودتر از آنچه با استعلام‌های دوره‌ای منظم ممکن است بازیابی کرد. برنامه Fetchmail همچنین شامل یک راهکار برای شبیه‌سازی IDLE است؛ این راهکار از نسخه 6.4.22 بی‌اثر بود و در نسخه 6.5.3 اصلاح شد (به دلیل کامیت 616e8c70 شکسته شده بود و در f91923b5 تعمیر شد)، گزارش Gitlab شماره #69.

--forceidle (از نسخه 6.5.0)

(کلمه کلیدی: forceidle، از نسخه 6.5.0)
استفاده از IDLE حتی اگر سرور آن را در قابلیت‌های خود اعلام نکرده باشد. این یک گزینه خطرناک است، با احتیاط استفاده کنید.

--idletimeout (از نسخه 6.5.0)

(کلمه کلیدی: idletimeout، از نسخه 6.5.0)
تنظیم مهلت زمانی (به ثانیه) برای دستور IDLE، زیرا سرورهای زیادی پروتکل را نقض می‌کنند (که نیازمند ۳۰ دقیقه است) و پس از چند دقیقه اتصال را قطع می‌کنند. مقدار پیش‌فرض: 1680 ثانیه (= ۲۸ دقیقه).

-P <portnumber> | --service <servicename>

(کلمه کلیدی: service) از نسخه 6.3.0.
گزینه service به شما امکان می‌دهد نام سرویسی را برای اتصال مشخص کنید. اگر پایگاه‌داده سرویس‌های شما فاقد تخصیص‌های لازم پورت به سرویس باشد، می‌توانید یک شماره درگاه بر مبنای دهدهی در اینجا مشخص کنید. برای جزئیات، مورد R12 از بخش FAQ و مستندات --ssl را ببینید. این گزینه جایگزین گزینه قدیمی‌تر --port شده است.

توجه داشته باشید که این گزینه به طور خودکار میان حالت‌های پوشش‌داده‌شده با TLS و حالت STARTTLS جابجا نمی‌شود؛ اگر در اینجا شماره درگاه یا نام سرویسی را مشخص کنید که با TLS پوشش داده شده است (به این معنی که مذاکره TLS را قبل از ارسال داده‌های برنامه به صورت متن آشکار آغاز می‌کند)، ممکن است لازم باشد --ssl را در خط فرمان یا ssl را در فایل rc خود مشخص کنید.

--port <portnumber>

(کلمه کلیدی: port)
نسخه منسوخ‌شده گزینه --service که نام‌های سرویس را نمی‌پذیرد. توجه: این گزینه ممکن است در نسخه‌های آینده حذف شود.

--principal <principal>

(کلمه کلیدی: principal)
گزینه principal به شما امکان می‌دهد یک شناسه سرویس (principal) را برای احراز هویت متقابل مشخص کنید. این گزینه فقط برای POP3 یا IMAP به همراه احراز هویت Kerberos 4 کاربرد دارد. برای Kerberos 5 یا GSSAPI اعمال نمی‌شود. این گزینه ممکن است در نسخه آینده fetchmail حذف شود.

-t <seconds> | --timeout <seconds>

(کلمه کلیدی: timeout)
گزینه timeout به شما امکان می‌دهد یک مهلت زمانی عدم پاسخ سرور را بر حسب ثانیه تنظیم کنید. اگر سرور ایمیل برای تعداد ثانیه‌های مشخص‌شده پیام خوش‌آمدگویی ارسال نکند یا به دستورات پاسخ ندهد، fetchmail اتصال به آن را قطع خواهد کرد. بدون چنین مهلتی، fetchmail ممکن است در تلاش برای بازیابی ایمیل از میزبانی که از کار افتاده است تا زمان اتمام مهلت اتصال TCP معلق بماند، که ممکن است بسیار طولانی باشد. این وضعیت به ویژه برای اجرای fetchmail در پس‌زمینه آزاردهنده خواهد بود. یک مهلت زمانی پیش‌فرض وجود دارد که fetchmail -V آن را گزارش می‌کند. اگر یک اتصال مشخص تعداد زیادی وقفه متوالی دریافت کند، fetchmail آن را مسدود تلقی کرده و تلاش مجدد را متوقف می‌کند. در این صورت از طریق ایمیل به کاربر فراخوان اطلاع داده خواهد شد.

از نسخه 6.3.10 برنامه fetchmail، کلاینت SMTP هنگام انتظار برای سرور SMTP/LMTP طرف مکالمه از حداقل مهلت‌های زمانی توصیه‌شده در RFC-5321 استفاده می‌کند. می‌توانید مهلت‌های زمانی را حتی بیشتر افزایش دهید، اما نمی‌توانید آن‌ها را کوتاه‌تر کنید. این برای جلوگیری از وضعیتی دردناک است که در آن fetchmail با مهلت زمانی کوتاهی (یک دقیقه یا کمتر) پیکربندی شده و پیامی طولانی (چندین مگابایت) را به MTA محلی ارسال می‌کند که پاسخ "OK" دادن آن بیش از مهلت زمانی طول می‌کشد، در حالی که در نهایت پاسخ خواهد داد؛ این بدان معناست که ایمیل به درستی تحویل داده می‌شود، اما fetchmail متوجه آن نمی‌شود و بنابراین این پیام بزرگ را بارها و بارها مجدداً بازیابی می‌کند.

--plugin <command>

(کلمه کلیدی: plugin)
گزینه plugin به شما امکان می‌دهد از یک برنامه خارجی برای برقراری اتصال TCP استفاده کنید. این قابلیت زمانی مفید است که بخواهید از ssh استفاده کنید یا به تنظیمات خاص فایروال نیاز داشته باشید. این برنامه در مسیرهای $PATH جستجو خواهد شد و می‌توان به صورت اختیاری نام میزبان و درگاه را با استفاده از "%h" و "%p" به عنوان آرگومان به آن ارسال کرد (توجه داشته باشید که منطق جایگذاری نسبتاً ابتدایی است و این نشانه‌ها باید با فاصله یا ابتدای رشته یا انتهای رشته محدود شوند). برنامه Fetchmail در ورودی استاندارد (stdin) پلاگین می‌نویسد و از خروجی استاندارد (stdout) آن می‌خواند.

--plugout <command>

(کلمه کلیدی: plugout)
همانند گزینه plugin در بالا، اما این گزینه برای اتصالات SMTP استفاده می‌شود.

-r <name> | --folder <name>

(کلمه کلیدی: folder[s])
باعث بازیابی یک پوشه ایمیل غیرپیش‌فرض مشخص‌شده روی سرور ایمیل (یا فهرستی از پوشه‌ها با جداکننده کاما) می‌شود. ساختار دستوری نام پوشه وابسته به سرور است. این گزینه تحت POP3، ETRN یا ODMR در دسترس نیست.

--tracepolls

(کلمه کلیدی: tracepolls)
به fetchmail دستور می‌دهد تا اطلاعات ردیابی استعلام را به صورت 'polling account %s' و 'folder %s' به خط Received که تولید می‌کند اضافه نماید، جایی که بخش‌های %s با نام راه دور کاربر، برچسب استعلام، و در صورت موجود بودن، پوشه (صندوق پستی) جایگزین می‌شوند (هدر Received معمولاً شامل نام واقعی سرور نیز هست). این قابلیت می‌تواند برای تسهیل فیلتر کردن ایمیل بر اساس حسابی که ایمیل از آن دریافت می‌شود استفاده شود. اطلاعات پوشه فقط از نسخه 6.3.4 به بعد نوشته می‌شود.

--ssl

(کلمه کلیدی: ssl)
باعث می‌شود اتصال به سرور ایمیل از طریق SSL رمزگذاری شود، که با مذاکره مستقیم SSL پس از برقراری اتصال انجام می‌گیرد (حالت SSL-wrapped، یا Implicit TLS طبق RFC-8314 نامیده می‌شود). لطفاً توضیحات --sslproto در ادامه را ببینید! اطلاعات بیشتر در فایل README.SSL همراه با fetchmail موجود است.

توجه داشته باشید که حتی اگر این گزینه حذف شود، fetchmail همچنان ممکن است از طریق ویژگی STLS یا STARTTLS اقدام به مذاکره درون‌باندی SSL برای POP3 یا IMAP کند. می‌توانید از گزینه --sslproto برای تغییر این رفتار استفاده کنید.

اگر درگاهی مشخص نشود، تلاش برای اتصال به درگاه شناخته‌شده نسخه SSL پروتکل پایه صورت می‌گیرد. این درگاه معمولاً متفاوت از درگاه مورد استفاده توسط پروتکل پایه است. برای IMAP، این درگاه برای پروتکل متن آشکار 143 و برای پروتکل امن‌شده با SSL درگاه 993 است؛ برای POP3، برای متن آشکار درگاه 110 و برای نوع رمزگذاری‌شده درگاه 995 است.

اگر سیستم شما فاقد مدخل‌های مربوطه در /etc/services است، گزینه --service را ببینید و شماره درگاه عددی را همان‌طور که در پاراگراف قبل ذکر شد مشخص کنید (مگر اینکه ISP شما درگاه‌های دیگری را به شما اعلام کرده باشد، که البته نامعمول است).

--nossl

(کلمه کلیدی: nossl)
در صورت تعیین --nossl در خط فرمان، مقدار پیش‌فرض ssl که قبلاً در بخش defaults یا در فایل rc تعیین شده بود لغو می‌شود. از --sslproto با آرگومان مناسب برای فعال‌سازی STARTTLS استفاده کنید.

--sslcert <name>

(کلمه کلیدی: sslcert)
برای احراز هویت کلاینت مبتنی بر گواهی. برخی سرورهای رمزگذاری‌شده با SSL برای احراز هویت نیازمند کلیدها و گواهی‌های سمت کلاینت هستند. در بیشتر موارد، این مورد اختیاری است. این گزینه مکان گواهی کلید عمومی را مشخص می‌کند که باید در زمان برقراری نشست SSL به سرور ارائه شود. اگر سرور به آن نیاز نداشته باشد الزامی نیست (اما می‌تواند ارائه شود). می‌تواند همان فایل کلید خصوصی باشد (فایل ترکیبی کلید و گواهی)، اما این کار توصیه نمی‌شود. همچنین --sslkey در ادامه را ببینید.

توجه: اگر از احراز هویت کلاینت استفاده کنید، نام کاربری از CommonName گواهی استخراج شده و بر نام تنظیم‌شده با --user اولویت خواهد داشت.

--sslkey <name>

(کلمه کلیدی: sslkey)
نام فایل کلید خصوصی SSL سمت کلاینت را مشخص می‌کند. برخی سرورهای رمزگذاری‌شده با SSL برای احراز هویت به کلیدها و گواهی‌های سمت کلاینت نیاز دارند. در بیشتر موارد، این مورد اختیاری است. این گزینه مکان کلید خصوصی مورد استفاده برای امضای تراکنش‌ها با سرور در زمان برقراری نشست SSL را مشخص می‌کند. اگر سرور به آن نیاز نداشته باشد الزامی نیست (اما می‌تواند ارائه شود). می‌تواند همان فایل گواهی کلید عمومی باشد (فایل ترکیبی کلید و گواهی)، اما این کار توصیه نمی‌شود.

اگر برای باز کردن قفل کلید به گذرواژه نیاز باشد، درست قبل از برقراری نشست با سرور درخواست گذرواژه خواهد شد. این موضوع می‌تواند در حالت دیمن پیچیدگی‌هایی ایجاد کند.

همچنین --sslcert در بالا را ببینید.

--sslproto <value>

(کلمه کلیدی: sslproto، توجه: تغییرات معنایی از نسخه 6.4.0)
این گزینه به دلیل رفتارهای تاریخی fetchmail کاربرد دوگانه‌ای دارد. این گزینه هم نسخه پروتکل SSL/TLS و هم در صورتی که --ssl مشخص نشده باشد، رفتار STARTTLS (ارتقای درون‌باندی پروتکل به یک اتصال SSL یا TLS) را کنترل می‌کند. با این حال برخی گزینه‌های دیگر ممکن است استفاده از TLS را اجباری کنند -- به ویژه، --sslcertck اکنون رفتار پیش‌فرض است و نیازمند SSL می‌باشد.

مقادیر شناخته‌شده برای --sslproto در زیر آمده است. به طور معمول باید یکی از گزینه‌های دارای مذاکره خودکار را انتخاب کنید، یعنی 'tls1.2+' یا 'auto' یا یکی از گزینه‌های دیگری که با نویسه مثبت (+) پایان می‌یابند. توجه داشته باشید که بسته به نسخه و پیکربندی کتابخانه TLS (مانند OpenSSL، AWS-LC، wolfSSL)، برخی گزینه‌ها باعث خطاهای زمان اجرا می‌شوند زیرا نسخه‌های درخواستی SSL یا TLS توسط کتابخانه TLS نصب‌شده پشتیبانی نمی‌شوند. حتماً قبل از استقرار برای کار بدون نظارت، به خوبی آزمایش کنید!

نکته: به ندرت پیش می‌آید که به چیزی جز '' (برای اجبار به اتصال بدون رمزگذاری) یا 'auto' (برای اجبار به TLS) نیاز داشته باشید.

--sslcertck

(کلمه کلیدی: sslcertck، پیش‌فرض فعال از نسخه 6.4.0)
گزینه --sslcertck باعث می‌شود fetchmail استفاده از SSL/TLS را الزامی بداند و در صورتی که نتواند با موفقیت SSL یا TLS را مذاکره کند، یا نتواند گواهی را با موفقیت بررسی و اعتبارسنجی کرده و زنجیره آن را تا یک لنگر اعتماد (یا گواهی ریشه معتمد) دنبال کند، اتصال را قطع کند. لنگرهای اعتماد به صورت مجموعه‌ای از گواهی‌های معتمد محلی داده می‌شوند (گزینه‌های sslcertfile و sslcertpath را ببینید). اگر گواهی سرور قابل دریافت نباشد یا توسط یکی از گواهی‌های معتمد (مستقیم یا غیرمستقیم) امضا نشده باشد، بدون در نظر گرفتن گزینه sslfingerprint، برنامه fetchmail اتصال را قطع خواهد کرد.

--nosslcertck

(کلمه کلیدی: no sslcertck، فقط در نسخه 6.4.X)
برعکس --sslcertck، این یک گزینه غیرتوصیه‌شده است. این گزینه به fetchmail اجازه می‌دهد حتی در صورت شکست بررسی‌های اعتبارسنجی گواهی سرور، به اتصال ادامه دهد. فقط باید همراه با --sslfingerprint استفاده شود.

--sslcertfile <file>

(کلمه کلیدی: sslcertfile، از نسخه 6.3.17)
فایلی را تنظیم می‌کند که fetchmail برای جستجوی گواهی‌های محلی استفاده می‌کند. حالت پیش‌فرض خالی است. این گزینه می‌تواند علاوه بر --sslcertpath در زیر مشخص شود، و گواهی‌های مشخص‌شده در --sslcertfile قبل از موارد موجود در --sslcertpath پردازش خواهند شد. این گزینه می‌تواند علاوه بر --sslcertpath استفاده شود.

این فایل یک فایل متنی است. این فایل شامل ادغام گواهی‌های CA معتمد با فرمت PEM است.

توجه داشته باشید که استفاده از این گزینه مانع از بارگذاری فایل گواهی‌های پیش‌فرض CA معتمد SSL می‌شود، مگر اینکه متغیر محیطی FETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS را با مقداری غیرخالی مقداردهی کنید.

--sslcertpath <directory>

(کلمه کلیدی: sslcertpath)
پوشه‌ای را تنظیم می‌کند که fetchmail برای جستجوی گواهی‌های محلی از آن استفاده می‌کند. مقدار پیش‌فرض، پوشه پیش‌فرض OpenSSL شماست. پوشه باید به روشی که OpenSSL انتظار دارد هش‌بندی شده باشد - هر بار که گواهی‌ای را در پوشه اضافه یا اصلاح می‌کنید، باید از ابزار c_rehash (که همراه با OpenSSL در زیرپوشه tools/ ارائه می‌شود) استفاده کنید. همچنین پس از ارتقای OpenSSL، ممکن است نیاز به اجرای c_rehash داشته باشید.

این گزینه می‌تواند علاوه بر --sslcertfile در بالا مشخص شود، که قوانین اولویت را در آن ببینید.

توجه داشته باشید که استفاده از این گزینه مانع از اضافه شدن پوشه پیش‌فرض گواهی‌های CA معتمد SSL می‌شود، مگر اینکه متغیر محیطی FETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS را با مقداری غیرخالی مقداردهی کنید.

--sslcommonname <common name>

(کلمه کلیدی: sslcommonname؛ از نسخه 6.3.9)
استفاده از این گزینه توصیه نمی‌شود. قبل از استفاده از آن، با مدیر سرور بالادستی خود تماس بگیرید و درخواست کنید تا یک گواهی مناسب SSL مورد استفاده قرار گیرد. اگر دستیابی به آن ممکن نباشد، این گزینه می‌تواند برای تعیین نامی (CommonName) استفاده شود که fetchmail انتظار دارد در گواهی سرور وجود داشته باشد. سروری که به درستی پیکربندی شده باشد این نام را روی نام میزبانی که از طریق آن در دسترس است تنظیم می‌کند، و fetchmail نیز به طور پیش‌فرض همین انتظار را دارد. از این گزینه هنگامی استفاده کنید که CommonName روی مقدار دیگری تنظیم شده باشد تا از هشدار "Server CommonName mismatch" جلوگیری شود، و فقط در صورتی که نتوان مدیر سرور بالادستی را به استفاده از گواهی‌های مناسب ترغیب کرد.

--sslfingerprint [{<algo>}]<fingerprint>

(کلمه کلیدی: sslfingerprint)
اثرانگشت (fingerprint) کلید سرور را به صورت نماد هگزادسیمال همراه با دو نقطه جداکننده گروه‌های دو رقمی مشخص می‌کند. این فرمتی است که fetchmail هنگام برقراری اتصال SSL برای گزارش اثرانگشت استفاده می‌کند. هنگامی که این گزینه مشخص شود، fetchmail اثرانگشت کلید سرور را با اثرانگشت ارائه‌شده مقایسه می‌کند و در صورت عدم تطابق، بدون در نظر گرفتن تنظیمات sslcertck، اتصال با شکست مواجه خواهد شد. اتصال همچنین در صورتی که fetchmail نتواند گواهی SSL را از سرور دریافت کند ناموفق خواهد بود. این قابلیت می‌تواند برای جلوگیری از حملات مرد میانی (MITM) استفاده شود، اما اثرانگشت سرور باید از طریق یک کانال امن دریافت یا تأیید شود، و مسلماً نه از طریق همان اتصال اینترنتی که fetchmail استفاده می‌کند.

اثرانگشت می‌تواند با نام الگوریتم خلاصه پیام EVP_MD داخل آکولاد پیشوندگذاری شود، برای نمونه: {MD5}00:01:...:0F. تمامی الگوریتم‌های خلاصه‌سازی که کتابخانه ارائه‌دهنده SSL شما پشتیبانی می‌کند قابل استفاده هستند. یک الگوریتم معقول مانند SHA256 را انتخاب کنید. اگر پیشوند {algo} حذف شود، از MD5 برای سازگاری با fetchmail نسخه 6.4 و قدیمی‌تر استفاده می‌شود.

استفاده از این گزینه تا زمانی که --nosslcertck فعال باشد، از چاپ خطاهای اعتبارسنجی گواهی جلوگیری می‌کند.

اگر فقط می‌خواهید خروجی لاگ --verbose را تغییر دهید تا به یک هش متفاوت منتقل شود، بدون اینکه هش گواهی سرور پین شود، می‌توانید از --sslfingerprint '{algo}*' استفاده کنید، به عنوان مثال: --sslfingerprint '{SHA256}*'

برای به دست آوردن اثرانگشت گواهی ذخیره‌شده در فایل cert.pem، دستور زیر را امتحان کنید:

openssl x509 -in cert.pem -noout -sha256 -fingerprint

برای جزئیات بیشتر، x509(1ssl) را ببینید.

گزینه‌های کنترل تحویل (Delivery Control Options)

-S <hosts> | --smtphost <hosts>

(کلمه کلیدی: smtp[host])
(از نسخه 6.6.0 به بعد، fetchmail از TLS و STARTTLS برای میزبان‌های SMTP پشتیبانی می‌کند)
(از نسخه 6.5.6 به بعد، fetchmail چگونگی تولید لیترال‌های آدرس IP بر اساس RFC-5321 را از یک رشته آدرس عددی خام IPv4 یا IPv6 می‌داند)

فهرستی از میزبان‌ها (hunt list) را برای فوروارد نامه‌ها مشخص می‌کند (یک یا چند نام میزبان، جداشده با کاما). میزبان‌ها به ترتیب فهرست آزمایش می‌شوند؛ نخستین میزبانی که در دسترس باشد، به عنوان مقصد فوروارد برای اجرای جاری انتخاب می‌شود. اگر این گزینه مشخص نشود، 'localhost' به عنوان پیش‌فرض استفاده می‌شود. هر نام میزبان می‌تواند دارای شماره پورت بعد از نام میزبان باشد. شماره پورت با یک اسلش از نام میزبان جدا می‌شود؛ پورت پیش‌فرض "smtp" است. اگر یک مسیر مطلق را مشخص کنید (که با / شروع شود)، به عنوان نام یک سوکت یونیکس تفسیر می‌شود که اتصالات LMTP را می‌پذیرد (مانند آنچه توسط دیمن Cyrus IMAP پشتیبانی می‌شود).
مثال:

--smtphost server1,server2/2525,server3,/var/imap/socket/lmtp

این گزینه می‌تواند همراه با ODMR استفاده شود و fetchmail را به یک بازپخش‌کننده (relay) میان سرور ODMR و گیرنده SMTP یا LMTP تبدیل خواهد کرد.

هر نام میزبان برای سرورهای SMTP تا چهار گزینه را که با اسلش (/) جدا شده‌اند پشتیبانی می‌کند:

نکته ۱: هر متنی که صراحتاً شناخته نشود به عنوان یک نام سرویس در نظر گرفته خواهد شد؛ خطاهای نگارشی مانند گزینه‌های اشتباه‌تایپ‌شده می‌توانند به شکل خطاهای گیج‌کننده ()getaddrinfo برای تفکیک یک سرویس ظاهر شوند، به عنوان نمونه: 'Servname not supported for ai_socktype'.

نکته ۲: هنگامی که گزینه‌های متناقض داده شوند، آخرین گزینه تعیین‌شده برتری دارد.

مثال:

--smtphost dnsname.example.org/25/starttls/tlsproto=tls1.3/servername=commonname.example.com

نام dnsname.example.org را تفکیک می‌کند، روی پورت ۲۵ به آن متصل می‌شود، تلاش می‌کند تا دستور STARTTLS را ارسال کرده و به TLS v1.3 ارتقا یابد و انتظار دارد که گواهی X.509 سرور با نام commonname.example.com مطابقت داشته باشد.

هشدار برای نسخه‌های 6.5.5 و قبل‌تر: اگر از آدرس‌های IP عددی در اینجا استفاده می‌کنید، حتماً از --smtpaddress یا --smtpname (به هر کدام که مراجعه کنید) همراه با یک لیترال آدرس SMTP معتبر استفاده نمایید!

--esmtpname <authid>

(از نسخه 6.5.7؛ کلمه کلیدی: esmtpname، از نسخه 5.9.9) شناسه احراز هویت (authorization ID) را برای SMTP AUTH جهت ورود به سرور SMTP تنظیم می‌کند. پیش‌فرض آن برداشت fetchmail از کاربر اجراکننده است که از نخستین متغیر محیطی تعریف‌شده میان FETCHMAILUSER، LOGNAME و USER گرفته می‌شود. (در حال حاضر در خروجی --help فهرست نشده است)

نکته: این مورد به ازای هر "poll" است و برای تمام سرورهای فهرست‌شده در فهرست smtphost شما یکسان خواهد بود!

نکته: در حال حاضر fetchmail الزام نمی‌کند که اتصال حتماً از طریق رابط loopback یا لایه رمزگذاری‌شده امن TLS برقرار شود - اگر سرور SMTP لوکال‌هاست شما نیست، حتماً TLS یا STARTTLS را روی آن اجباری کنید.

--esmtppassword <secret>

(از نسخه 6.5.7؛ کلمه کلیدی: esmtppassword، از نسخه 5.9.9) رمز عبور/راز را برای SMTP AUTH جهت ورود به سرور SMTP تعیین می‌کند. (در حال حاضر در خروجی --help فهرست نشده است)

نکته ۱: به‌جای فایل rcfile نرم‌افزار fetchmail، می‌توانید رمز عبور را در فایل netrc. قرار دهید. خط ورود (login) فایل netrc. باید با esmtpname مطابقت داشته باشد (به آن مراجعه کنید).

نکته ۲: این مورد به ازای هر "poll" است و برای تمام سرورهای فهرست‌شده در فهرست smtphost شما یکسان خواهد بود! رمز عبور از نخستین smtphost یا گزینه /servername= آن در فهرست که دارای یک مدخل netrc. باشد گرفته خواهد شد.

نکته ۳: در حال حاضر fetchmail الزام نمی‌کند که اتصال حتماً از طریق رابط loopback یا لایه رمزگذاری‌شده امن TLS برقرار شود - اگر سرور SMTP لوکال‌هاست شما نیست، حتماً TLS یا STARTTLS را روی آن اجباری کنید.

--fetchdomains <hosts>

(کلمه کلیدی: fetchdomains)
در حالت ETRN یا ODMR، این گزینه فهرستی از دامنه‌هایی را مشخص می‌کند که سرور باید پس از برقراری اتصال دوطرفه، نامه‌های مربوط به آن‌ها را ارسال کند. پیش‌فرض، FQDN ماشینی است که fetchmail را اجرا می‌کند.

-D <domain> | --smtpaddress <domain>

(کلمه کلیدی: smtpaddress)
دامنه‌ای را مشخص می‌کند که باید به آدرس‌های موجود در خطوط RCPT TO ارسالی به SMTP افزوده شود. در صورت عدم تعیین، نام سرور SMTP (همان‌طور که با --smtphost مشخص شده است) برای SMTP/LMTP و 'localhost' برای سوکت یونیکس/BSMTP استفاده می‌شود.

نکته: اگر قصد دارید از آدرس‌های عددی با fetchmail نسخه 6.5.5 یا قدیمی‌تر استفاده کنید، یا از به‌اصطلاح لیترال‌های آدرس طبق استاندارد SMTP، آن‌ها را با ساختار نحوی مناسب SMTP بنویسید، برای نمونه --smtpaddress "[192.0.2.6]" یا --smtpaddress "[IPv6:2001:DB8::6]".

--smtpname <user@domain>

(کلمه کلیدی: smtpname)
کاربر و دامنه‌ای را که باید در خطوط RCPT TO ارسالی به SMTP قرار گیرند، مشخص می‌کند. کاربر پیش‌فرض، کاربر محلی جاری است. لطفاً به نکته بالا درباره --smtpaddress و لیترال‌های آدرس نیز مراجعه کنید.

-Z <nnn> | --antispam <nnn[, nnn]...>

(کلمه کلیدی: antispam)
فهرستی از خطاهای عددی SMTP را مشخص می‌کند که باید به عنوان پاسخ مسدودسازی هرزنامه از سوی شنونده تفسیر شوند. مقدار 1- این گزینه را غیرفعال می‌کند. برای گزینه خط فرمان، مقادیر فهرست باید با کاما جدا شوند. توجه داشته باشید که مقادیر antispam تنها برای پاسخ‌های "MAIL FROM" در گفتگوی SMTP/LMTP اعمال می‌شوند، اما چندین MTA (مانند Postfix در پیکربندی پیش‌فرض خود، qmail) کد پاسخ ضد هرزنامه را تا پس از RCPT TO به تعویق می‌اندازند. --antispam در این شرایط کار نمی‌کند. همچنین به --softbounce (پیش‌فرض) و معکوس آن مراجعه کنید.

-m <command> | --mda <command>

(کلمه کلیدی: mda)
این گزینه به fetchmail اجازه می‌دهد مستقیماً از یک عامل تحویل پیام یا محلی (MDA یا LDA) استفاده کند، به‌جای اینکه نامه‌ها را از طریق SMTP یا LMTP فوروارد کند.

برای جلوگیری از گم شدن نامه‌ها، از این گزینه تنها با MDAهایی مانند maildrop یا MTAهایی مانند sendmail استفاده کنید که در صورت پر بودن دیسک و سایر خطاهای تحویل، با وضعیت غیر صفر خارج می‌شوند؛ این وضعیت غیر صفر به fetchmail اطلاع می‌دهد که تحویل با شکست مواجه شده است و از حذف پیام روی سرور جلوگیری می‌کند.

اگر fetchmail با دسترسی ریشه (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" (نکته: برخی نسخه‌های قدیمی‌تر یا ارائه‌شده توسط توزیع‌کنندگان sendmail به اشتباه -- را به عنوان یک آدرس در نظر می‌گیرند، نه به عنوان نشانه‌ای برای پایان آرگومان‌های گزینه‌ها)، "/usr/bin/deliver" و "/usr/bin/maildrop -d %T". آدرس‌های تحویل محلی در هر کجای دستور MDA که %T قرار دهید درج می‌شوند؛ آدرس فرستنده (From) پیام نیز در جایی که %F قرار دهید درج خواهد شد.

رشته‌های %F یا %T را داخل کوتیشن تکی (Single Quote) قرار ندهید! برای هر دو مورد %T و %F، برنامه fetchmail آدرس‌ها را پس از حذف هرگونه کوتیشن تکی موجود در آن‌ها، داخل کوتیشن تکی (') محصور می‌کند و سپس دستور MDA به شل ارسال می‌شود.

هرگز از فراخوانی MDA که بر اساس محتوای To/Cc/Bcc تصمیم‌گیری می‌کند استفاده نکنید، مانند "sendmail -i -t" یا "qmail-inject"، زیرا باعث ایجاد حلقه‌های نامه (mail loops) شده و خشم به‌حق بسیاری از مدیران پست را متوجه شما خواهد کرد. این یکی از شایع‌ترین خطاهای پیکربندی است!

همچنین، هرگز سعی نکنید حالت multidrop را با یک MDA مانند maildrop که تنها یک آدرس را می‌پذیرد ترکیب کنید، مگر اینکه سرور بالادست شما یک نسخه از پیام را به ازای هر گیرنده ذخیره کند و گیرنده پاکت نامه (envelope recipient) را در یک هدر انتقال دهد؛ در غیر این صورت نامه‌های خود را از دست خواهید داد.

بسته نرم‌افزاری شناخته‌شده procmail(1) پیکربندی بسیار دشواری دارد و در صورت بروز خطاهای تحویل (حتی خطاهای موقت مانند کمبود فضای دیسک در صورتی که دیمن نامه کاربر دیگری میل‌باکس را برای پاکسازی پیام‌های قدیمی جابه‌جا کند) رفتار بسیار زننده «رد شدن و رفتن به قاعده بعدی» را از خود نشان می‌دهد، بنابراین نامه‌های شما دیر یا زود سر از میل‌باکس اشتباهی درمی‌آورند. پیکربندی صحیح procmail خارج از محدوده این سند است. استفاده از maildrop(1) معمولاً بسیار آسان‌تر است و بسیاری از کاربران ساختار فیلترهای مورداستفاده در maildrop را ساده‌تر و قابل‌فهم‌تر می‌دانند.

در نهایت، اکیداً توصیه می‌کنیم که از qmail-inject استفاده نکنید. رابط خط فرمان آن غیراستاندارد است بدون اینکه مزیتی برای کاربردهای معمول فراهم کند، و fetchmail هیچ تلاشی برای انطباق با انحرافات qmail-inject از استانداردهای معمول انجام نمی‌دهد. برخی از گزینه‌های خط فرمان و محیطی qmail-inject در واقع خطرناک هستند و می‌توانند باعث شکستن زنجیره گفتگوها (broken threads)، عدم شناسایی پیام‌های تکراری و ایجاد حلقه‌های فوروارد شوند.

--lmtp

(کلمه کلیدی: lmtp)
موجب تحویل از طریق LMTP (پروتکل انتقال محلی نامه) می‌شود. در صورت انتخاب این گزینه، میزبان سرویس و پورت باید صراحتاً روی هر میزبان در فهرست smtphost (بالا را ببینید) مشخص شوند؛ پورت پیش‌فرض ۲۵ (مطابق با RFC 2033) پذیرفته نخواهد شد.

--bsmtp <filename>

(کلمه کلیدی: bsmtp)
نامه‌های دریافت شده را به یک فایل BSMTP الحاق می‌کند. این فایل صرفاً شامل دستورات SMTP است که معمولاً هنگام ارسال نامه به یک دیمن شنونده SMTP توسط fetchmail تولید می‌شوند.

آرگومان '-' باعث می‌شود بسته BSMTP در خروجی استاندارد نوشته شود که کاربرد محدودی دارد: این حالت تنها برای اشکال‌زدایی منطقی است، زیرا خروجی عادی fetchmail روی همان کانال با آن ترکیب می‌شود و در نتیجه برای تحویل واقعی نامه مناسب نیست. این حالت ویژه ممکن است در نسخه‌های بعدی حذف شود.

توجه داشته باشید که بازسازی خطوط MAIL FROM و RCPT TO توسط fetchmail لزوماً بدون نقص نیست؛ هشدارهایی که در بخش «استفاده و سوءاستفاده از صندوق‌های چندمقصده» (THE USE AND ABUSE OF MULTIDROP MAILBOXES) در ادامه بررسی شده‌اند در اینجا نیز صدق می‌کنند. این حالت نسبت به --mda و SMTP/LMTP اولویت دارد.

--bad-header {reject|accept}

(کلمه کلیدی: bad-header؛ از نسخه 6.3.15)
تعیین می‌کند که fetchmail چگونه باید با پیام‌های دارای هدرهای نادرست (یعنی هدرهایی با ساختار نحوی نامعتبر) رفتار کند. از گذشته، fetchmail چنین پیام‌هایی را رد می‌کرد، اما برخی توزیع‌کنندگان fetchmail را تغییر دادند تا آن‌ها را بپذیرد. اکنون می‌توانید رفتار fetchmail را به ازای هر سرور پیکربندی کنید.

گزینه‌های کنترل محدودیت منابع (Resource Limit Control Options)

-l <maxbytes> | --limit <maxbytes>

(کلمه کلیدی: limit)
یک آرگومان حداکثر اندازه بر حسب بایت (octet) می‌گیرد که در آن ۰ مقدار پیش‌فرض و همچنین مقدار ویژه به معنای «بدون محدودیت» است. در صورت غیر صفر بودن، پیام‌های بزرگتر از این اندازه واکشی نخواهند شد و روی سرور باقی می‌مانند (در نشست‌های پیش‌زمینه، پیام‌های پیشرفت وضعیت اشاره می‌کنند که پیام‌ها "oversized" یا بیش از حد بزرگ هستند). اگر پروتکل واکشی اجازه دهد (به‌ویژه در IMAP یا POP3 بدون گزینه fetchall)، پیام به عنوان دیده‌شده علامت‌گذاری نخواهد شد.

مقدار صریح ۰ برای --limit هرگونه محدودیت تنظیم‌شده در فایل کنترل اجرای شما را لغو می‌کند. این گزینه برای کسانی در نظر گرفته شده است که به دلیل هزینه‌های متغیر و گران تماس‌های تلفنی نیاز دارند زمان واکشی را به دقت کنترل کنند.

در ترکیب با --limitflush، می‌توان از آن برای حذف پیام‌های بسیار بزرگی که روی سرور منتظر مانده‌اند استفاده کرد. در حالت دیمن، اعلان‌های مربوط به پیام‌های بیش از حد بزرگ برای کاربر فراخواننده ایمیل می‌شود (به گزینه --warnings مراجعه کنید). این گزینه همراه با ETRN یا ODMR کار نمی‌کند.

-w <interval> | --warnings <interval>

(کلمه کلیدی: warnings)
یک بازه زمانی بر حسب ثانیه می‌گیرد. هنگامی که fetchmail را با گزینه 'limit' در حالت دیمن اجرا می‌کنید، این گزینه بازه زمانی ارسال هشدارهای مربوط به پیام‌های بیش از حد بزرگ به کاربر فراخواننده (یا کاربر مشخص‌شده توسط گزینه 'postmaster') را کنترل می‌کند. یک اعلان از این دست همیشه در پایان نخستین بررسی (poll) که در آن پیام بسیار بزرگ شناسایی شود ارسال می‌گردد. پس از آن، ارسال مجدد اعلان تا زمان سپری شدن بازه هشدار متوقف می‌شود (و در پایان نخستین بررسی پس از آن انجام خواهد شد).

-b <count> | --batchlimit <count>

(کلمه کلیدی: batchlimit)
حداکثر تعداد پیام‌هایی را که پیش از قطع عمدی اتصال و بازسازی مجدد آن به یک شنونده SMTP ارسال می‌شوند، مشخص می‌کند (پیش‌فرض ۰ است که به معنای بدون محدودیت می‌باشد). تعیین صریح مقدار ۰ برای --batchlimit هرگونه محدودیت تنظیم‌شده در فایل کنترل اجرای شما را لغو می‌کند. در حالی که sendmail(8) معمولاً بلافاصله پس از دریافت پایان‌دهنده پیام، فرآیند تحویل را آغاز می‌کند، برخی شنوندگان SMTP چندان سریع نیستند. MTAهایی مانند smail(8) ممکن است تا زمان بسته شدن سوکت تحویل برای تحویل دادن نامه‌ها منتظر بمانند. این موضوع ممکن است هنگام پردازش دسته‌های بسیار بزرگ توسط fetchmail تاخیرهای آزاردهنده‌ای ایجاد کند. تنظیم محدودیت دسته روی یک مقدار غیر صفر از این تاخیرها جلوگیری خواهد کرد. این گزینه همراه با ETRN یا ODMR کار نمی‌کند.

-B <number> | --fetchlimit <number>

(کلمه کلیدی: fetchlimit)
تعداد پیام‌های پذیرفته‌شده از یک سرور مشخص را در یک بار بررسی محدود می‌کند. به صورت پیش‌فرض محدودیتی وجود ندارد. تعیین صریح مقدار ۰ برای --fetchlimit هرگونه محدودیت تنظیم‌شده در فایل کنترل اجرای شما را لغو می‌کند. این گزینه همراه با ETRN یا ODMR کار نمی‌کند.

--fetchsizelimit <number>

(کلمه کلیدی: fetchsizelimit)
تعداد اندازه‌های پیام‌های پذیرفته‌شده از یک سرور مشخص را در یک تراکنش محدود می‌کند. این گزینه برای کاهش تاخیر در دانلود نخستین نامه در زمانی که نامه‌های زیادی در صندوق پستی وجود دارد مفید است. به صورت پیش‌فرض، این محدودیت ۱۰۰ است. اگر روی ۰ تنظیم شود، اندازه‌های تمام پیام‌ها در ابتدا دانلود می‌شوند. این گزینه همراه با ETRN یا ODMR کار نمی‌کند. برای POP3، تنها مقدار غیر صفر معتبر ۱ است.

--fastuidl <number>

(کلمه کلیدی: fastuidl)
به‌جای جستجوی خطی، یک جستجوی دودویی برای یافتن نخستین UID دیده‌نشده انجام می‌دهد. جستجوی دودویی از دانلود UIDهای تمام نامه‌ها جلوگیری می‌کند. این کار در زمان صرفه‌جویی می‌کند (به‌ویژه در حالت دیمن) که در آن دانلود مجموعه یکسانی از UIDها در هر بررسی هدر دادن پهنای باند است. عدد 'n' نشان می‌دهد که جستجوی خطی هر چند وقت یک‌بار باید انجام شود. در حالت دیمن، در صورتی که 'n' بزرگتر از ۱ باشد، جستجوی خطی یک بار انجام شده و سپس در 'n-1' بار بررسی بعدی از جستجوی دودویی استفاده می‌شود؛ اگر 'n' برابر با ۱ باشد همواره از جستجوی دودویی استفاده می‌شود؛ اگر 'n' برابر با ۰ باشد همواره از جستجوی خطی استفاده می‌شود. در حالت غیر دیمن، اگر 'n' برابر با ۱ باشد از جستجوی دودویی استفاده می‌شود؛ در غیر این صورت جستجوی خطی به کار می‌رود. مقدار پیش‌فرض 'n' برابر با ۴ است. این گزینه تنها با POP3 کار می‌کند.

-e <count> | --expunge <count>

(کلمه کلیدی: expunge)
ترتیبی می‌دهد که حذف نامه‌ها پس از تعداد معینی پیام نهایی شود. تحت POP2 یا POP3، برنامه fetchmail نمی‌تواند بدون ارسال QUIT و پایان دادن به نشست، حذف‌ها را نهایی کند -- با فعال بودن این گزینه، fetchmail یک نشست طولانی بازیابی نامه را به چندین زیرنشست تقسیم می‌کند و پس از هر زیرنشست QUIT می‌فرستد. این روش دفاع خوبی در برابر قطع خط در سرورهای POP3 است. تحت IMAP، برنامه fetchmail معمولاً پس از هر حذف یک دستور EXPUNGE صادر می‌کند تا حذف فوراً انجام شود. این کار زمانی که اتصال شما به سرور ناپایدار و پرهزینه باشد ایمن‌ترین راه است، زیرا از ارسال مجدد نامه‌های تکراری پس از قطع اتصال جلوگیری می‌کند. با این حال، در صندوق‌های پستی بزرگ، بار ناشی از نمایه‌سازی مجدد (re-indexing) پس از هر پیام می‌تواند فشار زیادی به سرور وارد کند، بنابراین اگر اتصال شما قابل اعتماد است، بهتر است دستورات expunge با دفعات کمتری اجرا شوند. همچنین توجه داشته باشید که برخی سرورها پس از هر خروج تاخیری چند ثانیه‌ای اعمال می‌کنند، بنابراین fetchmail ممکن است نتواند بلافاصله پس از یک expunge دوباره وارد شود -- در صورت وقوع ممکن است خطاهای "lock busy" را مشاهده کنید. اگر این گزینه را روی یک عدد صحیح N تنظیم کنید، به fetchmail می‌گوید که تنها به ازای هر Nمین حذف، دستور expunge صادر کند. آرگومان صفر دستورات expunge را کاملاً متوقف می‌کند (بنابراین تا پایان اجرا هیچ expungeای انجام نخواهد شد). این گزینه همراه با ETRN یا ODMR کار نمی‌کند.

گزینه‌های احراز هویت (Authentication Options)

-u <name> | --user <name> | --username <name>

(کلمه کلیدی: user[name])
شناسه کاربری مورد استفاده هنگام ورود به سرور نامه را مشخص می‌کند. شناسه کاربری مناسب هم به سرور و هم به کاربر بستگی دارد. پیش‌فرض، نام کاربری شما در ماشین کلاینتی است که fetchmail را اجرا می‌کند. برای شرح کامل به بخش «احراز هویت کاربر» (USER AUTHENTICATION) در ادامه مراجعه کنید.

-I <specification> | --interface <specification>

(کلمه کلیدی: interface)
الزام می‌کند که پیش از شروع بررسی، یک دستگاه رابط (interface) خاص بالا باشد و یک آدرس (یا محدوده آدرس) محلی یا راه دور IPv4 مشخص داشته باشد (IPv6 هنوز توسط این گزینه پشتیبانی نمی‌شود). غالباً fetchmail روی یک پیوند گذرا و نظیر‌به‌نظیر TCP/IP که مستقیماً از طریق SLIP یا PPP به یک سرور نامه برقرار شده است استفاده می‌شود. این یک کانال نسبتاً امن است. اما هنگامی که مسیرهای TCP/IP دیگری به سرور نامه وجود داشته باشد (برای نمونه زمانی که پیوند به یک ISP جایگزین متصل است)، ممکن است نام کاربری و رمز عبور شما در برابر شنود آسیب‌پذیر باشد (به‌ویژه هنگامی که حالت دیمن به صورت خودکار برای دریافت نامه‌ها جستجو می‌کند و رمز عبور واضح و رمزنشده را در فواصل زمانی قابل پیش‌بینی روی شبکه ارسال می‌نماید). گزینه --interface می‌تواند برای جلوگیری از این مشکل استفاده شود. هنگامی که پیوند مشخص‌شده بالا نباشد یا به یک آدرس IP منطبق متصل نباشد، مرحله بررسی انجام نخواهد شد. ساختار به این صورت است:

interface/iii.iii.iii.iii[/mmm.mmm.mmm.mmm]

فیلد قبل از نخستین اسلش نام رابط است (مانند sl0، ppp0 و غیره). فیلد قبل از اسلش دوم آدرس IP قابل قبول است. فیلد بعد از اسلش دوم یک ماسک است که محدوده‌ای از آدرس‌های IP مورد قبول را مشخص می‌کند. اگر ماسکی وجود نداشته باشد، 255.255.255.255 فرض می‌شود (یعنی تطابق دقیق). این گزینه در حال حاضر تنها تحت لینوکس و FreeBSD پشتیبانی می‌شود. لطفاً برای اطلاعات ویژه FreeBSD به بخش monitor در زیر مراجعه کنید.

توجه داشته باشید که ممکن است این گزینه در نسخه‌های آینده fetchmail حذف شود.

-M <interface> | --monitor <interface>

(کلمه کلیدی: monitor)
حالت دیمن می‌تواند باعث شود پیوندهای گذرایی که پس از یک دوره عدم فعالیت به طور خودکار قطع می‌شوند (مانند پیوندهای PPP)، به طور نامحدود بالا و متصل بمانند. این گزینه یک رابط TCP/IP سیستمی را برای پایش فعالیت مشخص می‌کند. پس از هر بازه بررسی، اگر پیوند برقرار باشد اما هیچ فعالیت دیگری روی آن رخ نداده باشد، آن بررسی نادیده گرفته خواهد شد. با این حال، هنگامی که fetchmail با یک سیگنال بیدار می‌شود، بررسی مانیتور نادیده گرفته شده و عملیات واکشی بدون قید و شرط انجام می‌شود. این گزینه در حال حاضر تنها تحت لینوکس و FreeBSD پشتیبانی می‌شود. برای اینکه گزینه‌های monitor و interface برای کاربران غیر ریشه تحت FreeBSD کار کنند، باینری fetchmail باید به صورت setgid kmem نصب شده باشد. این کار می‌توانست یک حفره امنیتی باشد، اما fetchmail شناسه مؤثر GID خود را تنها زمانی روی گروه kmem تنظیم می‌کند که داده‌های رابط در حال جمع‌آوری باشند.

توجه داشته باشید که ممکن است این گزینه در نسخه‌های آینده fetchmail حذف شود.

--auth <type>

(کلمه کلیدی: auth[enticate])
این گزینه به شما اجازه می‌دهد نوع احراز هویت را مشخص کنید (برای جزئیات به بخش «احراز هویت کاربر» (USER AUTHENTICATION) در زیر مراجعه کنید). مقادیر ممکن عبارتند از: any، password، kerberos_v5، kerberos (یا برای دقت فوق‌العاده بالا، kerberos_v4)، gssapi، cram-md5، otp، ntlm، msn (تنها برای POP3)، external (تنها IMAP) و implicit (ssh به عنوان نام مستعار برای implicit شناخته می‌شود). هنگامی که any (پیش‌فرض) مشخص شود، fetchmail ابتدا روش‌هایی را که نیازی به رمز عبور ندارند (EXTERNAL، GSSAPI، KERBEROS IV، KERBEROS 5) آزمایش می‌کند؛ سپس به دنبال روش‌هایی می‌گردد که رمز عبور شما را بپوشانند و ماسک کنند (CRAM-MD5، NTLM، X-OTP - توجه داشته باشید که MSN تنها برای POP3 پشتیبانی می‌شود و به صورت خودکار شناسایی نمی‌شود)؛ و تنها در صورتی که سرور از هیچ‌یک از آن‌ها پشتیبانی نکند، رمز عبور شما را بدون رمزگذاری ارسال خواهد کرد. مقادیر دیگر را می‌توان برای اجبار به استفاده از روش‌های احراز هویت گوناگون به کار برد: implicit احراز هویت را غیرفعال می‌کند و بنابراین برای IMAP PREAUTH مفید است (اگر از یک --plugin امن استفاده می‌کنید، برای نمونه یک ssh به درستی پیکربندی‌شده، ممکن است لازم باشد --sslproto '' یا در فایل rcfile گزینه sslproto '' را نیز تنظیم کنید تا از مذاکره STARTTLS توسط fetchmail روی بستر SSH جلوگیری شود). external احراز هویت را غیرفعال می‌کند و از این رو برای IMAP EXTERNAL کاربرد دارد. هر مقداری به جز password، cram-md5، ntlm، msn یا otp درخواست عادی fetchmail برای دریافت رمز عبور را متوقف می‌کند. هنگامی که از یک اتصال امن سرتاسری مانند تونل ssh استفاده می‌کنید، implicit را مشخص نمایید (در این حالت ممکن است بخواهید --sslproto '' را نیز مشخص کنید که به آن اشاره شد)؛ هنگامی که از TLS با احراز هویت کلاینت استفاده می‌کنید، external را تعیین کنید و در صورتی که از نوعی پروتکل استفاده می‌کنید که GSSAPI یا K4 را به کار می‌برد، gssapi یا kerberos_v4 را مشخص کنید. انتخاب پروتکل KPOP به صورت خودکار احراز هویت Kerberos را انتخاب می‌کند. این گزینه با ETRN کار نمی‌کند. نام‌های سرویس GSSAPI مطابق با RFC-2743 و ثبت‌های IANA هستند، پیوند زیر را ببینید: نام‌های سرویس رابط برنامه‌نویسی کاربردی سرویس‌های امنیتی عمومی (GSSAPI) / کربروس / لایه احراز هویت ساده و امنیت (SASL).

گزینه‌های گوناگون (Miscellaneous Options)

-f <pathname> | --fetchmailrc <pathname>

نامی غیر از نام پیش‌فرض را برای فایل کنترل اجرای ~/.fetchmailrc مشخص می‌کند. آرگومان pathname باید "-" (یک خط تیره تنها، به معنای خواندن پیکربندی از ورودی استاندارد) یا یک نام فایل باشد. مگر اینکه گزینه --version نیز فعال باشد، یک فایل نام‌گذاری‌شده نباید مجوزی بازتر از 0700 (u=rwx,g=,o=) داشته باشد یا اینکه باید dev/null/ باشد.

-i <pathname> | --idfile <pathname>

(کلمه کلیدی: idfile)
یک نام جایگزین برای فایل fetchids. مشخص می‌کند که برای ذخیره UIDهای پیام‌ها استفاده می‌شود. نکته: از نسخه 6.3.0 به بعد fetchmail، دسترسی نوشتن به دایرکتوری حاوی idfile الزامی است، زیرا fetchmail یک فایل موقت می‌نویسد و تنها در صورت موفقیت‌آمیز بودن نوشتن فایل موقت، نام آن را به جای idfile واقعی تغییر می‌دهد. این کار از کوتاه و خراب شدن idfileها در صورت اتمام فضای دیسک جلوگیری می‌کند.

--pidfile <pathname>

(کلمه کلیدی: pidfile؛ از نسخه 6.3.4 به بعد fetchmail)
محل پیش‌فرض فایل PID را که به عنوان یک فایل قفل (lock file) استفاده می‌شود بازنویسی می‌کند. پیش‌فرض: به بخش "ENVIRONMENT" در ادامه مراجعه کنید. توجه داشته باشید که در بسیاری از بخش‌های کد و مستندات، اصطلاح "lock file" به کار رفته است. این فایل شامل شناسه فرآیند (Process ID) برنامه در حال اجرای fetchmail در خط نخست و احتمالاً بازه زمانی دیمن در خط دوم است.

-n | --norewrite

(کلمه کلیدی: no rewrite)
به طور معمول، fetchmail هدرهای آدرس RFC-822 (شامل To، From، Cc، Bcc و Reply-To) را در نامه‌های واکشی‌شده ویرایش می‌کند تا هر شناسه نامه‌ای که متعلق به سرور محلی است به آدرس‌های کامل بسط داده شود (@ و نام میزبان سرور نامه الحاق می‌شوند). این قابلیت باعث می‌شود پاسخ‌ها در کلاینت به درستی آدرس‌دهی شوند (در غیر این صورت برنامه ایمیل شما ممکن است تصور کند نامه‌ها باید برای کاربران محلی روی ماشین کلاینت آدرس‌دهی شوند!). این گزینه بازنویسی را غیرفعال می‌کند. (این گزینه برای آسودگی خاطر افرادی فراهم شده است که در مورد ویرایش هدرهای نامه توسط MTA حساسیت دارند و می‌خواهند بدانند که می‌توانند مانع آن شوند، اما به طور کلی غیرفعال کردن بازنویسی ایده خوبی نیست.) هنگام استفاده از ETRN یا ODMR، گزینه rewrite بی‌تاثیر است.

-E <line> | --envelope <line>

(کلمه کلیدی: envelope؛ تنها Multidrop)
در فایل پیکربندی، ساختار نحوی پیشرفته‌تری استفاده می‌شود:
envelope [<count>] <line>

این گزینه هدری را که fetchmail فرض می‌کند حاوی رونوشتی از آدرس پاکت نامه (envelope address) است، تغییر می‌دهد. به طور معمول این هدر 'X-Envelope-To' است. هدرهای متداول دیگری که اطلاعات پاکت را حمل می‌کنند عبارتند از 'X-Original-To' و 'Delivered-To'. از آنجا که این هدرها استانداردسازی نشده‌اند، رویه‌ها متفاوت است. به بحث پیرامون مدیریت آدرس‌های multidrop در ادامه مراجعه کنید. به عنوان یک حالت ویژه، 'envelope "Received"' امکان تجزیه خطوط Received به سبک sendmail را فراهم می‌کند. این حالت پیش‌فرض است، اما توصیه نمی‌شود زیرا کاملاً قابل اعتماد نیست.

توجه داشته باشید که fetchmail انتظار دارد خط Received در قالب خاصی باشد: این خط باید شامل "by host for address" باشد که در آن host باید با یکی از نام‌های سرور نامه‌ای که fetchmail برای حساب کاربری مربوطه می‌شناسد مطابقت داشته باشد.

آرگومان اختیاری count (که تنها در فایل پیکربندی در دسترس است) تعیین می‌کند که چه تعداد از خطوط هدر این چنینی نادیده گرفته شوند. مقدار count برابر با ۱ به این معناست: خط اول را نادیده بگیر، خط دوم را بردار. مقدار ۲ یعنی: خطوط اول و دوم را نادیده بگیر، خط سوم را بردار، و الی آخر.

-Q <prefix> | --qvirtual <prefix>

(کلمه کلیدی: qvirtual؛ تنها Multidrop)
پیشوند رشته‌ای اختصاص‌یافته به این گزینه از نام کاربری یافت‌شده در هدر مشخص‌شده با گزینه envelope حذف خواهد شد (پیش از انجام نگاشت نام multidrop یا بررسی localdomain، در صورت اعمال هر یک). این گزینه در صورتی مفید است که از fetchmail برای جمع‌آوری نامه‌های یک دامنه کامل استفاده می‌کنید و ISP شما (یا ارائه‌دهنده تغییر مسیر نامه شما) از qmail استفاده می‌کند. یکی از ویژگی‌های اساسی qmail هدر پیام Delivered-To: است. هر زمان که qmail پیامی را به یک صندوق پستی محلی تحویل می‌دهد، نام کاربری و نام میزبان گیرنده پاکت نامه را در این خط قرار می‌دهد. دلیل اصلی این کار جلوگیری از حلقه‌های نامه است. برای تنظیم qmail جهت دسته‌بندی نامه‌ها برای سایتی که آفلاین است، میزبان نامه ISP معمولاً آن سایت را در فایل کنترل 'Virtualhosts' خود قرار می‌دهد تا یک پیشوند به تمام آدرس‌های نامه این سایت اضافه کند. این امر منجر می‌شود نامه‌هایی که به 'username@userhost.userdom.dom.com' فرستاده می‌شوند، دارای خط Delivered-To: به این شکل باشند:

Delivered-To: mbox-userstr-username@userhost.example.com

ارائه‌دهنده اینترنت (ISP) می‌تواند پیشوند 'mbox-userstr-' را هر چه که بخواهد تعیین کند، اما رشته‌ای که با نام میزبان کاربر مطابقت داشته باشد محتمل‌تر است. با استفاده از گزینه 'envelope Delivered-To:' می‌توانید کاری کنید که fetchmail گیرنده اصلی پاکت نامه را با قابلیت اطمینان شناسایی کند، اما برای تحویل به کاربر صحیح باید پیشوند 'mbox-userstr-' را حذف نمایید. این گزینه دقیقاً برای همین منظور است.

--configdump

فایل ~/.fetchmailrc را تجزیه می‌کند، هر گزینه خط فرمان مشخص‌شده‌ای را تفسیر می‌نماید و یک گزارش پیکربندی را در خروجی استاندارد ثبت می‌کند. گزارش پیکربندی یک انتساب ساختار داده در زبان پایتون است. این گزینه برای استفاده در یک ویرایشگر تعاملی ~/.fetchmailrc مانند fetchmailconf که به زبان پایتون نوشته شده در نظر گرفته شده است.

-y | --yydebug

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

گزینه‌های حذف‌شده (Removed Options)

-T | --netsec

پیش از نسخه 6.3.0 حذف شد، زیرا کتابخانه زیربنایی مورد نیاز inet6_apps منسوخ شده و دیگر در دسترس نیست.

استفاده از فایل‌های netrc (Using netrc files)

اگر گذرواژه‌ای تعیین نکنید و fetchmail نتواند آن را از فایل ~/.fetchmailrc شما استخراج کند، پیش از درخواست تعاملی آن، به دنبال فایل ~/.netrc در دایرکتوری خانگی شما می‌گردد؛ اگر ورودی منطبق با سرور ایمیل در آن فایل یافت شود، از آن گذرواژه استفاده خواهد شد. برنامه fetchmail ابتدا به دنبال تطابق بر اساس نام poll می‌گردد؛ اگر موردی نیافت، تطابق بر اساس نام via را بررسی می‌کند. برای نشان دادن یک مثال کاربردی، فایل netrc. ممکن است به این شکل باشد:

machine hermes.example.org
login joe
password topsecret

در صورت نیاز به ارائه بیش از یک گذرواژه، می‌توانید این بلوک را با اطلاعات کاربری مختلف تکرار کنید.

این قابلیت به شما امکان می‌دهد از تکرار اطلاعات گذرواژه در بیش از یک فایل جلوگیری کنید.

فایل netrc شامل اطلاعات ورود به سیستمی است که در اصل برای ftp(1) تنظیم شده بود، اما fetchmail ساختارهای معمول این فایل را برای استفاده از گذرواژه‌ها درک می‌کند. قواعد نحوی شامل نشانه‌ها (معمولاً به صورت جفت همراه با رشته‌ها) است. رشته‌ها می‌توانند داخل علامت نقل‌قول تکی یا دوتایی قرار گیرند (مانند "quoted string") تا امکان گنجاندن فاصله‌های خالی وجود داشته باشد، و یک بک‌اسلش (\) در یک رشته نقل‌قول‌شده، کاراکتر بعدی را اسکیپ می‌کند تا گذرواژه بتواند خودش حاوی علامت‌های نقل‌قول باشد. نشانه‌ها با فاصله‌ها، تب‌ها یا کاراکترهای خط جدید از یکدیگر جدا می‌شوند.

این نشانه‌ها پشتیبانی می‌شوند:

machine name

نام رایانه راه دور را که نشانه‌های بعدی برای آن اعمال می‌شوند، مشخص می‌کند. این نام باید با نام poll یا via در fetchmail مطابقت داشته باشد.

login name

نام کاربری را مشخص می‌کند که fetchmail هنگام جستجوی ورودی‌ها با آن مطابقت می‌دهد. برنامه Fetchmail نام‌های با طول صفر یا ورودی‌های فاقد login را نادیده می‌گیرد.

password string

گذرواژه‌ای را مشخص می‌کند که fetchmail هنگام تطابق machine و login با نام poll/via و نام کاربری از آن استفاده خواهد کرد.

default

این نشانه شبیه به machine است، اما با هر نامی مطابقت دارد. برنامه Fetchmail آن را نادیده می‌گیرد. پس از این نشانه، بخش‌های machine دیگری مجاز نیستند.

account string

برنامه Fetchmail این جفت نشانه/رشته را نادیده می‌گیرد.

macdef macro_name

برنامه Fetchmail این تعریف ماکرو را نادیده می‌گیرد، به این معنی که این خط، باقی‌مانده خطوط و تمام خطوط بعدی تا رسیدن به یک خط خالی (یعنی دو کاراکتر متوالی خط جدید) نادیده گرفته می‌شوند. سپس تجزیه netrc. از سر گرفته می‌شود.

در سرورهای ایمیلی که حساب‌های کاربری عادی ارائه نمی‌دهند، شناسه کاربری و گذرواژه شما معمولاً هنگام درخواست صندوق پستی در سرور، توسط مدیر سرور اختصاص داده می‌شود. اگر شناسه کاربری و گذرواژه صحیح صندوق پستی خود را نمی‌دانید، با مدیر سرور خود تماس بگیرید.

لایه‌های سوکت امن (SSL) و امنیت لایه انتقال (TLS) (Secure Socket Layers (SSL) and Transport Layer Security (TLS))

تمامی پروتکل‌های دریافت می‌توانند از پوشش SSL یا TLS برای انتقال داده استفاده کنند. علاوه بر این، دریافت POP3 و IMAP نیز می‌تواند از طریق STARTTLS (یا STLS) پروتکل SSL/TLS را مذاکره کند.

می‌توانید با مشخص کردن گزینه‌هایی که با --ssl شروع می‌شوند (مانند --ssl, --sslproto, --nosslcertck و سایر موارد) به سرویس‌های رمزنگاری‌شده با TLS دسترسی پیدا کنید. همچنین می‌توانید این کار را با استفاده از گزینه‌های کاربری متناظر در فایل .fetchmailrc انجام دهید. برخی سرویس‌ها، مانند POP3 و IMAP، درگاه‌های شناخته‌شده متفاوتی برای سرویس‌های رمزنگاری‌شده با SSL تعریف کرده‌اند. درگاه‌های رمزنگاری‌شده زمانی که SSL فعال باشد و درگاه صریحی مشخص نشده باشد، به طور خودکار انتخاب خواهند شد. همچنین، گزینه خط فرمان --sslcertck یا گزینه فایل کنترل اجرای sslcertck باید حداقل در مستندات برای اجبار به بررسی دقیق گواهی در نسخه‌های قدیمی‌تر fetchmail استفاده شود - توضیحات زیر را ببینید.

اگر TLS یا SSL پیکربندی نشده باشد، fetchmail معمولاً همچنان تلاش می‌کند از STARTTLS استفاده کند. در عمل، TLS یا SSL همچنان الزامی است زیرا --sslcertck یک تنظیم پیش‌فرض است و به طور ضمنی نیازمند STARTTLS است.

پروتکل STARTTLS می‌تواند با استفاده از --sslproto auto اجباری شود و با استفاده از --sslproto '' غیرفعال گردد. اتصالات STARTTLS از همان درگاه نسخه رمزنگاری‌نشده پروتکل استفاده می‌کنند و TLS را از طریق دستور ویژه‌ای مذاکره می‌نمایند. گزینه خط فرمان --sslcertck یا گزینه فایل کنترل اجرای sslcertck باید برای اجبار به بررسی دقیق گواهی استفاده شود - توضیحات زیر را ببینید.

استفاده از --sslcertck توصیه می‌شود: هنگام اتصال به یک سرور رمزنگاری‌شده با SSL یا TLS، سرور گواهی‌ای را برای اعتبارسنجی به کلاینت ارائه می‌دهد. گواهی بررسی می‌شود تا اطمینان حاصل شود نام عمومی (common name) در گواهی با نام سروری که با آن تماس گرفته شده مطابقت دارد و تاریخ‌های شروع و انقضا در گواهی نشان می‌دهند که در حال حاضر معتبر است. اگر هر یک از این بررسی‌ها ناموفق باشد، یک پیام هشدار چاپ می‌شود، اما اتصال ادامه می‌یابد. گواهی سرور نیازی ندارد توسط مرجع صدور گواهی (CA) خاصی امضا شده باشد و می‌تواند یک گواهی «خودامضا» (self-signed) باشد. اگر گزینه خط فرمان --sslcertck یا گزینه فایل کنترل اجرای sslcertck استفاده شود، در صورت ناموفق بودن هر یک از این بررسی‌ها، fetchmail عملیات را متوقف می‌کند، زیرا در این سناریو باید فرض کند حمله مرد میانی (man-in-the-middle) رخ داده است؛ بنابراین fetchmail نباید گذرواژه‌های متن‌ساده را فاش کند. از این رو استفاده از گزینه sslcertck یا --sslcertck توصیه می‌شود؛ این گزینه در نسخه 6.4.0 fetchmail به حالت پیش‌فرض تبدیل شده است.

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

نکته‌ای احتیاطی درباره استفاده از SSL: در حالی که پیکربندی ذکرشده در بالا با گواهی‌های خودامضای سرور که از طریق شبکه دریافت می‌شوند می‌تواند از شما در برابر شنود غیرفعال محافظت کند، در برابر یک مهاجم فعال کمکی نمی‌کند. این روش قطعاً نسبت به ارسال گذرواژه‌ها به صورت متن‌ساده یک پیشرفت است، اما باید آگاه باشید که حمله مرد میانی به سادگی امکان‌پذیر است (به ویژه با ابزارهایی مانند dsniff). اگر به امنیت صندوق پستی و گذرواژه‌های خود اهمیت جدی می‌دهید، استفاده از بررسی دقیق گواهی با یک مرجع صدور گواهی که توسط سرور و کلاینت شناخته شده باشد، یا شاید استفاده از یک تونل SSH (برای برخی مثال‌ها به ادامه مراجعه کنید) ارجحیت دارد.

دستورات RETR یا TOP (RETR or TOP)

برنامه fetchmail تلاش‌هایی انجام می‌دهد تا سرور تصور کند پیام‌ها دریافت نشده‌اند؛ این کار در صورت امکان با استفاده از دستور TOP همراه با تعداد زیادی خط انجام می‌شود. دستور TOP دستوری است که سرآیند کامل و تعداد مشخصی از خطوط بدنه تعیین‌شده توسط fetchmail را دریافت می‌کند. این دستور اختیاری است و بنابراین توسط همه سرورها پیاده‌سازی نشده است، و مشخص شده که برخی سرورها آن را به درستی پیاده‌سازی نمی‌کنند. با این حال، در بسیاری از سرورها دستور RETR که کل پیام را همراه با سرآیند و بدنه دریافت می‌کند، فلگ "دیده شده" (seen) را (مثلاً در رابط وب) تنظیم می‌کند، در حالی که دستور TOP این کار را انجام نمی‌دهد.

اگر "fetchall" تنظیم شده باشد، fetchmail همیشه از دستور RETR استفاده خواهد کرد. همچنین اگر "keep" تنظیم شده و "uidl" تنظیم نشده باشد، fetchmail از دستور RETR استفاده خواهد کرد. در نهایت، fetchmail در سرورهای Maillennium POP3/PROXY (مورد استفاده توسط Comcast) از دستور RETR استفاده می‌کند تا از تفسیر نادرست عمدی TOP در این سرور که باعث خرابی پیام می‌شود، جلوگیری کند.

در تمام موارد دیگر، fetchmail از دستور TOP استفاده خواهد کرد. این بدان معناست که در پیکربندی‌های "keep"، در صورتی که استفاده از "TOP" مد نظر باشد، باید "uidl" تنظیم شود.

توجه داشته باشید که این توضیحات برای نسخه فعلی fetchmail صادق است، اما این رفتار ممکن است در نسخه‌های آینده تغییر کند. به طور خاص، fetchmail ممکن است دستور RETR را ترجیح دهد زیرا دستور TOP در برخی سرورها مشکلات زیادی ایجاد می‌کند و تنها اختیاری است.

احراز هویت ESMTP (ESMTP AUTH)

برنامه fetchmail همچنین از احراز هویت در سرور ESMTP در سمت کلاینت طبق RFC 4952 پشتیبانی می‌کند. سازوکارهای احراز هویت پشتیبانی‌شده عبارتند از CRAM-MD5، PLAIN و در نسخه 6.5.X fetchmail روش منسوخ‌شده LOGIN. می‌توانید یک جفت نام/گذرواژه را برای استفاده با کلیدواژه‌های 'esmtpname' و 'esmtppassword' تعیین کنید؛ اولی به طور پیش‌فرض روی نام کاربری کاربر فراخواننده تنظیم می‌شود.

معرفی حالت دیمن (Introducing the daemon mode)

در حالت دیمن، fetchmail خود را در پس‌زمینه قرار می‌دهد و به طور مداوم اجرا می‌شود، هر هاست مشخص‌شده را بررسی کرده و سپس برای یک بازه زمانی مشخص به خواب می‌رود.

شروع حالت دیمن (Starting the daemon mode)

چندین راه برای اجرای fetchmail در حالت دیمن وجود دارد. در خط فرمان، گزینه --daemon <interval> یا -d <interval> برنامه fetchmail را در حالت دیمن اجرا می‌کند. باید یک آرگومان عددی مشخص کنید که بازه بررسی (مدت زمان انتظار پس از تکمیل یک چرخه کامل بررسی با آخرین سرور و قبل از شروع چرخه بعدی با اولین سرور) بر حسب ثانیه است.

مثال: اجرای ساده دستور

fetchmail -d 900

باعث می‌شود تمام هاست‌های توصیف‌شده در فایل ~/.fetchmailrc شما (به جز مواردی که با عبارت 'skip' صراحتاً مستثنی شده‌اند) با فاصله‌ای کمی کمتر از یک بار در هر ۱۵ دقیقه (دقیقاً: ۱۵ دقیقه + زمانی که بررسی طول می‌کشد) بررسی شوند.

همچنین می‌توان با نوشتن عبارت 'set daemon <interval>' در فایل ~/.fetchmailrc یک بازه زمانی بررسی تنظیم کرد، که در آن <interval> یک عدد صحیح بر حسب ثانیه است. اگر این کار را انجام دهید، fetchmail همیشه در حالت دیمن شروع به کار می‌کند، مگر اینکه با گزینه خط فرمان --daemon 0 یا -d0 آن را لغو کنید.

برای هر کاربر تنها یک فرایند دیمن مجاز است؛ در حالت دیمن، fetchmail یک فایل قفل برای هر کاربر ایجاد می‌کند تا این موضوع را تضمین کند. (البته می‌توانید با تنظیم متغیر محیطی FETCHMAILHOME این محدودیت را دور بزنید، اما در این صورت، مسئولیت اطمینان از اینکه یک سرور را با دو فرایند به طور همزمان بررسی نمی‌کنید بر عهده خودتان است.)

بیدار کردن دیمن پس‌زمینه (Awakening the background daemon)

به طور معمول، فراخوانی fetchmail در حالی که یک دیمن در پس‌زمینه در حال اجراست، یک سیگنال بیدارباش به دیمن ارسال کرده و بدون چاپ خروجی خارج می‌شود. دیمن پس‌زمینه سپس بلافاصله چرخه بررسی بعدی خود را آغاز می‌کند. سیگنال بیدارباش، SIGUSR1، را می‌توان به صورت دستی نیز ارسال کرد. عمل بیدارباش همچنین تمام فلگ‌های 'wedged' را که نشان‌دهنده گیر کردن اتصالات به دلیل شکست در احراز هویت یا اتمام زمان‌های مکرر هستند، پاک می‌کند.

خاتمه دادن به دیمن پس‌زمینه (Terminating the background daemon)

گزینه -q یا --quit به جای بیدار کردن دیمن، فرایند دیمن در حال اجرا را متوقف می‌کند (اگر چنین فرایندی وجود نداشته باشد، fetchmail به شما اطلاع خواهد داد). اگر گزینه --quit به عنوان آخرین گزینه در خط فرمان ظاهر شود، fetchmail فرایند دیمن در حال اجرا را متوقف کرده و سپس خارج می‌شود. در غیر این صورت، fetchmail ابتدا فرایند دیمن در حال اجرا را متوقف می‌کند و سپس با سایر گزینه‌ها به اجرای خود ادامه می‌دهد.

گزینه‌های مفید برای حالت دیمن (Useful options for daemon mode)

گزینه -L <filename> یا --logfile <filename> (کلیدواژه: set logfile) تنها زمانی مؤثر است که fetchmail جدا شده و در حالت دیمن باشد. توجه داشته باشید که فایل گزارش (logfile) باید قبل از اجرای fetchmail وجود داشته باشد؛ می‌توانید از دستور touch(1) با نام فایل به عنوان تنها آرگومان آن برای ایجاد فایل استفاده کنید.
این گزینه به شما امکان می‌دهد پیام‌های وضعیت را به یک فایل گزارش مشخص هدایت کنید (نام فایل گزارش را بعد از گزینه بیاورید). فایل گزارش در حالت الحاق (append) باز می‌شود، بنابراین پیام‌های قبلی حذف نمی‌شوند. این کار در درجه اول برای اشکال‌زدایی پیکربندی‌ها مفید است. توجه داشته باشید که fetchmail چرخش (rotate) فایل گزارش را تشخیص نمی‌دهد؛ فایل گزارش تنها یک بار هنگام شروع fetchmail باز می‌شود. لازم است پس از چرخاندن فایل گزارش و قبل از فشرده‌سازی آن (در صورت وجود)، fetchmail را مجدداً راه‌اندازی کنید.
از نسخه 6.5.0، فایل گزارش با برچسب‌های زمانی، در زمان محلی و با فرمت "Jun 20 23:45:01 fetchmail: " پیشوندگذاری می‌شود. این فرمت از طریق متغیرهای محیطی LC_TIME (یا LC_ALL) و TZ بومی‌سازی خواهد شد.

گزینه --syslog (کلیدواژه: set syslog) به شما امکان می‌دهد پیام‌های وضعیت و خطای صادرشده را در صورت در دسترس بودن به دیمن سیستمی syslog(3) هدایت کنید. پیام‌ها با شناسه fetchmail، بخش LOG_MAIL و اولویت‌های LOG_ERR، LOG_ALERT یا LOG_INFO ثبت می‌شوند. این گزینه برای ثبت پیام‌های وضعیت و خطا در نظر گرفته شده است که وضعیت دیمن و نتایج دریافت ایمیل از سرور(ها) را نشان می‌دهند. پیام‌های خطای مربوط به گزینه‌های خط فرمان و تجزیه فایل .fetchmailrc همچنان در stderr یا در فایل گزارش مشخص‌شده نوشته می‌شوند. گزینه --nosyslog استفاده از syslog(3) را خاموش می‌کند، با این فرض که در فایل ~/.fetchmailrc روشن شده باشد. این گزینه در شرایط خاصی توسط --logfile (که توضیح داده شد) نادیده گرفته می‌شود.

گزینه -N یا --nodetach از رفتن به پس‌زمینه و جدا شدن فرایند دیمن از ترمینال کنترلی آن جلوگیری می‌کند. این قابلیت برای اشکال‌زدایی یا زمانی که fetchmail به عنوان فرزند یک فرایند ناظر مانند init(8) یا runit(8) اثر Gerrit Pape اجرا می‌شود، مفید است. توجه داشته باشید که این کار همچنین باعث نادیده گرفته شدن گزینه logfile می‌شود.

توجه داشته باشید که هنگام اجرا در حالت دیمن و بررسی یک سرور POP2 یا IMAP2bis، خطاهای گذرا (مانند خرابی‌های DNS یا عدم پذیرش تحویل توسط sendmail) ممکن است گزینه fetchall را برای مدت چرخه بررسی بعدی اجباری کنند. این یک ویژگی برای افزایش پایداری است؛ به این معنی که اگر پیامی دریافت شود (و در نتیجه توسط سرور ایمیل به عنوان دیده‌شده علامت‌گذاری شود) اما به دلیل یک خطای گذرا به صورت محلی تحویل داده نشود، در طول چرخه بررسی بعدی دوباره دریافت خواهد شد. (منطق IMAP پیام‌ها را تا زمانی که تحویل داده نشوند حذف نمی‌کند، بنابراین این مشکل در آن رخ نمی‌دهد.)

اگر فایل ~/.fetchmailrc را در حالی که fetchmail در حالت دیمن در حال اجراست تغییر دهید یا دستور touch روی آن اجرا کنید، این تغییر در ابتدای چرخه بررسی بعدی تشخیص داده می‌شود. هنگامی که تغییر فایل ~/.fetchmailrc تشخیص داده شود، fetchmail آن را مجدداً می‌خواند و از ابتدا راه‌اندازی می‌شود (با استفاده از exec(2)؛ هیچ اطلاعات وضعیتی در نمونه جدید حفظ نمی‌شود). توجه داشته باشید که اگر fetchmail نیاز به درخواست گذرواژه داشته باشد، یا اگر ساختار دستوری فایل ~/.fetchmailrc را خراب کنید، نمونه جدید هنگام راه‌اندازی به آرامی و بدون صدا ناپدید خواهد شد.

قواعد نحوی کنترل اجرا (Run Control Syntax)

توضیحات با یک '#' شروع شده و تا انتهای خط ادامه می‌یابند. در غیر این صورت، فایل شامل مجموعه‌ای از ورودی‌های سرور یا دستورات گزینه‌های عمومی در یک ساختار نحوی آزاد و مبتنی بر نشانه است.

چهار نوع نشانه وجود دارد: کلیدواژه‌های دستوری، اعداد (یعنی دنباله‌ای از ارقام ده‌دهی)، رشته‌های بدون نقل‌قول و رشته‌های داخل نقل‌قول. یک رشته داخل نقل‌قول با علامت‌های نقل‌قول دوتایی احاطه می‌شود و می‌تواند شامل فاصله‌های خالی باشد (و ارقام داخل نقل‌قول به عنوان یک رشته در نظر گرفته می‌شوند). توجه داشته باشید که رشته‌های داخل نقل‌قول اگر روی دو یا چند خط امتداد یابند، حاوی کاراکترهای خط جدید (line feed) نیز خواهند بود، مگر اینکه از یک بک‌اسلش برای پیوند دادن خطوط استفاده کنید (به ادامه مراجعه فرمایید). یک رشته بدون نقل‌قول هر نشانه‌ای است که با فاصله خالی جدا شده و نه عددی است، نه داخل نقل‌قول است و نه شامل کاراکترهای ویژه ','، ';'، ':' یا '=' می‌باشد.

هر مقدار فاصله خالی نشانه‌ها را در ورودی‌های سرور از یکدیگر جدا می‌کند، اما در غیر این صورت نادیده گرفته می‌شود. می‌توانید از دنباله‌های اسکیپ بک‌اسلش (\n برای LF، \t برای HT، \b برای BS، \r برای CR، \nnn برای ده‌دهی (که در آن nnn نمی‌تواند با 0 شروع شود)، \0ooo برای هشت‌هشتی، و \xhh برای هگزادسیمال) برای گنجاندن کاراکترهای غیرقابل چاپ یا جداکننده‌های رشته در رشته‌ها استفاده کنید. در رشته‌های داخل نقل‌قول، یک بک‌اسلش در انتهای خط باعث می‌شود که خود بک‌اسلش و کاراکتر خط جدید (LF یا NL) نادیده گرفته شوند تا بتوانید رشته‌های طولانی را بشکنید. بدون بک‌اسلش در انتهای خط، کاراکتر خط جدید بخشی از رشته خواهد شد.

هشدار: اگرچه این دنباله‌ها شبیه به دنباله‌های اسکیپ به سبک C هستند، اما یکسان نیستند. برنامه fetchmail تنها از این هشت سبک پشتیبانی می‌کند. زبان C از دنباله‌های اسکیپ بیشتری که شامل بک‌اسلش (\) و یک کاراکتر منفرد هستند پشتیبانی می‌کند، اما از کدهای ده‌دهی پشتیبانی نمی‌کند و نیازی به 0 ابتدایی در نماد هشت‌هشتی ندارد. مثال: برنامه fetchmail عبارت \233 را همانند \xE9 (حرف لاتین کوچک e با اکسان اکیو) تفسیر می‌کند، در حالی که C عبارت \233 را به عنوان هشت‌هشتی 0233 = \x9B (CSI، معرفی‌کننده دنباله کنترل) تفسیر می‌کند.

هر ورودی سرور شامل یکی از کلیدواژه‌های 'poll' یا 'skip' است که به دنبال آن یک نام سرور، سپس گزینه‌های سرور، سپس هر تعداد توصیف کاربر (یا نام کاربری) و در نهایت گزینه‌های کاربر می‌آید. نکته: شایع‌ترین علت خطاهای نحوی، مخلوط کردن گزینه‌های کاربر و سرور یا قرار دادن گزینه‌های کاربر قبل از توصیف‌های کاربر است.

برای سازگاری با گذشته، کلمه 'server' مترادفی برای 'poll' است.

می‌توانید از کلیدواژه‌های پرکننده (noise keywords) شامل 'and'، 'with'، 'has'، 'wants' و 'options' در هر جای ورودی استفاده کنید تا آن را شبیه به زبان انگلیسی کنید. این کلمات نادیده گرفته می‌شوند، اما می‌توانند خواندن ورودی‌ها را در یک نگاه بسیار آسان‌تر کنند. علائم نگارشی ':'، ';' و ',' نیز نادیده گرفته می‌شوند.

بررسی در برابر نادیده‌گیری (Poll versus Skip)

فعل 'poll' به fetchmail می‌گوید که هنگام اجرا بدون هیچ آرگومانی، این هاست را بررسی کند. فعل 'skip' به fetchmail می‌گوید که این هاست را بررسی نکند مگر اینکه صراحتاً در خط فرمان نام برده شود. (فعل 'skip' به شما امکان می‌دهد تا ورودی‌های آزمایشی را با اطمینان آزمایش کنید، یا به راحتی ورودی‌های مربوط به هاست‌هایی را که موقتاً از دسترس خارج شده‌اند غیرفعال کنید.)

کلیدواژه‌های فاقد سوییچ‌های متناظر (Keywords Not Corresponding To Option Switches)

گزینه‌های 'folder' و 'smtphost' (برخلاف معادل‌های خط فرمان خود) می‌توانند فهرستی از نام‌ها را که با فاصله یا کاما از یکدیگر جدا شده‌اند به عنوان ورودی بپذیرند.

تمامی گزینه‌ها با آرگومان‌های واضح خط فرمان مطابقت دارند، به جز موارد زیر: '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'.

گزینه 'via' برای مواقعی است که می‌خواهید بیش از یک پیکربندی با اشاره به یک سایت داشته باشید. اگر این گزینه وجود داشته باشد، آرگومان رشته‌ای آن به عنوان نام واقعی DNS میزبان کارگزار ایمیل برای پرس‌وجو در نظر گرفته خواهد شد. این گزینه بر آرگومان poll اولویت دارد، که می‌تواند صرفاً برچسبی مجزا برای پیکربندی باشد (مثلاً آنچه در خط فرمان برای پرس‌وجوی صریح این میزبان وارد می‌کردید).

گزینه 'interval' (که یک آرگومان عددی می‌گیرد) به شما اجازه می‌دهد سرور را در فواصل زمانی کمتری نسبت به فاصله زمانی پایه poll بررسی کنید. اگر عبارت 'interval N' را قید کنید، سروری که این گزینه به آن متصل است تنها در هر N دور چرخه poll بررسی خواهد شد.

گزینه‌های تک‌مقصدی در برابر چندمقصدی (Singledrop versus Multidrop options)

لطفاً در صورتی که قصد استفاده از حالت چندمقصدی را دارید، اطمینان حاصل کنید که بخش با عنوان THE USE AND ABUSE OF MULTIDROP MAILBOXES را مطالعه کرده‌اید.

کلیدواژه‌های 'is' یا 'to' نام(های) محلی (کلاینت) زیر (یا نگاشت‌های نام سرور به نام کلاینت که با = جدا شده‌اند) را با نام کاربری کارگزار ایمیل در مدخل مرتبط می‌سازند. اگر یک فهرست is/to علامت '*' را به عنوان آخرین نام خود داشته باشد، نام‌های ناشناخته به سادگی عبور داده می‌شوند. توجه داشته باشید که تا نسخه 6.3.4 fetchmail (شامل آن)، این فهرست‌ها تنها می‌توانستند شامل بخش‌های محلی نام‌های کاربری باشند (fetchmail تنها بخش قبل از علامت @ را بررسی می‌کرد). نسخه‌های 6.3.5 و جدیدتر fetchmail از آدرس‌های کامل در سمت چپ این نگاشت‌ها پشتیبانی می‌کنند و این نگاشت‌ها بر هرگونه نگاشت 'localdomains'، 'aka'، 'via' یا موارد مشابه اولویت دارند.

یک نام محلی واحد می‌تواند برای هدایت ایمیل شما در زمانی که نام کاربری شما در دستگاه کلاینت با نام شما در کارگزار ایمیل متفاوت است، استفاده شود. هنگامی که تنها یک نام محلی وجود دارد، ایمیل بدون توجه به هدرهای Received، To، Cc و Bcc پیام، به آن نام کاربری محلی فوروارد می‌شود. در این حالت، fetchmail هرگز جستجوهای DNS را انجام نمی‌دهد.

هنگامی که بیش از یک نام محلی (یا نگاشت نام) وجود داشته باشد، fetchmail ابتدا به هدر پاکت (در صورت پیکربندی) و در غیر این صورت به هدرهای Received، To، Cc و Bcc ایمیل‌های دریافت‌شده نگاه می‌کند (این همان «حالت چندمقصدی» است). این برنامه به دنبال آدرس‌هایی می‌گردد که بخش نام میزبان آن‌ها با نام poll شما یا گزینه‌های 'via'، 'aka' یا 'localdomains' مطابقت داشته باشد، و معمولاً به دنبال بخش‌هایی از نام میزبان می‌گردد که DNS آن‌ها را به عنوان نام‌های مستعار کارگزار ایمیل معرفی می‌کند. برای جزئیات در مورد نحوه مدیریت آدرس‌های منطبق، به توضیحات 'dns'، 'checkalias'، 'localdomains' و 'aka' مراجعه کنید.

اگر fetchmail نتواند هیچ نام کاربری کارگزار ایمیل یا آدرس localdomain منطبقی پیدا کند، ایمیل پس زده (بونس) خواهد شد. به طور معمول، ایمیل به فرستنده بازگردانده می‌شود، اما اگر گزینه سراسری 'bouncemail' خاموش باشد، ایمیل به جای آن به مدیر محلی ایمیل (postmaster) تحویل داده خواهد شد. (به گزینه سراسری 'postmaster' نگاه کنید). همچنین به BUGS مراجعه کنید.

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

گزینه 'checkalias' (به طور پیش‌فرض خاموش) جستجوهای انجام‌شده توسط کلیدواژه 'dns' را در حالت چندمقصدی گسترش می‌دهد و راهکاری برای مدیریت MTAهای دوردستی فراهم می‌کند که خود را با نام متعارفشان (canonical name) معرفی می‌کنند، در حالی که با یک نام مستعار poll می‌شوند. هنگامی که چنین سروری poll می‌شود، بررسی‌ها برای استخراج آدرس پاکت با شکست مواجه شده و fetchmail به تحویل از طریق هدرهای To/Cc/Bcc بازمی‌گردد (به بخش «هدر در برابر آدرس‌های پاکت» در زیر مراجعه کنید). تعیین این گزینه به fetchmail دستور می‌دهد تا تمام آدرس‌های IP مرتبط با هر دو نام poll و نام مورداستفاده توسط MTA دوردست را دریافت کرده و آدرس‌های IP را با یکدیگر مقایسه کند. این قابلیت در شرایطی که سرور دوردست تغییرات مکرر نام متعارف را تجربه می‌کند و در غیر این صورت نیازمند تغییرات مداوم در rcfile است، بسیار مفید واقع می‌شود. در صورت تعیین 'no dns' در rcfile، گزینه 'checkalias' هیچ اثری نخواهد داشت.

گزینه 'aka' برای استفاده با صندوق‌های پستی چندمقصدی است. این گزینه به شما امکان می‌دهد فهرستی از نام‌های مستعار DNS را برای یک سرور از پیش اعلان کنید. این یک راهکار بهینه‌سازی است که به شما امکان می‌دهد فضا را با سرعت معاوضه کنید. هنگامی که fetchmail در حین پردازش یک صندوق پستی چندمقصدی، هدرهای پیام را برای یافتن نام‌های کارگزار ایمیل جستجو می‌کند، اعلان پیشاپیش نام‌های رایج می‌تواند آن را از انجام جستجوهای DNS بی‌نیاز کند. توجه: نام‌هایی که به عنوان آرگومان به 'aka' می‌دهید به عنوان پسوند مطابقت داده می‌شوند -- اگر (مثلاً) عبارت 'aka netaxs.com' را مشخص کنید، این نه تنها با نام میزبان netaxs.com، بلکه با هر نام میزبانی که به '‎.netaxs.com‎' ختم شود مطابقت خواهد داشت؛ مانند pop3.netaxs.com و mail.netaxs.com.

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

اگر از 'localdomains' استفاده می‌کنید، ممکن است لازم باشد 'no envelope' را نیز مشخص کنید که تلاش معمول fetchmail برای استنتاج آدرس پاکت از خط Received یا هدر X-Envelope-To یا هر هدری که قبلاً توسط 'envelope' تنظیم شده است را غیرفعال می‌کند. اگر 'no envelope' را در مدخل پیش‌فرض‌ها تنظیم کرده باشید، می‌توانید با استفاده از 'envelope <string>' آن را در مدخل‌های جداگانه لغو کنید. به عنوان یک حالت خاص، عبارت 'envelope "Received"' تجزیه پیش‌فرض خطوط Received را بازیابی می‌کند.

گزینه password نیازمند یک آرگومان رشته‌ای است که گذرواژه مورداستفاده برای سرور این مدخل می‌باشد.

کلیدواژه 'preconnect' به شما امکان می‌دهد یک دستور شل را مشخص کنید تا دقیقاً قبل از هر بار برقراری اتصال به کارگزار ایمیل توسط fetchmail اجرا شود. این قابلیت در صورتی که در تلاش برای راه‌اندازی اتصالات امن POP با کمک ssh(1) باشید، می‌تواند بسیار مفید باشد. اگر دستور وضعیتی غیرصفر برگرداند، بررسی (poll) آن کارگزار ایمیل لغو خواهد شد.

به طور مشابه، کلیدواژه 'postconnect' به شما امکان می‌دهد یک دستور شل را مشخص کنید تا دقیقاً پس از هر بار قطع اتصال به کارگزار ایمیل اجرا شود.

گزینه 'forcecr' کنترل می‌کند که آیا خطوطی که فقط با LF خاتمه یافته‌اند، پیش از فوروارد با CRLF خاتمه داده شوند یا خیر. از نظر فنی و دقیق RFC821 این مورد را الزامی می‌داند، اما MTAهای کمی این الزام را اعمال می‌کنند، بنابراین این گزینه معمولاً خاموش است (تنها یک MTA از این دست، یعنی qmail، در زمان نگارش این متن کاربرد چشمگیری دارد).

گزینه 'stripcr' کنترل می‌کند که آیا کاراکترهای carriage return قبل از فوروارد شدن ایمیل واکشی‌شده، از آن حذف شوند یا خیر. معمولاً نیازی به تنظیم این گزینه نیست، زیرا در صورت اعلان یک MDA به صورت پیش‌فرض 'روشن' (حذف CR فعال) و در صورت فوروارد از طریق SMTP به صورت پیش‌فرض 'خاموش' (حذف CR غیرفعال) است. اگر هر دو گزینه 'stripcr' و 'forcecr' روشن باشند، 'stripcr' اولویت خواهد داشت.

گزینه 'pass8bits' برای مقابله با برنامه‌های ایمیل مایکروسافت وجود دارد که با بی‌دقتی هدر "Content-Transfer-Encoding: 7bit" را روی همه پیام‌ها می‌چسبانند. در صورت خاموش بودن این گزینه (پیش‌فرض) و وجود چنین هدری، fetchmail مقدار BODY=7BIT را به یک شنونده دارای قابلیت ESMTP اعلان می‌کند؛ این امر باعث ایجاد مشکل برای پیام‌هایی می‌شود که واقعاً از مجموعه‌های نویسه ۸ بیتی ISO یا KOI-8 استفاده می‌کنند، و با حذف بیت‌های بالایی تمام کاراکترها مخدوش خواهند شد. اگر 'pass8bits' روشن باشد، fetchmail مجبور می‌شود مقدار BODY=8BITMIME را به هر شنونده دارای قابلیت ESMTP اعلان کند. اگر شنونده با داده‌های ۸ بیتی سازگار باشد (همان‌طور که همه شنونده‌های اصلی امروزه این‌گونه هستند)، احتمالاً نتیجه مطلوب حاصل خواهد شد.

گزینه 'dropstatus' کنترل می‌کند که آیا خطوط غیرخالی Status و X-Mozilla-Status در ایمیل‌های واکشی‌شده باقی بمانند (پیش‌فرض) یا دور ریخته شوند. نگه‌داشتن آن‌ها به MUA شما اجازه می‌دهد ببیند چه پیام‌هایی (در صورت وجود) در سرور به عنوان دیده‌شده علامت‌گذاری شده بودند. از سوی دیگر، این کار می‌تواند برخی از برنامه‌های اعلان ایمیل جدید را سردرگم کند، چرا که آن‌ها فرض می‌کنند هر چیزی که خط Status دارد قبلاً دیده شده است. (توجه: خطوط خالی Status درج‌شده توسط برخی سرورهای معیوب POP بدون قید و شرط دور ریخته می‌شوند.)

گزینه 'dropdelivered' کنترل می‌کند که آیا هدرهای Delivered-To در ایمیل‌های واکشی‌شده حفظ شوند (پیش‌فرض) یا دور ریخته شوند. این هدرها توسط کارگزارهای ایمیل qmail و Postfix به منظور جلوگیری از ایجاد حلقه‌های ایمیل اضافه می‌شوند، اما اگر بخواهید یک سرور ایمیل را در همان دامنه "آینه‌سازی" کنید، ممکن است مانع کار شما شوند. با احتیاط استفاده کنید.

گزینه 'mimedecode' کنترل می‌کند که آیا پیام‌های MIME که از کدگذاری quoted-printable استفاده می‌کنند به صورت خودکار به داده‌های خالص ۸ بیتی تبدیل شوند یا خیر. اگر در حال تحویل ایمیل به یک شنونده سازگار با داده‌های ۸ بیتی و دارای قابلیت ESMTP هستید (که شامل تمام MTAهای اصلی مانند sendmail می‌شود)، این گزینه هدرها و داده‌های پیام quoted-printable را به طور خودکار به داده‌های ۸ بیتی تبدیل کرده و خواندن ایمیل را آسان‌تر می‌سازد. اگر برنامه‌های ایمیل شما نحوه کار با پیام‌های MIME را می‌دانند، به این گزینه نیازی نیست. گزینه mimedecode به طور پیش‌فرض خاموش است، زیرا انجام تبدیل RFC2047 روی هدرها اطلاعات مجموعه نویسه‌ها را دور می‌ریزد و اگر کدگذاری هدرها با کدگذاری بدنه متفاوت باشد، می‌تواند منجر به نتایج نامطلوب شود.

گزینه 'idle' برای استفاده با سرورهای IMAP در نظر گرفته شده است که از افزونه دستور IDLE طبق RFC2177 پشتیبانی می‌کنند، اما به طور اکید به آن نیازمند نیست. در صورت فعال بودن، و در صورتی که fetchmail تشخیص دهد IDLE پشتیبانی می‌شود، در پایان هر poll دستور IDLE صادر خواهد شد. این به سرور IMAP می‌گوید که اتصال را باز نگه دارد و هنگام در دسترس بودن ایمیل جدید به کلاینت اطلاع دهد. اگر IDLE پشتیبانی نشود، fetchmail با ارسال دوره‌ای دستور NOOP آن را شبیه‌سازی خواهد کرد. اگر نیاز به بررسی مکرر یک پیوند دارید، IDLE می‌تواند با حذف اتصالات TCP/IP و توالی‌های LOGIN/LOGOUT در پهنای باند صرفه‌جویی کند. از سوی دیگر، یک اتصال IDLE تقریباً تمام زمان fetchmail شما را مصرف خواهد کرد، زیرا هرگز اتصال را قطع نمی‌کند و اجازه نمی‌دهد pollهای دیگر رخ دهند مگر اینکه سرور مهلت IDLE را به پایان برساند. همچنین این گزینه با چندین پوشه کار نمی‌کند؛ تنها اولین پوشه مورد بررسی قرار خواهد گرفت.

گزینه 'properties' یک مکانیزم توسعه است. این گزینه یک آرگومان رشته‌ای می‌گیرد که توسط خود fetchmail نادیده گرفته می‌شود. آرگومان رشته‌ای می‌تواند برای ذخیره اطلاعات پیکربندی برای اسکریپت‌هایی که به آن نیاز دارند استفاده شود. به طور ویژه، خروجی گزینه '--configdump' ویژگی‌های مرتبط با یک مدخل کاربر را به راحتی در دسترس یک اسکریپت پایتون قرار می‌دهد.

سایر گزینه‌های کنترل اجرا (Miscellaneous Run Control Options)

کلمات 'here' و 'there' معنای شبیه به زبان انگلیسی و مفیدی دارند. به طور معمول عبارت 'user eric is esr' به این معنی است که ایمیل برای کاربر دوردست 'eric' باید به 'esr' تحویل داده شود، اما می‌توانید با گفتن 'user eric there is esr here' این موضوع را روشن‌تر کنید، یا با گفتن 'user esr here is eric there' آن را معکوس نمایید.

شناسه‌های معتبر پروتکل برای استفاده با کلیدواژه 'protocol' عبارتند از:

auto (یا AUTO) (منسوخ، در نسخه‌های آینده حذف می‌شود)
pop2 (یا POP2) (منسوخ، در نسخه‌های آینده حذف می‌شود)
pop3 (یا POP3)
sdps (یا SDPS)
imap (یا IMAP)
apop (یا APOP)
kpop (یا KPOP)

انواع معتبر احراز هویت عبارتند از 'any'، 'password'، 'kerberos'، 'kerberos_v4'، 'kerberos_v5' و 'gssapi'، 'cram-md5'، 'otp'، 'msn' (تنها برای POP3)، 'ntlm'، 'implicit'، 'external' (تنها برای IMAP). نوع 'password' احراز هویت را از طریق ارسال معمول یک گذرواژه مشخص می‌کند (گذرواژه می‌تواند متن ساده یا مشمول رمزنگاری ویژه پروتکل مانند CRAM-MD5 باشد)؛ 'kerberos' به fetchmail می‌گوید که به جای آن در شروع هر پرس‌وجو سعی کند یک بلیت Kerberos دریافت کرده و یک رشته دلخواه را به عنوان گذرواژه ارسال کند؛ و 'gssapi' به fetchmail می‌گوید که از احراز هویت GSSAPI استفاده کند. برای اطلاعات بیشتر به توضیحات کلیدواژه 'auth' مراجعه کنید.

تعیین 'kpop' پروتکل POP3 را روی پورت 1109 با احراز هویت Kerberos V4 تنظیم می‌کند. این پیش‌فرض‌ها ممکن است توسط گزینه‌های بعدی لغو شوند.

چندین عبارت گزینه سراسری وجود دارد: عبارت 'set logfile' همراه با یک رشته، همان متغیر سراسری مشخص‌شده توسط ‎--logfile‎ را تنظیم می‌کند. گزینه خط فرمان ‎--logfile‎ بر این مقدار اولویت خواهد داشت. توجه داشته باشید که ‎--logfile‎ تنها در صورتی مؤثر است که fetchmail خود را از ترمینال جدا کند و فایل لاگ قبل از اجرای fetchmail از پیش موجود باشد، و در این حالت بر ‎--syslog‎ اولویت دارد. همچنین، عبارت 'set daemon' فاصله زمانی poll را مانند ‎--daemon‎ تنظیم می‌کند. این مقدار می‌تواند توسط گزینه خط فرمان ‎--daemon‎ لغو شود؛ به ویژه ‎--daemon 0‎ می‌تواند برای اجبار به اجرای پیش‌زمینه استفاده شود. عبارت 'set postmaster' آدرسی را تعیین می‌کند که در صورت عدم وجود تطابق محلی، ایمیل‌های چندمقصدی به طور پیش‌فرض به آن ارسال می‌شوند. در نهایت، 'set syslog' پیام‌های لاگ را به syslogd(8) می‌فرستد.

کرش کردن و توقف ناگهانی Fetchmail (Fetchmail crashing)

روش‌های گوناگونی وجود دارد که در آن‌ها fetchmail ممکن است "کرش کند"، یعنی عملکرد آن به طور ناگهانی و غیرمنتظره متوقف شود. یک "کرش" معمولاً به وضعیت خطایی اشاره دارد که نرم‌افزار خود قادر به مدیریت آن نبوده است. یک حالت شکست شناخته‌شده "خطای قطعه‌بندی حافظه" (segmentation fault) یا "سیگنال ۱۱" یا "SIGSEGV" یا به اختصار "segfault" است. این موارد می‌توانند ناشی از مشکلات سخت‌افزاری یا نرم‌افزاری باشند. خطاهای segfault ناشی از نرم‌افزار معمولاً به راحتی و در همان نقطه قابل بازتولید هستند، در حالی که خطاهای segfault ناشی از سخت‌افزار ممکن است با راه‌اندازی مجدد رایانه یا خاموش کردن آن برای چند ساعت برطرف شوند و حتی اگر از نرم‌افزار به همان شکل استفاده کنید، می‌توانند در مکان‌های تصادفی رخ دهند.

برای رفع segfaultهای ناشی از سخت‌افزار، قطعه معیوب را پیدا کرده و آن را تعمیر یا تعویض کنید. پرسش‌های متداول Sig11 ممکن است در جزئیات به شما کمک کند.

برای رفع segfaultهای ناشی از نرم‌افزار، توسعه‌دهندگان ممکن است به یک "ردگیری پشته" (stack backtrace) نیاز داشته باشند.

فعال‌سازی دامپ هسته fetchmail (Enabling fetchmail core dumps)

به طور پیش‌فرض، fetchmail از ایجاد دامپ‌های هسته (core dumps) جلوگیری می‌کند زیرا این فایل‌ها ممکن است حاوی گذرواژه‌ها و سایر اطلاعات حساس باشند. برای اشکال‌زدایی کرش‌های fetchmail، به دست آوردن "ردگیری پشته" از یک دامپ هسته اغلب سریع‌ترین راه برای حل مشکل است، و هنگام ارسال مشکل خود در یک لیست پستی، توسعه‌دهندگان ممکن است از شما یک "backtrace" بخواهند.

۱. برای دریافت backtraceهای مفید، fetchmail باید بدون حذف نمادهای کامپایل (strip) نصب شده باشد. متأسفانه، بیشتر بسته‌های باینری که نصب می‌شوند stripped هستند و فایل‌های هسته حاصل از برنامه‌های بدون نماد بی‌ارزش هستند. بنابراین ممکن است لازم باشد fetchmail را دوباره کامپایل کنید. در بسیاری از سیستم‌ها، می‌توانید دستور زیر را تایپ کنید:

file `which fetchmail`

تا متوجه شوید که آیا نمادهای fetchmail حذف شده‌اند یا خیر. اگر برنامه شما فاقد حذف نماد (unstripped) بود، مشکلی نیست و ادامه دهید؛ اگر stripped بود، ابتدا باید کد منبع را دوباره کامپایل کنید. معمولاً برای اشکال‌زدایی fetchmail نیازی به نصب آن ندارید.

۲. محیط شل که fetchmail را اجرا می‌کند باید تولید دامپ‌های هسته را فعال کند. نکته کلیدی "حداکثر اندازه فایل هسته" است که معمولاً با ابزاری به نام "limit" یا "ulimit" قابل پیکربندی است. برای جزئیات به مستندات شل خود مراجعه کنید. در شل محبوب bash، دستور "ulimit -Sc unlimited"; اجازه ایجاد دامپ هسته را می‌دهد.

۳. شما باید به fetchmail نیز بگویید که اجازه ایجاد دامپ‌های هسته را بدهد. برای انجام این کار، fetchmail را با گزینه‌های -d0 -v اجرا کنید. اغلب آسان‌تر است که --nosyslog -N را نیز اضافه کنید.

در نهایت، باید کرش را بازتولید کنید. می‌توانید به سادگی fetchmail را از دایرکتوری محل کامپایل با تایپ ./fetchmail اجرا کنید، بنابراین خط فرمان کامل با ./fetchmail -Nvd0 --nosyslog آغاز شده و احتمالاً سایر گزینه‌های شما را فهرست می‌کند.

پس از کرش، اشکال‌زدای خود را برای دریافت دامپ هسته اجرا کنید. اشکال‌زدا اغلب GNU GDB خواهد بود؛ سپس می‌توانید (با تنظیم مسیرها در صورت نیاز) دستور gdb ./fetchmail fetchmail.core را وارد کرده و پس از بالا آمدن GDB و خواندن تمام فایل‌هایش، عبارت backtrace full را تایپ کنید، خروجی را ذخیره نمایید (کپی و پیست کافی است، backtrace توسط یک انسان خوانده خواهد شد) و سپس quit را برای خروج از gdb تایپ کنید. توجه: در برخی سیستم‌ها، فایل‌های هسته نام‌های متفاوتی دارند؛ ممکن است به جای نام برنامه حاوی یک عدد، یا شماره و نام باشند، اما معمولاً کلمه "core" را به عنوان بخشی از نام خود خواهند داشت.

نشانی‌های هدر در برابر نشانی‌های پاکت (Header versus Envelope addresses)

مشکل بنیادین این است که با انداختن نامه‌های چندین نفر توسط سرور ایمیل درون یک صندوق پستی واحد، ممکن است اطلاعات بالقوه حیاتی درباره اینکه هر نامه واقعاً به چه کسی ارسال شده بود را دور ریخته باشید (یعنی «نشانی پاکت» یا envelope address، در مقابل نشانی‌های هدر در خطوط RFC822 To/Cc — زیرا اطلاعات Bcc در سمت گیرنده در دسترس نیست). این «نشانی پاکت» همان نشانی‌ای است که برای بازهدایت صحیح ایمیل به آن نیاز دارید.

گاهی اوقات fetchmail می‌تواند نشانی پاکت را استنتاج کند. اگر MTA سرور ایمیل sendmail باشد و پیام فقط یک گیرنده داشته باشد، MTA یک عبارت 'by/for' را در هدر Received ثبت کرده است که گیرنده پاکت را مشخص می‌کند. اما این روش برای سایر MTAها یا در صورتی که بیش از یک گیرنده وجود داشته باشد به طور مطمئن کار نمی‌کند. به طور پیش‌فرض، fetchmail در این خطوط به دنبال نشانی‌های پاکت می‌گردد؛ می‌توانید این پیش‌فرض را با -E "Received" یا بازیابی کنید.

به عنوان یک جایگزین بهتر، برخی از شنوندگان SMTP و/یا سرورهای ایمیل هدری را در هر پیام درج می‌کنند که حاوی نسخه‌ای از نشانی‌های پاکت است. این هدر (در صورت وجود) اغلب یا 'X-Envelope-To' است. پیش‌فرض fetchmail در این مورد را می‌توان با گزینه -E یا تغییر داد. توجه داشته باشید که نوشتن چنین هدر پاکتی نام گیرندگان (شامل گیرندگان رونوشت پنهان) را برای تمام دریافت‌کنندگان پیام فاش می‌کند، بنابراین سرور بالادست باید به ازای هر گیرنده یک نسخه از پیام ذخیره کند تا مشکل حریم خصوصی ایجاد نشود.

برنامه Postfix، از نسخه ۲.۰ به بعد، یک هدر X-Original-To: می‌نویسد که حاوی نسخه‌ای از پاکت به همان شکلی است که دریافت شده بود.

برنامه‌های Qmail و Postfix عموماً هنگام تحویل پیام به صف محلی، هدر 'Delivered-To' را می‌نویسند و از آن برای جلوگیری از حلقه‌های ایمیلی استفاده می‌کنند. با این حال، دامنه‌های مجازی Qmail نام کاربری را با رشته‌ای که معمولاً با دامنه کاربر مطابقت دارد پیشوند می‌زنند. برای حذف این پیشوند می‌توانید از گزینه -Q یا استفاده کنید.

متأسفانه گاهی هیچ‌یک از این روش‌ها کارساز نیست. این نقطه‌ای است که باید با ارائه‌دهنده اینترنت (ISP) خود تماس بگیرید و از آن‌ها بخواهید چنین هدر پاکتی را ارائه دهند، و در این وضعیت نباید از صندوق چندمقصدی استفاده کنید. وقتی همه این‌ها شکست بخورند، fetchmail باید به محتویات هدرهای To/Cc متوسل شود (هدرهای Bcc در دسترس نیستند - پایین را ببینید) تا گیرندگان را تشخیص دهد -- و این روش نامطمئن است. به ویژه، نرم‌افزارهای فهرست پستی اغلب نامه‌ها را تنها با نشانی پخش همگانی لیست در هدر To: ارسال می‌کنند.

توجه داشته باشید که نسخه آینده fetchmail ممکن است پردازش هدرهای To/Cc را حذف کند!

وقتی fetchmail نتواند یک نشانی گیرنده محلی را استنتاج کند، و نشانی گیرنده مورد نظر فردی غیر از کاربر اجراکننده fetchmail باشد، نامه گم خواهد شد. این همان چیزی است که استفاده از ویژگی چندمقصدی را بدون اطلاعات پاکت مناسب پرریسک می‌کند.

مشکل مرتبط دیگر این است که وقتی پیامی را به صورت رونوشت پنهان (Bcc) ارسال می‌کنید، اطلاعات Bcc تنها به عنوان نشانی پاکت منتقل می‌شود (توسط سرور ایمیل فرستنده از هدرها حذف می‌شود، بنابراین fetchmail تنها در صورتی می‌تواند آن را ببیند که هدر X-Envelope-To وجود داشته باشد). بنابراین، ارسال رونوشت پنهان به شخصی که نامه‌هایش را از طریق پیوند چندمقصدی fetchmail دریافت می‌کند ناموفق خواهد بود مگر اینکه سرور ایمیل به طور مرتب هدر X-Envelope-To یا معادل آن را درون پیام‌های صندوق پستی شما بنویسد.

در نتیجه، فهرست‌های پستی و نامه‌های دارای Bcc تنها در صورتی به درستی کار می‌کنند که سروری که از آن دریافت می‌کنید:

(1)

به ازای هر گیرنده در دامنه شما، یک نسخه از پیام را ذخیره کند و

(2)

اطلاعات پاکت را در یک هدر ویژه (X-Original-To، Delivered-To، X-Envelope-To) ثبت نماید.

روش‌های مناسب استفاده از صندوق‌های پستی چندمقصدی (Good Ways To Use Multidrop Mailboxes)

از چندین نام محلی می‌توان برای مدیریت یک لیست پستی از سمت کلاینت در یک جمع‌آوری fetchmail استفاده کرد. فرض کنید نام کاربری شما 'esr' است و می‌خواهید هم نامه‌های خود را تحویل بگیرید و هم یک لیست پستی به نام (مثلاً) "fetchmail-friends" را نگهداری کنید، و می‌خواهید لیست نام‌های مستعار (alias) را روی سیستم کلاینت خود نگه دارید.

روی سرور خود می‌توانید نام مستعار 'fetchmail-friends' را به 'esr' ارجاع دهید؛ سپس در فایل .fetchmailrc خود عبارت 'to esr fetchmail-friends here' را اعلام کنید. سپس، وقتی نامه‌ای شامل 'fetchmail-friends' به عنوان یک نشانی محلی واکشی می‌شود، نام لیست به انتهای لیست گیرندگانی که شنونده SMTP شما می‌بیند افزوده خواهد شد. بنابراین فرایند بسط نام مستعار به صورت محلی انجام می‌شود. حتماً نام 'esr' را در بسط محلی نام‌های مستعار fetchmail-friends بگنجانید، در غیر این صورت نامه‌هایی را که فقط به لیست ارسال شده‌اند هرگز نخواهید دید. همچنین مطمئن شوید که شنونده شما گزینه "me-too" را فعال کرده باشد (گزینه خط فرمان -oXm در sendmail یا اعلان OXm) تا نام شما از بسط نام‌های مستعار در پیام‌هایی که ارسال می‌کنید حذف نشود.

با این حال، این ترفند بدون مشکل نیست. وقتی پیامی وارد شود که فقط به یک لیست پستی ارسال شده باشد و شما آن را به عنوان یک نام محلی تعریف نکرده باشید، متوجه مشکل خواهید شد. هر یک از این پیام‌ها دارای یک هدر 'X-Fetchmail-Warning' خواهند بود که به این دلیل ایجاد می‌شود که fetchmail نمی‌تواند یک نام محلی معتبر در نشانی‌های گیرنده پیدا کند. چنین پیام‌هایی به طور پیش‌فرض (همان‌طور که در بالا توضیح داده شد) برای کاربر محلی اجراکننده fetchmail ارسال می‌شوند، اما برنامه راهی ندارد که بداند آیا این کار واقعاً درست است یا خیر.

روش‌های نامناسب و سوءاستفاده از صندوق‌های پستی چندمقصدی (Bad Ways To Abuse Multidrop Mailboxes)

صندوق‌های پستی چندمقصدی و اجرای fetchmail برای سرویس‌دهی به چندین کاربر در حالت دیمن (daemon) با یکدیگر سازگار نیستند. مشکل بار دیگر نامه‌های دریافتی از لیست‌های پستی است که معمولاً نشانی گیرنده فردی روی آن‌ها درج نشده است. مگر اینکه fetchmail بتواند نشانی پاکت را استنتاج کند، چنین نامه‌هایی فقط به حسابی که fetchmail را اجرا می‌کند (احتمالاً root) تحویل داده می‌شوند. همچنین کاربرانی که رونوشت پنهان (Bcc) دریافت کرده‌اند به احتمال زیاد اصلاً نامه‌های خود را نخواهند دید.

اگر وسوسه شده‌اید که از fetchmail برای دریافت ایمیل چندین کاربر از یک صندوق پستی واحد از طریق POP یا IMAP استفاده کنید، دوباره فکر کنید (و بخش مربوط به نشانی‌های هدر و پاکت را در بالا مجدداً مطالعه کنید). هوشمندانه‌تر این است که اجازه دهید ایمیل‌ها در صف سرور ایمیل باقی بمانند و از حالت‌های ETRN یا ODMR در fetchmail برای راه‌اندازی دوره‌ای ارسال SMTP استفاده کنید (البته این بدان معناست که باید با فاصله‌های زمانی کوتاه‌تر از مدت زمان انقضای سرور، عمل بررسی را انجام دهید). اگر نمی‌توانید این سازوکار را ترتیب دهید، راه‌اندازی فید UUCP را امتحان کنید.

اگر کاملاً مجبورید از صندوق چندمقصدی برای این منظور استفاده کنید، مطمئن شوید که سرور ایمیل شما هدر نشانی پاکت را می‌نویسد به طوری که fetchmail بتواند آن را ببیند. در غیر این صورت، قطعاً نامه‌ها را از دست خواهید داد و این مسئله برایتان دردسرساز خواهد شد.

افزایش سرعت بررسی صندوق‌های چندمقصدی (Speeding Up Multidrop Checking)

به طور معمول، هنگامی که چندین کاربر تعریف می‌شوند، fetchmail نشانی‌های گیرنده را همان‌طور که در بالا شرح داده شد استخراج می‌کند و بخش میزبان (host part) هر کدام را از طریق DNS بررسی می‌کند تا ببیند آیا نام مستعاری از سرور ایمیل است یا خیر. در صورت تطابق، نگاشت نام‌ها طبق اعلان "to ... here" انجام شده و نامه به صورت محلی تحویل داده می‌شود.

این روش راحت اما کند است. برای افزایش سرعت، نام‌های مستعار سرور ایمیل را از قبل با 'aka' اعلان کنید؛ این نام‌ها قبل از انجام جستجوهای DNS بررسی می‌شوند. اگر مطمئن هستید که فهرست aka شما شامل تمام نام‌های مستعار DNS سرور ایمیل (و تمام رکوردهای MX که به آن اشاره دارند - توجه داشته باشید که این ممکن است در نسخه آینده تغییر کند) است، می‌توانید 'no dns' را اعلام کنید تا جستجوهای DNS کاملاً غیرفعال شوند و تنها با فهرست aka مطابقت داده شود.

حذف ایمیل‌های تکراری در حالت چندمقصدی (Duplicate suppression on multidrop)

اگر کد حذف تکراری‌های fetchmail برای حساب چندمقصدی شما فعال نمی‌شود، گزینه‌های دیگر استفاده از sieve یا به عنوان مثال بسته maildrop از Courier (و به ویژه برنامه reformail آن با گزینه -D) به عنوان عامل تحویل (MDA) است (چه از طریق fetchmail و چه از طریق سرور ایمیل محلی شما که fetchmail نامه‌ها را به آن تزریق می‌کند).