INN.CONF(5) InterNetNews Documentation INN.CONF(5)

inn.conf - پیکربندی InterNetNews

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

این فایل قرار است تا حد زیادی ایستا باشد. هرگونه تغییری در آن معمولاً بر برنامه‌های در حال اجرا تأثیری نخواهد گذاشت تا زمانی که مجدداً راه‌اندازی شوند. برخلاف تقریباً هر فایل پیکربندی دیگر، inn.conf را نمی‌توان با استفاده از ctlinnd(8) به‌صورت پویا بازخوانی کرد؛ innd(8) باید متوقف شده و مجدداً راه‌اندازی شود تا تغییرات مربوطه در inn.conf اعمال شوند ("ctlinnd xexec innd" سریع‌ترین راه برای انجام این کار است.)

خطوط خالی و خطوطی که با علامت هش ("#") آغاز می‌شوند نادیده گرفته خواهند شد. تمام خطوط دیگر پارامترها را مشخص می‌کنند و باید به قالب زیر باشند:

<name>: <value>

(هر میزان فاصله خالی می‌تواند پس از دونقطه قرار گیرد و اختیاری است.) اگر مقدار حاوی فاصله‌های خالی درون‌متنی یا هر یک از نویسه‌های "[]<>{}"\:;" باشد، باید درون نقل‌قول دوتایی ("") محصور شود. از یک بک‌اسلش ("\") می‌توان برای گریز نقل‌قول‌ها و بک‌اسلش‌ها در داخل نقل‌قول دوتایی استفاده کرد. <name> به حروف کوچک و بزرگ حساس است؛ "server" با "Server" یا "SERVER" یکسان نیست. (پارامترهای inn.conf معمولاً همگی با حروف کوچک هستند.)

اگر <name> بیش از یک بار در فایل ظاهر شود، از اولین مقدار استفاده می‌شود. برخی از پارامترهای مشخص‌شده در فایل ممکن است توسط متغیرهای محیطی لغو شوند. اکثر پارامترها در صورت مشخص نشدن در inn.conf دارای مقادیر پیش‌فرض هستند؛ این مقادیر پیش‌فرض در توضیحات هر پارامتر ذکر شده‌اند.

بسیاری از پارامترها یک مقدار بولی می‌پذیرند. برای تمام این پارامترها، مقدار ممکن است به‌صورت "true"، "yes" یا "on" برای روشن کردن آن و به‌صورت هر یک از "false"، "no" یا "off" برای خاموش کردن آن مشخص شود. بزرگی و کوچکی حروف این مقادیر مهم است.

این مستندات بسیار طولانی بوده و به عنوان یک کتابچه مرجع سازماندهی شده‌اند نه یک آموزش. اگر این اولین برخورد شما با INN و این پارامترها است، بهتر است با خواندن صفحات راهنمای دیگر شروع کرده و تنها زمانی به این صفحه مراجعه کنید که یک پارامتر inn.conf به‌صراحت ذکر شده باشد. پارامترهایی که هنگام راه‌اندازی سرور جدید نیاز به تغییر دارند، در INSTALL مورد بحث قرار گرفته‌اند.

این پارامترها توسط طیف گسترده‌ای از اجزای مختلف INN استفاده می‌شوند.

این باید نام دامنه میزبان محلی باشد. نباید نقطه در ابتدا داشته باشد و نباید یک آدرس کامل میزبان باشد. تنها در صورتی استفاده می‌شود که یک نام دامنه کاملاً واجد شرایط (FQDN) یافت نشود. INN ابتدا تلاش می‌کند آن را از متغیر محیطی INN_HOSTNAME در صورت تنظیم بودن، سپس از فراخوانی‌های gethostname(3) و getaddrinfo(3) دریافت کند. این بررسی بسیار ساده است؛ اگر نام میزبان بازیابی‌شده حاوی نقطه باشد، فرض می‌شود که نام کامل دامنه را دارد. در غیر این صورت، یک نقطه همراه با مقدار domain به انتهای نام میزبان بازیابی‌شده اضافه می‌شود. مقدار پیش‌فرض تنظیم‌نشده است.

توصیه می‌شود نام دامنه کاملاً واجد شرایط خود را در /etc/hostname یا در متغیر محیطی INN_HOSTNAME در صورت عدم امکان تعریف کنید.

هدف به دست آوردن یک نام میزبان تضمین‌شده و یکتا است، بنابراین باید از مقداری مانند "localhost.localdomain" برای نام میزبان یا "localdomain" برای پارامتر domain اجتناب شود. در حالت ایده‌آل، باید از دامنه‌ای وابسته به مدیران سرور خبری استفاده شود.

این پارامتر قرار نیست برای تأثیرگذاری بر سمت راست Message-IDهای تولیدشده خودکار استفاده شود؛ به دلایل سازگاری با گذشته باید مستقیماً از domain در readers.conf(5) استفاده کنید. (نام این پارامتر در readers.conf احتمالاً در یک نسخه اصلی آینده برای رفع ابهام در کاربرد آن تغییر خواهد کرد.)

فلگ‌هایی که باید در زمان راه‌اندازی به innd داده شوند. برای جزئیات مربوط به فلگ‌های ممکن، innd(8) را ببینید. مقدار پیش‌فرض تنظیم‌نشده است.

توجه داشته باشید که این فلگ‌ها فقط زمانی استفاده می‌شوند که innd از طریق rc.news یا nntpsend آغاز شده باشد.

مسیر برنامه‌ای که برای ارسال گزارش‌ها و خطاها با ایمیل به مدیر خبر استفاده می‌شود. پیش‌فرض pathbin/innmail است. این معمولاً نباید نیازی به تغییر داشته باشد.
دستوری که هنگام ارسال ایمیل باید استفاده شود (مانند ارسال نوشته‌ها به ناظران، پل ارتباطی خبر به ایمیل، ارسال آمار به پروژه TOP1000، ارسال ایمیلی خطاها و گزارش‌ها به مدیر خبر). برخی برنامه‌ها از innmail(1) استفاده می‌کنند که به نوبه خود دستوری را که در پارامتر mta است اجرا می‌کند. پیام به همراه سرایندهای آن، به این برنامه mta پایپ خواهد شد. بسته به برنامه فراخواننده، در صورت لزوم فیلدهای سرایند اضافی مانند فیلدهای To، Subject یا Auto-Submitted ممکن است افزوده شوند.

رشته "%s"، در صورت وجود، با گیرنده(های) مورد انتظار مانند آدرس ایمیل ناظر یا یک فهرست راه دور جایگزین می‌شود. اکیداً توصیه می‌شود که این دستور با "%s" در خط فرمان پایان یابد، نه اینکه در صورت عدم وجود، از آدرس‌های موجود در فیلدهای سرایند To و Cc پیام استفاده کند، چرا که رویکرد دوم به سرور خبری اجازه می‌دهد تا به عنوان سازوکاری برای ارسال ایمیل به آدرس‌های دلخواه مورد سوءاستفاده قرار گیرد و منجر به رفتارهای غیرمنتظره خواهد شد. هیچ مقدار پیش‌فرضی برای این پارامتر وجود ندارد؛ باید در inn.conf تنظیم شود وگرنه یک پیام خطای مهلک از طریق syslog ثبت خواهد شد.

برای بیشتر سیستم‌ها، "/usr/lib/sendmail -oi -oem %s" (تنظیم‌شده برای مسیر صحیح sendmail، و درون نقل‌قول دوتایی) یک انتخاب مناسب است.

برای بهبود تحویل‌پذیری ایمیل‌های ارسالی، به‌ویژه ارسال‌های گروه‌های نیازمند تأیید (moderated)، تشویق می‌شوید که یک MTA مدرن و کامل مانند Postfix را به‌جای یک MTA ساده مانند Nullmailer نصب کنید. سپس می‌توانید بازگشت‌ها (bounces) را پیکربندی کرده و از DSN (اعلان‌های وضعیت تحویل) بهره‌مند شوید. فلگ‌های مفیدی که در صورت پشتیبانی برنامه mta شما می‌توان افزود عبارتند از: "-N failure"; (تنها بازگرداندن DSN در هنگام شکست، نه تأخیر)، "-F 'Newsmaster'" (برای تنظیم نام کامل اعلان)، "-fnewsmaster@server.com" (برای تنظیم آدرس فرستنده پاکت)، و "-opnobodyreturn" (یک گزینه حریم خصوصی برای بازگرداندن تنها سرایندها در DSN). در افزودن هر گزینه دیگری که مناسب می‌دانید آزاد هستید.

آنچه باید در فیلد سرایند Path قرار گیرد تا سایت محلی را نشان دهد. این هویت مسیر به بدنه فیلد سرایند Path تمامی مقالاتی که از سیستم عبور می‌کنند، از جمله مقالات ارسال‌شده محلی، افزوده می‌شود و همچنین هنگام پردازش برخی پیام‌های کنترلی و هنگام نام‌گذاری سرور در گزارش‌های وضعیت استفاده می‌شود. هیچ مقدار پیش‌فرضی وجود ندارد؛ این پارامتر باید در inn.conf تنظیم شود وگرنه INN راه‌اندازی نخواهد شد. یک مقدار مناسب، نام کامل میزبان (FQDN) سیستم است.

هدف اصلی هویت مسیر این است که همتایان شما مقالاتی را که از قبل حاوی هویت مسیر شما در فیلدهای سرایند Path خود هستند، به شما پیشنهاد ندهند.

در صورتی که چندین سرور خبری داخلی را اجرا می‌کنید، ممکن است بخواهید pathcluster را نیز تنظیم کنید تا هویت مسیر اصلی برای تبلیغ به همتایان شما تعریف شود تا آن‌ها بتوانند سرورهای خبری شما را به درستی شناسایی کرده و تشخیص مسیر مناسب را اضافه کنند (برای جزئیات بیشتر درباره تشخیص‌های مسیر، بخش 3.2.1 از RFC 5537 را ببینید).

گروهی که سرور خبری تحت آن اجرا خواهد شد. پیش‌فرض "news" است (یا گروهی که در زمان پیکربندی مشخص شده است) و معمولاً نباید نیازی به تغییر داشته باشد.
کاربری که سرور خبری تحت آن اجرا خواهد شد. پیش‌فرض "news" است (یا کاربری که در زمان پیکربندی مشخص شده است) و معمولاً نباید نیازی به تغییر داشته باشد.
نام سرور پیش‌فرض NNTP. اگر nnrpdposthost تنظیم نشده باشد و سوکت‌های دامنه یونیکس پشتیبانی نشوند، nnrpd تلاش می‌کند مقالات ارسال‌شده محلی را از طریق یک سوکت دامنه INET به این سرور تحویل دهد.

برنامه‌های actsync، getlist، inews و nntpget نیز از این مقدار به عنوان سرور پیش‌فرض برای اتصال استفاده می‌کنند. در موارد اخیر، مقدار متغیر محیطی NNTPSERVER در صورت وجود، این را لغو می‌کند. مقدار پیش‌فرض تنظیم‌نشده است. ممکن است بخواهید آن را روی "localhost" یا نام کامل دامنه سرور خبری محلی خود یا یک سرور خبری راه دور تنظیم کنید.

برنامه rnews از این مقدار به عنوان یک پشتیبان در زمانی که nnrpdposthost تنظیم نشده و سرور localhost وجود ندارد استفاده می‌کند.

فهرستی از مقادیر که سطح بررسی‌های انجام‌شده توسط innd و nnrpd را کنترل می‌کنند. برای نمونه: 
syntaxchecks: [ no-laxmid ]

آخرین رخداد یک مقدار معین اولویت دارد، به این معنی که اگر "no-laxmid laxmid" ذکر شود، laxmid اولویت خواهد داشت.

در حال حاضر تنها یک بررسی می‌تواند فعال/غیرفعال شود:

هنگامی که laxmid تنظیم شده باشد، Message-IDهایی که در بخش سمت چپ حاوی ".." هستند پذیرفته می‌شوند، و همچنین Message-IDهایی با دو علامت "@" یا بدون هیچ علامت "@". برخی از ارسال‌کنندگان خبر غیرمنطبق چنین Message-IDهای نامعتبر از نظر نحو را تولید می‌کنند، به‌ویژه در گروه‌های خبری باینری. حتی با تنظیم laxmid، برنامه nnrpd همچنان اطمینان حاصل می‌کند که Message-IDها حاوی یک "@" باشند.

پیش‌فرض no-laxmid است، به این معنی که INN دقیقاً از استاندارد در مورد بررسی‌های نحوی پیروی می‌کند (نه این مقالات را می‌پذیرد و نه آن‌ها را به همتایان راه دور منتشر می‌کند). توجه داشته باشید که در صورت تنظیم laxmid، همتایان راه دور ممکن است مقالات با Message-ID نامعتبر از نظر نحو را رد کنند.

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

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

به منظور غیرفعال کردن این بررسی روی تاریخ، می‌توانید این پارامتر را روی "0" تنظیم کنید.

عدد روی خط "/remember/" در expire.ctl احتمالاً باید یکی بیشتر از این عدد باشد تا مقالاتی را که تاریخ ارسال آن‌ها یک روز در آینده است در نظر بگیرد.

کدام آدرس IP باید توسط innd(8) به خود متصل (bind) شود. این باید در قالب چهاربخشی نقطه‌دار (nnn.nnn.nnn.nnn) باشد. اگر روی "all" تنظیم شود یا تنظیم نشده باشد، innd به‌طور پیش‌فرض روی تمام رابط‌ها گوش می‌دهد. مقدار متغیر محیطی INND_BIND_ADDRESS در صورت تنظیم، این تنظیم را لغو می‌کند. مقدار پیش‌فرض تنظیم‌نشده است.

این پارامتر هنگامی که فعال‌سازی سوکت systemd استفاده می‌شود هیچ تأثیری ندارد.

مانند bindaddress اما برای سوکت‌های IPv6. اگر تنها یکی از پارامترهای bindaddress و bindaddress6 استفاده شود، آن‌گاه تنها سوکت مربوط به خانواده آدرس متناظر ایجاد می‌شود. اگر هر دو پارامتر استفاده شوند، دو سوکت ایجاد می‌گردد. اگر هیچ‌یک از آن‌ها استفاده نشود، فهرست سوکت‌ها برای گوش دادن توسط تابع getaddrinfo(3) کتابخانه سیستم تعیین خواهد شد. مقدار متغیر محیطی INND_BIND_ADDRESS6 در صورت تنظیم، این تنظیم را لغو می‌کند. مقدار پیش‌فرض تنظیم‌نشده است.

توجه داشته باشید که در صورت تنظیم این مقدار، معمولاً باید اطراف آن نقل‌قول دوتایی ("") قرار دهید، زیرا آدرس‌های IPv6 حاوی دونقطه هستند.

این پارامتر هنگامی که فعال‌سازی سوکت systemd استفاده می‌شود هیچ تأثیری ندارد.

این پارامتر برای سایت‌هایی در نظر گرفته شده است که نگران سوءاستفاده از لغو مقالات هستند، یا تمایل دارند سازوکاری برای احراز اصالت لغوها اعمال کنند. این پارامتر نحوه پردازش اعلانات NoCeM توسط perl-nocem(8) را تغییر نمی‌دهد و تنها برای مقالات لغو (با فیلد سرایند Control) و درخواست‌های جایگزینی (با فیلد سرایند Supersedes) اعمال می‌شود.

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

"require-auth"
تنها مقالاتی که در ابتدا با سازوکار احراز اصالت Cancel-Lock محافظت شده‌اند می‌توانند توسط یک مقاله لغو معتبر احراز هویت شده یا یک درخواست جایگزینی معتبر احراز هویت شده پس گرفته شوند. پس‌گرفتن مقالاتی که در ابتدا توسط Cancel-Lock محافظت نشده‌اند اجرا نخواهد شد.

این مقدار پیش‌فرض است اگر innd بداند چگونه لغوها را احراز اصالت کند (به این معنی که INN با پشتیبانی از Cancel-Lock ساخته شده باشد). در غیر این صورت، رفتار مانند "none" خواهد بود.

"auth"
پس‌گرفتن مقالاتی که در ابتدا توسط سازوکار احراز اصالت Cancel-Lock محافظت نشده‌اند همیشه اجرا خواهد شد. با این حال، اگر مقاله اصلی محافظت شده باشد، تنها یک مقاله لغو معتبر احراز هویت شده یا یک درخواست جایگزینی معتبر احراز هویت شده اجازه پس‌گرفتن آن را می‌دهد. (اگر INN با پشتیبانی Cancel-Lock ساخته نشده باشد، چنین مقالات محافظت‌شده‌ای پس گرفته نخواهند شد.)
"none"
نه مقالات لغو و نه درخواست‌های جایگزینی پردازش نخواهند شد؛ هیچ مقاله‌ای پس گرفته نخواهد شد.

این مقدار پیش‌فرض است اگر innd نداند چگونه لغوها را احراز اصالت کند (به این معنی که INN با پشتیبانی Cancel-Lock ساخته نشده باشد) زیرا هیچ ابزاری برای اطمینان از مشروع بودن این درخواست‌های پس‌گرفتن ندارد.

"all"
برنامه innd تمامی مقالات لغو و درخواست‌های جایگزینی را پردازش خواهد کرد، حتی اگر غیرمعتبر، جعلی یا با احراز هویت نادرست باشند. اگر این مقدار را انتخاب می‌کنید باید مطمئن باشید چه می‌کنید، زیرا هر مقاله‌ای ممکن است پس گرفته شود (حتی توسط کسی که نویسنده مقاله نیست).
به‌طور معمول innd(8) مقالات ورودی را هنگامی که توسط هر یک از فیلترهای مقاله فعال (Perl یا Python) به آن دستور داده شود رد می‌کند. با این حال، این پارامتر باعث می‌شود چنین مقالاتی رد نشوند؛ در عوض پالایش می‌تواند روی مقالات خروجی اعمال شود. اگر این پارامتر تنظیم شود، تمامی مقالات در ماشین محلی پذیرفته خواهند شد، اما مقالات ردشده توسط فیلتر به هیچ‌یک از همتایان مشخص‌شده در newsfeeds با فلگ "Af" ارسال نخواهند شد. مقدار پیش‌فرض false است.

اگر این پارامتر تنظیم شده باشد، همچنین می‌توانید از کلید filtered در مدخل‌های روش‌های ذخیره‌سازی در storage.conf برای ذخیره مقالات فیلترشده در کلاس‌های ذخیره‌سازی اختصاصی استفاده کنید.

اگر روی مقداری غیر از "0" تنظیم شود، یک جدول درهم‌سازی (هش) از Message-IDهای به‌تازگی دریافت‌شده در حافظه نگهداری می‌شود تا جستجوهای تاریخچه تسریع شوند. این مقدار میزان حافظه‌ای است که باید به کیلوبایت به حافظه پنهان اختصاص داده شود. این حافظه پنهان تنها برای فیدهای ورودی استفاده می‌شود و یک حافظه پنهان کوچک می‌تواند تعداد زیادی Message-ID را نگه دارد، بنابراین مقادیر بزرگ لزوماً مفید نیستند مگر اینکه فیدهای ورودی با تأخیر شدید داشته باشید. برنامه innreport می‌تواند آمارهای مفیدی درباره استفاده از حافظه پنهان تاریخچه ارائه دهد، به‌ویژه هنگامی که به خطا می‌خورد (miss). یک مقدار مناسب برای سیستمی با بیش از یک فید ورودی "256" است؛ سیستم‌هایی با تنها یک فید ورودی احتمالاً باید این مقدار را روی "0" تنظیم کنند. مقدار پیش‌فرض "256" است.
اینکه آیا پیام‌های کنترلی ایجاد گروه خبری (newgroup و rmgroup) باید به‌گونه‌ای ارسال شوند که گویی در گروه خبری که ایجاد یا حذف می‌کنند ارسال شده‌اند، نه به گروه‌های خبری فهرست‌شده در فیلد سرایند Newsgroups. اگر این پارامتر تنظیم شود، گروه خبری متأثر از پیام کنترلی از فیلد سرایند Control استخراج می‌شود و مقاله به‌گونه‌ای ارسال خواهد شد که گویی فیلد سرایند Newsgroups آن صرفاً شامل همان گروه خبری بوده است. این برای مسیریابی پیام‌های کنترلی به همتایان زمانی که به گروه‌های خبری نامربوط ارسال شده‌اند و نباید با گروه‌های خبری مورد نظر همتا در newsfeeds تطبیق داده شوند مفید است. این یک مقدار بولی است و پیش‌فرض false است.
هنگام استفاده از روش ذخیره‌سازی timecaf، لغو مقالات معمولاً فقط برای لغو شدن پنهان‌سازی (cache) می‌شود، نه اینکه فوراً لغو شود. اگر این مقدار روی true تنظیم شود، به محض پردازش لغو، مقالات لغو خواهند شد. این یک مقدار بولی است و پیش‌فرض false است.

این تنظیم نادیده گرفته می‌شود مگر اینکه از روش ذخیره‌سازی timecaf استفاده شود.

اگر روی مقداری غیر از "0" تنظیم شود، تعداد خطوط مقاله با بدنه فیلد سرایند Lines مقاله (در صورت وجود) بررسی می‌شود و اگر مقادیر بیش از این مقدار اختلاف داشته باشند، مقاله رد خواهد شد. یک تنظیم معقول "5" است، که حداکثر طول استاندارد امضا به علاوه یک است (برخی نرم‌افزارهای تزریق فیلد سرایند Lines را قبل از افزودن امضا محاسبه می‌کنند). مقدار پیش‌فرض "0" است، که به INN می‌گوید فیلد سرایند Lines مقالات ورودی را بررسی نکند.
حداکثر اندازه مقاله (سرایندها و بدنه) که توسط سرور پذیرفته می‌شود، بر حسب بایت. مقدار "0" هر اندازه‌ای از مقاله را مجاز می‌داند، اما توجه داشته باشید که اگر از حافظه سیستم فراتر رود، innd کرش خواهد کرد. مقدار پیش‌فرض "1000000" (تقریباً ۱ مگابایت) است. این مقدار در برابر مقاله در قالب سیمی (CRLF در انتهای هر خط، نقطه‌های آغازین محافظت‌شده، و با "\r\n.\r\n" پایانی در انتها) بررسی می‌شود. همچنین localmaxartsize را ببینید.
حداکثر تعداد اتصالات ورودی NNTP که innd(8) می‌پذیرد. مقدار پیش‌فرض "50" است.
در صورت تنظیم، این مقدار به عنوان یک هویت مسیر بلافاصله در سمت راست pathhost در بدنه فیلد سرایند Path مقالات پذیرفته‌شده اضافه می‌شود، در صورتی که قبلاً در فیلد سرایند Path ظاهر نشده باشد. مقدار پیش‌فرض تنظیم‌نشده است.

هدف اصلی این پارامتر زمانی است که هویت مسیر دیگری وجود دارد که بنا به دلایلی می‌خواهید به فیلد سرایند Path هر مقاله‌ای که از سرور(های) خبری شما عبور می‌کند اضافه شود، شاید به این دلیل که قبلاً هویت مسیر دیگری داشته‌اید و همتایانی دارید که پیکربندی شده‌اند تا مقالاتی را که قبلاً از آن نهاد عبور کرده‌اند برای شما ارسال نکنند، و بنا به دلایلی نمی‌توانید آن‌ها را وادار کنید به هویت مسیر فعلی شما به‌روزرسانی کنند.

در صورت تنظیم، این مقدار به عنوان یک هویت مسیر بلافاصله در سمت چپ pathhost در بدنه فیلد سرایند Path مقالات پذیرفته‌شده اضافه می‌شود، در صورتی که قبلاً به عنوان چپ‌ترین عنصر بدنه فیلد سرایند Path وجود نداشته باشد. مقدار پیش‌فرض تنظیم‌نشده است.

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

اینکه آیا اعتبارسنجی PGP برای پیام‌های کنترلی غیر از cancel فعال شود یا خیر. این یک مقدار بولی است و پیش‌فرض در فایل نمونه inn.conf بر این اساس است که آیا configure برنامه‌های pgp، pgpv، pgpgpg، gpgv، gpgv1، gpgv2، gpg، gpg1 یا gpg2 را یافته است یا خیر. توجه داشته باشید که اگر پارامتر در فایل پیکربندی وجود نداشته باشد، پیش‌فرض آن false است.
کدام درگاه (پورت) TCP باید توسط innd(8) برای گوش دادن استفاده شود. مقدار پیش‌فرض "119"، پورت استاندارد NNTP است.
به‌طور پیش‌فرض، innd(8) مقالات ردشده را در تاریخچه ثبت می‌کند تا در صورت پیشنهاد مجدد همان مقاله، بتوان آن را قبل از ارسال رد کرد. اگر می‌خواهید این رفتار را غیرفعال کنید، این را روی false تنظیم کنید. این می‌تواند باعث افزایش قابل توجه پهنای باند مصرفی توسط اخبار ورودی شود اگر چندین همتا دارید و مقالات زیادی را رد می‌کنید، بنابراین با آن محتاط باشید. حتی اگر این مقدار روی true تنظیم شده باشد، INN برخی از مقالات ردشده را در تاریخچه ثبت نخواهد کرد اگر دلیلی وجود داشته باشد که باور شود ممکن است مقاله در صورت پیشنهاد توسط همتای دیگری پذیرفته شود، بنابراین معمولاً دلیلی برای تنظیم آن روی false وجود ندارد (اگرچه انجام این کار می‌تواند اندازه فایل تاریخچه را کاهش دهد). این یک مقدار بولی است و پیش‌فرض true است.
کدام آدرس IP محلی برای سوکت‌های خروجی NNTP باید متصل (bind) شود (توسط innxmit(8) در میان برنامه‌های دیگر، و همچنین innfeed(8) تا زمانی که توسط bindaddress در innfeed.conf(5) لغو نشده باشد استفاده می‌شود). این باید در قالب چهاربخشی نقطه‌دار (nnn.nnn.nnn.nnn) باشد. اگر روی "all" تنظیم شود، سیستم‌عامل آدرس IP مبدأ را برای اتصالات خروجی انتخاب خواهد کرد. مقدار پیش‌فرض تنظیم‌نشده است.
مانند sourceaddress اما برای سوکت‌های IPv6. توجه داشته باشید که در صورت تنظیم این مقدار، معمولاً باید اطراف آن نقل‌قول دوتایی ("") قرار دهید، زیرا آدرس‌های IPv6 حاوی دونقطه هستند.
این مقدار را روی true تنظیم کنید تا مقالات ورودی که حاوی یک گروه خبری ناشناخته در کل فهرست گروه‌های خبری ارسالی خود هستند رد شوند. در صورتی که wanttrash روی true تنظیم شده باشد، چنین مقالاتی همچنان رد خواهند شد. این یک مقدار بولی است و پیش‌فرض false است.
اگر می‌خواهید مقالات ارسال‌شده به گروه‌های خبری ناشناخته (گروه‌های خبری که در فایل active نیستند) به‌جای رد شدن در گروه خبری "junk" بایگانی شوند، این مقدار را روی true تنظیم کنید. این گاهی برای یک سرور خبری ترانزیت که نیاز به انتشار مقالات (مطابق با تنظیم "Aj" در الگوی فید newsfeeds) در تمامی گروه‌های خبری بدون توجه به اینکه آیا به‌صورت محلی نگهداری می‌شوند یا خیر دارد، مفید است. این یک مقدار بولی است و پیش‌فرض false است.

پارامتر logtrash مشخص می‌کند که آیا چنین مقالاتی باید به عنوان ارسال‌شده به گروه‌های خبری ناخواسته در فایل گزارش news ثبت شوند یا خیر.

اگر مقاله‌ای توسط یک همتا در یک کانال به INN پیشنهاد شود، برای این تعداد ثانیه پاسخ‌های تعویق (کد 436) به تمام پیشنهادات دیگر آن مقاله برمی‌گرداند. (پس از این مدت، اگر همتایی که مقاله را پیشنهاد داده هنوز آن را ارسال نکرده باشد، از کانال‌های دیگر پذیرفته خواهد شد.) مقدار پیش‌فرض "5" است و احتمالاً نیازی به تغییر ندارد.
چه مدت، بر حسب ثانیه، شناسه‌های پیام پیشنهادشده روی یک کانال قبل از منقضی کردن مقالاتی که هنوز ارسال نشده‌اند ردیابی شوند. مقدار پیش‌فرض "10" است و احتمالاً نیازی به تغییر ندارد.

پارامتر زیر بر پایگاه‌داده تاریخچه تأثیر می‌گذارد.

کدام روش ذخیره‌سازی تاریخچه باید استفاده شود. تنها مقداری که در حال حاضر پشتیبانی می‌شود "hisv6" است. هیچ مقدار پیش‌فرضی وجود ندارد؛ این پارامتر باید تنظیم شود.
"hisv6"
داده‌های تاریخچه را در قالب تاریخچه نسخه ۶ INN ذخیره می‌کند: فایل متنی history(5) و تعدادی فایل پایگاه‌داده dbz؛ این ممکن است بسته به گزینه‌های ساخت، در قالب واقعی تاریخچه v6 یا قالب درهم‌سازی برچسب‌دار (tagged hash) باشد. جداسازی این دو پروژه‌ای است که هنوز انجام نشده است.

این پارامترها بر نحوه ذخیره‌سازی مقالات روی دیسک تأثیر می‌گذارند.

اگر روی مقداری غیر از "0" تنظیم شود، اندازه ادعاشده مقالات در بافرهای چرخشی CNFS در برابر maxartsize به علاوه این مقدار بررسی می‌شود و در صورت بزرگ‌تر بودن، بافر چرخشی CNFS مخدوش در نظر گرفته می‌شود. این می‌تواند به عنوان یک بررسی سلامت پس از کرش سیستم مفید باشد، اما اگر اخیراً maxartsize را تغییر داده‌اید، در استفاده از این پارامتر دقت کنید. مقدار پیش‌فرض "0" است.
اینکه آیا داده‌های نمای کلی (overview) برای مقالات نوشته شود یا خیر. اگر روی false تنظیم شود، INN بسیار سریع‌تر اجرا خواهد شد، اما خواندن اخبار از سیستم غیرممکن خواهد بود (سرور تنها برای ترانزیت خبر خواهد بود). اگر این گزینه روی true تنظیم شود، ovmethod نیز باید تنظیم گردد. این یک مقدار بولی است و پیش‌فرض true است.
فیلتر بلوم استفاده‌شده توسط expireover را برای تسریع در انقضای نمای کلی کنترل می‌کند. مقدار معکوس نرخ مثبت کاذب مورد نظر است: برای نمونه، "10000" به معنای نرخ مثبت کاذب ۱ در ۱۰٬۰۰۰ (۰٫۰۱٪) است. مقادیر بالاتر از حافظه بیشتری استفاده می‌کنند اما مثبت کاذب کمتری تولید می‌نمایند. در مقدار پیش‌فرض "10000"، مصرف حافظه تقریباً ۲۰ بیت به ازای هر مقاله در فایل history است (مثلاً ۴۸ مگابایت برای ۲۰ میلیون مقاله، ۲٫۴ گیگابایت برای ۱ میلیارد مقاله).

تنظیم این مقدار روی "0" فیلتر بلوم را کاملاً غیرفعال می‌کند و به جستجوی تاریخچه به ازای هر مقاله بازمی‌گردد (رفتار قبلی). این برای مخازن بزرگ توصیه نمی‌شود زیرا منجر به ورودی/خروجی تصادفی به فایل history برای هر مقاله در پایگاه‌داده نمای کلی می‌شود.

هنگامی که expireover با فلگ -s اجرا شود (که بررسی وضعیت فایل‌سیستم stat را برای هر مقاله اجباری می‌کند)، فیلتر بلوم هیچ تأثیری ندارد.

این یک عدد صحیح غیرمنفی است و پیش‌فرض آن "10000" است.

اینکه آیا ابزارهای INN سنگ‌قبرهای لغو (cancellation tombstones) را ثبت کنند تا اجرای بعدی expire بتواند از بررسی‌های وجود در محل ذخیره‌سازی به ازای هر مقاله صرف‌نظر کند یا خیر. هنگامی که فعال باشد (و groupbaseexpiry نیز true باشد)، دو فایل گزارش در pathdb هر لغو را ثبت می‌کنند:
پس از هر "SMcancel" موفق در انقضای مبتنی بر گروه توسط expireover نوشته شده و در یک اجرای تمیز، به‌صورت اتمیک به نام نهایی تغییر نام می‌یابد. هنگامی که expireover با فلگ -z (حذف با تأخیر) اجرا می‌شود، فراخوانی‌های "SMcancel" از طریق expirerm به fastrm واگذار می‌شوند؛ expireover مدخل‌ها را از ابتدا می‌نویسد و expirerm تغییر نام اتمیک را پس از موفقیت fastrm انجام می‌دهد، بنابراین همان افزایش سرعت برای تنظیمات delayrm اعمال می‌شود. پس از اینکه expire این فایل را مصرف کرد، آن را unlink کرده و به عنوان جانشین فقط-سرایند مجدداً ایجاد می‌کند تا با حضور دیسکی cancels.tombstone مطابقت داشته باشد؛ اجرای بعدی expireover فایل ایجادشده را با محتوای کامل خود بازنویسی می‌کند.
هنگامی که innd پیام‌های کنترلی cancel را پردازش می‌کند و توسط sm -r برای لغوهای دستی، به‌صورت پیوسته ضمیمه می‌شود. افزایندگان یک قفل مشترک fcntl POSIX می‌گیرند؛ expire تحت یک قفل انحصاری fcntl با تغییر نام اتمیک به cancels.tombstone.processing از فایل اسنپ‌شات می‌گیرد، اسنپ‌شات را پس از مصرف موفقیت‌آمیز unlink می‌کند، سپس cancels.tombstone را به عنوان یک فایل فقط-سرایند تحت قفل انحصاری بازسازی می‌کند تا مسیر سریع به ازای هر اتصال nnrpd در دوره‌های آرام میان لغوها فعال بماند. افزاینده‌ای که بین تغییر نام و بازسازی، یک لغو را در فایل زنده جدید ثبت کرده باشد، محتوایش به صورت دست‌نخورده در زیر سرایند بازیابی‌شده حفظ می‌شود. اتمیک بودن ضمیمه به تضمین POSIX متکی است که هر "write(2)" به یک فایل معمولی باز شده با "O_APPEND" نسبت به سایر نویسندگان اتمیک است؛ این برای هر اندازه‌ای از یک "write" منفرد روی فایل‌سیستم‌های محلی صادق است. اتمیک بودن بین کلاینت‌ها روی NFS تضمین نمی‌شود: اگر pathdb روی NFS باشد، خطوط نویسندگان همزمان روی کلاینت‌های مختلف در تئوری می‌توانند در هم تنیده شوند. در عمل منابع لغو INN (innd روی یک میزبان واحد به علاوه sm -r گاه‌به‌گاه روی همان میزبان) از یک کلاینت می‌نویسند.

فراخوانی بعدی expire هر دو فایل را در یک مجموعه هش منفرد بارگذاری کرده و با هر مقاله در هر یک از دو لاگ به عنوان مقاله‌ای که از قبل حذف شده رفتار می‌کند، و بدین ترتیب از یک فراخوانی "SMretrieve(RETR_STAT)" به ازای هر مدخل تاریخچه اجتناب می‌کند. برای روش‌های ذخیره‌سازی که در آن‌ها stat یک فراخوانی فایل‌سیستم است (tradspool، timehash)، این کار یک میلیارد فراخوانی "access(2)" را به چند هزار جستجوی هش تبدیل می‌کند؛ برای روش‌های ذخیره‌سازی که خودمنقضی‌شونده هستند (CNFS)، فراخوانی stat باقی می‌ماند زیرا مقالات می‌توانند به دلیل چرخش بافر بدون عبور از "SMcancel" ناپدید شوند.

در عملکرد عادی، هر مسیر لغو در ردیابی سنگ‌قبر مشارکت دارد، بنابراین تمام مقالات حذف‌شده از مخزن ثبت می‌شوند. مقالات یتیم باقی‌مانده تنها می‌توانند از رویدادهای خارج از مسیرهای ردیابی‌شده جمع شوند: کرش پردازش در پنجره زمانی باریک بین "SMcancel" و ضمیمه سنگ‌قبر، حذف‌های دستی در سطح فایل‌سیستم که sm -r را دور می‌زنند، یا خرابی فایل‌سیستم. هنگامی که چنین مقالات یتیمی ظاهر می‌شوند، بی‌ضرر هستند (nnrpd پیام "no such article" را به خوانندگانی که به آن‌ها برخورد می‌کنند برمی‌گرداند) و تنها به عنوان مدخل‌های کوچک تاریخچه وجود دارند. هیچ دوره تطبیق منظمی مورد نیاز نیست. اگر اپراتور به انباشت مقالات یتیم پس از مداخله مدیر یا حادثه ذخیره‌سازی مشکوک شود، expire می‌تواند با غیرفعال بودن این گزینه در inn.conf مجدداً اجرا شود تا یک اسکن جامع "SMretrieve(RETR_STAT)" انجام دهد؛ این یک عملیات استثنایی است، نه یک عملیات زمان‌بندی‌شده.

میزان مصرف: حدود ۳۸ بایت به ازای هر مدخل روی دیسک، حدود ۵۰ بایت در جدول هش expire. برای نمونه، ۱ میلیون لغو در هر اجرا نیاز به حدود ۳۸ مگابایت برای سنگ‌قبر و حدود ۵۰ مگابایت برای هش دارد.

این یک مقدار بولی است و پیش‌فرض آن false است؛ سایت‌ها باید پس از ارزیابی رفتار این گزینه در برابر بار کاری خود، آن را فعال کنند.

علاوه بر هفت فیلد استاندارد نمای کلی (که به ترتیب عبارتند از "Subject"، "From"، "Date"، "Message-ID"، "References"، ":bytes" و ":lines") و هشتمین فیلد "Xref:full" که توسط INN برای مدیریت ارسال‌های چندگانه (crosspost) الزامی است، می‌توان فیلدهای دیگری را نیز در پایگاه‌داده نمای کلی اضافه کرد. این پارامتر فهرستی از نام این فیلدهای سرایند را انتظار دارد. داده‌های نمای کلی برای این فیلدهای سرایند اضافی برای هر مقاله جدید در زمان ورود تولید خواهد شد. برای نمونه، اگر مشخص کنید: 
extraoverviewadvertised: [ Path Newsgroups ]

این بدان معناست که nnrpd فیلدهای "Path:full" و "Newsgroups:full" را به عنوان فیلدهای نهم و دهم در پاسخ به LIST OVERVIEW.FMT اعلان خواهد کرد و بدنه این دو فیلد سرایند برای هر مقاله جدید در پایگاه‌داده نمای کلی ذخیره خواهد شد. این ممکن است پیکربندی مفیدی باشد زیرا برخی خبرخوان‌ها امتیازدهی مقالات را با قوانینی بر اساس این دو فیلد سرایند انجام می‌دهند. داشتن آن‌ها در پایگاه‌داده نمای کلی اجازه می‌دهد امتیازدهی برای این خوانندگان سریع‌تر انجام شود، بدون اینکه نیاز به درخواست جداگانه آن‌ها باشد، اما از سوی دیگر این فیلدهای اضافی در درخواست‌های نمای کلی تمام خوانندگان دیگر نیز وجود دارند که خواندن آن‌ها را اندکی کند می‌کند.

مقدار پیش‌فرض یک فهرست خالی است (هیچ فیلد اضافی ذخیره نمی‌شود). با توجه به بهینه‌سازی‌ها هنگامی که innd مقالات دریافتی را تجزیه می‌کند، ممکن است تمام مقادیر موجود در فهرست توسط innd به عنوان نام‌های فیلد سرایند استاندارد شناسایی نشوند. در چنین مواردی، innd خطایی را در زمان راه‌اندازی در news.err ثبت می‌کند و فیلدهای ناشناخته کنار گذاشته می‌شوند. افزون بر این، فیلدهای سرایند منسوخ "Bytes" و "Lines" که از قبل در فیلدهای استاندارد نمای کلی به عنوان اقلام متادیتا وجود دارند، نمی‌توانند اضافه شوند.

شما باید تنها فیلدهایی را اعلان کنید که پایگاه‌داده نمای کلی برای آن‌ها سازگار است، به این معنی که محتوا یا عدم وجود این فیلدها را برای تمام مقالات، از جمله مقالاتی که از قبل در مخزن خبر وجود دارند، ثبت کرده باشد. در نتیجه، اگر تصمیم به افزودن یا حذف فیلدی از پایگاه‌داده نمای کلی خود گرفتید، باید یا extraoverviewadvertised را تغییر داده و پایگاه‌داده نمای کلی خود را با makehistory(8) پس از حذف تمام فایل‌های نمای کلی موجود بازسازی کنید، یا با استفاده اولیه از extraoverviewhidden همان‌طور که در زیر شرح داده شده، یک دوره گذار پیاده‌سازی نمایید.

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

اگر برای نمونه می‌خواهید محتوای بدنه فیلد سرایند Injection-Info را علاوه بر فیلدهایی که در بالا ذخیره شده‌اند ذخیره کنید، باید استفاده کنید از:

extraoverviewadvertised: [ Path Newsgroups ]
extraoverviewhidden:     [ Injection-Info ]

به این ترتیب، "Injection-Info:full" توسط nnrpd اعلان نخواهد شد اما برای هر مقاله جدید ذخیره می‌شود. هنگامی که مطمئن شدید تمام مقالات در پایگاه‌داده نمای کلی شما محتوا یا عدم وجود آن فیلد جدید را ثبت کرده‌اند (اگر expire.ctl(5) به‌گونه‌ای پارامتربندی شده باشد که تمام مقالات شما ظرف ۳۰ روز منقضی شوند، می‌توانید فرض کنید پایگاه‌داده پس از ۳۰ روز در چنین وضعیتی است -- با این حال، توجه داشته باشید که زمان انقضا می‌تواند با CNFS غیرقابل پیش‌بینی باشد و سپس باید از "cnfsstat -a" برای بررسی اینکه چه زمانی بافرها دور زده‌اند استفاده کنید)، باید قرار دهید:

extraoverviewadvertised: [ Path Newsgroups Injection-Info ]
extraoverviewhidden:     [ ]

مقدار "Injection-Info" باید در انتهای فهرست اضافه شود زیرا ترتیب مهم است و فیلدهای ذکرشده در extraoverviewhidden پس از فیلدهای ذکرشده در extraoverviewadvertised تولید می‌شوند. اکنون nnrpd فیلد "Injection-Info:full" را در پاسخ به دستور LIST OVERVIEW.FMT اعلان خواهد کرد ("full" نشان می‌دهد که نام فیلد سرایند به همراه مقدار آن ظاهر می‌شود).

اکنون فرض کنید می‌خواهید محتوای فیلد سرایند Newsgroups را از نمای کلی حذف کنید. از آنجا که ترتیب مهم است، پایگاه‌داده نمای کلی دیگر برای فیلد سرایند Injection-Info سازگار نخواهد بود. بنابراین، باید مشخص کنید:

extraoverviewadvertised: [ Path ]
extraoverviewhidden:     [ Injection-Info ]

و هنگامی که داده‌های نمای کلی برای تمام مقالات دقیق شد، باید استفاده کنید از:

extraoverviewadvertised: [ Path Injection-Info ]
extraoverviewhidden:     [ ]

توجه داشته باشید که اگر nnrpd به‌صورت دیمن اجرا می‌شود، هر زمان که مقدار extraoverviewadvertised را تغییر می‌دهید باید آن را مجدداً راه‌اندازی کنید؛ یک دستور ساده "ctlinnd xexec innd" کافی نیست.

این پارامتر باید در ارتباط با extraoverviewadvertised استفاده شود (برای جزئیات بیشتر به بالا مراجعه کنید). این پارامتر فهرستی از نام‌های فیلدهای سرایند را انتظار دارد. داده‌های نمای کلی برای این فیلدهای سرایند برای هر مقاله جدید در زمان ورود تولید خواهند شد، اما برعکس فیلدهای ذکرشده در extraoverviewadvertised، برنامه nnrpd آن‌ها را در پاسخ به دستور LIST OVERVIEW.FMT اعلان نخواهد کرد. این همچنین بدان معناست که nnrpd هنگامی که به درخواست‌های HDR، XHDR و XPAT رسیدگی می‌کند، در پایگاه‌داده نمای کلی به دنبال فیلدهای ذکرشده در extraoverviewhidden نخواهد گشت زیرا پایگاه‌داده نمای کلی هنوز برای این فیلدها سازگار در نظر گرفته نمی‌شود؛ nnrpd مجبور خواهد بود سرایندهای مقالات درخواستی را در مخزن خبر تجزیه کند، که کندتر از پرس‌وجوی مستقیم از پایگاه‌داده نمای کلی است.

مقدار پیش‌فرض یک فهرست خالی است (هیچ فیلد اضافی ذخیره نمی‌شود). با توجه به بهینه‌سازی‌ها هنگامی که innd مقالات دریافتی را تجزیه می‌کند، ممکن است تمام مقادیر موجود در فهرست توسط innd به عنوان نام‌های فیلد سرایند استاندارد شناسایی نشوند. در چنین مواردی، innd خطایی را در زمان راه‌اندازی در news.err ثبت می‌کند و فیلدهای ناشناخته کنار گذاشته می‌شوند. افزون بر این، فیلدهای سرایند منسوخ "Bytes" و "Lines" که از قبل در فیلدهای استاندارد نمای کلی به عنوان اقلام متادیتا وجود دارند، نمی‌توانند اضافه شوند.

اینکه آیا انقضای مبتنی بر گروه خبری فعال شود یا خیر. اگر روی false تنظیم شود، انقضای مقاله بر اساس کلاس ذخیره‌سازی روش ذخیره انجام می‌شود. اگر روی true تنظیم شود (و اطلاعات نمای کلی در دسترس باشد)، انقضا بر اساس نام گروه خبری انجام می‌پذیرد. این بر قالب expire.ctl تأثیر می‌گذارد. این یک مقدار بولی است و پیش‌فرض true است.
اینکه آیا تمام ارسال‌ها به گروه‌های "to.*" در شبه‌گروه خبری "to" بایگانی شوند یا خیر. اگر روی true تنظیم شود، گروه خبری "to" باید در فایل active وجود داشته باشد وگرنه INN راه‌اندازی نخواهد شد. (بحث مربوط به گروه‌های "to." در innd(8) را ذیل بخش CONTROL MESSAGES ببینید.) این یک مقدار بولی است و پیش‌فرض false است.
برای سرورهایی که مقاله می‌نویسند، تعیین می‌کند که آیا مخزن مقاله روی حافظه NFS است یا خیر. در صورت تنظیم، INN تلاش می‌کند مقالات را به موقع‌تر در مخزن خالی (flush) کند، به جای اینکه به سیستم‌عامل برای خالی کردن مواردی مانند بیت‌مپ‌های مقاله CNFS متکی باشد. تنها در صورتی باید این پارامتر را تنظیم کنید که در تلاش برای استفاده از یک مخزن اشتراکی NFS روی ماشینی باشید که به عنوان یک نویسنده منفرد در یک کلاستر عمل می‌کند. این یک مقدار بولی است و پیش‌فرض false است.
چه تعداد اسلات حافظه پنهان برای فایل‌های باز نمای کلی رزرو شود. اگر INN در حال نوشتن فایل‌های نمای کلی است (ببینید enableoverview)، پارامتر ovmethod روی "tradindexed" تنظیم شده باشد، و این مقدار روی مقداری غیر از "0" تنظیم گردد، INN آن تعداد از فایل‌های نمای کلی اخیراً نوشته‌شده را در صورت ورود مقالات بیشتر برای آن گروه‌های خبری، باز و آماده نگه می‌دارد. هر اسلات حافظه پنهان نمای کلی دو توصیف‌گر فایل (file descriptor) مصرف می‌کند، بنابراین مراقب باشید این مقدار را خیلی بالا تنظیم نکنید. می‌توانید از دستور "ulimit -n" استفاده کنید تا ببینید سیستم‌عامل شما چه تعداد توصیف‌گر فایل باز را مجاز می‌داند. برنامه innd(8) همچنین برای هر فید ورودی و کانال خروجی یا فایل دسته‌ای از یک توصیف‌گر فایل باز استفاده می‌کند، و اگر توصیف‌گرهای فایل باز آن تمام شود، ممکن است مهار (throttle) شده و پذیرش اخبار جدید را متوقف کند. مقدار پیش‌فرض "128" است (که احتمالاً هنوز خیلی کم است اگر تعداد زیادی توصیف‌گر فایل در دسترس دارید).

لطفاً نگاهی به مستندات پارامتر rlimitnofile بیندازید، زیرا افزایش مقدار پیش‌فرض ممکن است منجر به اتمام توصیف‌گرهای فایل قابل استفاده شود.

این تنظیم نادیده گرفته می‌شود مگر اینکه ovmethod روی "tradindexed" تنظیم شده باشد.

در صورت تنظیم، داده‌های نمای کلی ذخیره‌شده توسط INN را تنها به گروه‌های خبری منطبق با این فهرست جداشده با کاما از عبارات uwildmat محدود می‌کند. گروه‌های خبری که با این تنظیم مطابقت ندارند ممکن است قابل خواندن نباشند، و اگر groupbaseexpiry روی true تنظیم شده باشد و روش ذخیره‌سازی برای این گروه‌های خبری قابلیت خودانقضایی نداشته باشد، ذخیره داده‌های نمای کلی با شکست مواجه خواهد شد. پیش‌فرض تنظیم‌نشده است.
تعداد مقالات دریافت‌شده بین هر بار خالی کردن داده‌های نمای کلی آن‌ها به دیسک. این پارامتر تنها برای روش ذخیره‌سازی نمای کلی buffindexed استفاده می‌شود و پیش‌فرض آن "50" است. (خالی کردن به دیسک برای سایر روش‌ها به گونه متفاوتی پارامتربندی می‌شود: txn_nosync در ovdb.conf، transrowlimit و transtimelimit در ovsqlite.conf، و برای tradindexed همیشه پس از ورود هر مقاله.)

پارامتر icdsynccount (مربوط به همگام‌سازی فایل‌های active و history) را برای اطلاعات بیشتر در مورد این تعادل میان سرعت بیشتر و از دست رفتن داده‌های بیشتر در صورت کرش innd ببینید.

کدام روش ذخیره‌سازی نمای کلی استفاده شود. مقادیر پشتیبانی‌شده در حال حاضر عبارتند از "buffindexed"، "ovdb"، "ovsqlite" و "tradindexed". هیچ مقدار پیش‌فرضی وجود ندارد؛ این پارامتر باید در صورتی که enableoverview برابر با true باشد (پیش‌فرض) تنظیم شود.
"buffindexed"
این روش داده‌های نمای کلی و اطلاعات نمایه را در فایل‌های بزرگ از پیش پیکربندی‌شده مانند CNFS ذخیره می‌کند. در نوشتن سریع است، روش ذخیره‌سازی نمای کلی "buffindexed" می‌تواند به راحتی با فیدهای بزرگ همراه شود و هرگز فضای دیسک اضافی فراتر از آنچه به این بافرها اختصاص داده شده مصرف نمی‌کند. نقطه ضعف این است که بازیابی این بافرها در صورت خرابی دشوار است و تا حدودی برای خوانندگان و فرآیند انقضا کندتر است. همچنین، داده‌های نمای کلی به ۸ کیلوبایت به ازای هر مقاله محدود می‌شود، که ممکن است منجر به عدم ادغام چند مقاله با سرایندهای غیرمعمول طولانی در پایگاه‌داده نمای کلی شود. برای جزئیات بیشتر و به‌ویژه نحوه ایجاد بافرها، صفحه راهنمای buffindexed.conf(5) را ببینید.
"ovdb"
این روش اطلاعات نمای کلی را در پایگاه‌داده Berkeley DB ذخیره می‌کند که روند توسعه آن در سال‌های اخیر متوقف شده است. این روش سریع و بسیار پایدار است، اما ممکن است به فضای دیسک بیشتری نیاز داشته باشد مگر اینکه فشرده‌سازی فعال شود. داده‌های نمای کلی هر بار برای یک مقاله بازیابی می‌شوند که این روش را برای خوانندگان اندکی کندتر از "ovsqlite" می‌کند. برای جزئیات بیشتر صفحه راهنمای ovdb(5) را ببینید.
"ovsqlite"
این روش اطلاعات نمای کلی را در پایگاه‌داده SQLite ذخیره می‌کند که به پایداری و سازگاری طولانی‌مدت معروف است. پایدار و در خواندن محدوده‌های داده نمای کلی سریع‌تر از "ovdb" است (زیرا داده‌های نمای کلی در قطعات ۱۲۸ کیلوبایتی بین ovsqlite-server و nnrpd انتقال می‌یابند) اما در نوشتن تا حدودی کندتر است، این روش ممکن است به فضای دیسک بیشتری نیاز داشته باشد مگر اینکه فشرده‌سازی فعال شود. برای جزئیات بیشتر صفحه راهنمای ovsqlite(5) را ببینید.
"tradindexed"
این روش از دو فایل به ازای هر گروه خبری استفاده می‌کند، یکی حاوی داده‌های نمای کلی و دیگری حاوی نمایه. برای خوانندگان سریع است، اما در نوشتن کند است زیرا باید برای هر مقاله ورودی دو فایل را به‌روزرسانی کند. مزیت اصلی آن این است که آزموده‌ترین، قابل‌اعتمادترین و دارای بهترین ابزارهای بازیابی (tdx-util) است.
اگر روی true تنظیم شود، مقالات بر اساس نام‌های گروه خبری در بدنه فیلد سرایند Xref ذخیره می‌شوند تا در بدنه فیلد سرایند Newsgroups. این بر اینکه الگوها در storage.conf برای چه اعمال می‌شوند تأثیر می‌گذارد. تأثیر جالب اصلی تنظیم این روی true فعال کردن بایگانی تمامی پیام‌های کنترلی بر اساس کلاس ذخیره‌سازی شبه‌گروه‌های کنترلی است، به جای اینکه بر اساس گروه‌های خبری که پیام‌های کنترلی در آن‌ها ارسال شده‌اند باشد. این یک مقدار بولی است و پیش‌فرض true است.

اگر روش ذخیره‌سازی مقاله tradspool استفاده شود، storeonxref باید برابر با true باشد.

اینکه آیا innd(8) باید داده‌های نمای کلی را در داخل از طریق libinnstorage(3) ایجاد کند یا خیر. اگر روی false تنظیم شود، innd داده‌های نمای کلی را خود ایجاد می‌کند. اگر روی true تنظیم شود، innd ایجاد نمی‌کند؛ در عوض داده‌های نمای کلی باید توسط overchan(8) از یک مدخل مناسب در newsfeeds ایجاد شوند. تنظیم روی true ممکن است در صورتی مفید باشد که innd نتواند با فید ورودی همراه شود و گلوگاه، ایجاد داده‌های نمای کلی درون innd باشد. این یک مقدار بولی است و پیش‌فرض false است.
تنها با روش ذخیره‌سازی tradspool استفاده می‌شود و مشخص می‌کند که آیا مقالات در قالب سیمی نوشته شوند یا خیر. قالب سیمی به معنای ذخیره مقالات با "\r\n" در انتهای هر خط و با نقطه‌های ابتدای خط مضاعف‌شده است، قالبی از مقاله که توسط پروتکل NNTP الزامی است. مقالات ذخیره‌شده در این قالب برای ارسال مستقیم به اتصال شبکه بدون نیاز به تبدیل مناسب هستند، و بنابراین تنظیم این روی true می‌تواند سرور را کارآمدتر کند. دلیل اصلی برای عدم تنظیم این زمانی است که نرم‌افزار قدیمی موجودی دارید که در مخزن جستجو می‌کند و نحوه خواندن قالب سیمی را درک نمی‌کند. روش‌های ذخیره‌سازی غیر از tradspool همیشه مقالات را در قالب سیمی ذخیره می‌کنند. این یک مقدار بولی است و پیش‌فرض true است.
اینکه آیا به عنوان پیرو (slave) سرور دیگری عمل شود یا خیر. در صورت تنظیم، INN شماره‌گذاری مقالات سروری را که به آن فید می‌دهد با نگاه کردن به بدنه فیلد سرایند Xref مقالات ورودی و تخصیص همان شماره‌های مقاله به مقالاتی که در بدنه فیلد سرایند Xref از سرور بالادست ذکر شده بود، دقیقاً تکرار می‌کند. اگر فیلد سرایند Xref وجود نداشته باشد یا غیرقابل تجزیه باشد، مقاله رد خواهد شد. نتیجه این است که کلاینت‌ها باید بتوانند به هر یک از سرورها به جای یکدیگر اشاره کنند (مثلاً با استفاده از نوعی طرح تعادل بار) و همان شماره‌گذاری داخلی مقاله را ببینند.

سرورهایی با این پارامتر تنظیم‌شده معمولاً باید تنها یک فید بالادست داشته باشند، و همیشه باید nnrpdposthost را تنظیم کرده باشند تا مقالات ارسال‌شده محلی را به سرور اصلی تحویل دهند. سرور بالادست باید دقت کند که مقالات را به ترتیب ارسال کند تا فایل تاریخچه سرور پیرو از نظر زمانی مرتب بماند، زیرا فرآیند انقضا بر اساس زمان ورود مقالات است (مگر اینکه فلگ -p به expire و expireover داده شود تا تصمیمات انقضا به جای آن نسبت به تاریخ‌های ارسال اتخاذ شود، اما روش‌های ذخیره‌سازی خودمنقضی‌شونده مانند CNFS در هر حال دور می‌زنند و مقالات را به همان ترتیبی که رسیده‌اند حذف می‌کنند). این یک مقدار بولی است و پیش‌فرض false است.

به doc/FAQ (موضوع 6.4) برای نمونه‌ای از کاربرد این پارامتر هنگام ارسال تمامی مقالات روی یک سرور به سرور دیگر با حفظ ترتیب زمانی آن‌ها مراجعه کنید.

این پارامترها بر رفتار INN برای خوانندگان اخبار تأثیر می‌گذارند. بیشتر آن‌ها توسط nnrpd(8) استفاده می‌شوند. چند مجموعه ویژه از تنظیمات وجود دارند که پس از فهرست الفبایی اولیه به‌طور جداگانه تقسیم‌بندی شده‌اند.

اینکه آیا استفاده از دستور NEWNEWS توسط کلاینت‌ها مجاز باشد یا خیر. این دستور در نسخه‌های قدیمی‌تر INN بار سنگینی بر سرور تحمیل می‌کرد، اما اکنون نسبتاً کارآمد است، دست‌کم اگر تنها یک گروه خبری توسط کلاینت مشخص شده باشد. این یک مقدار بولی است و پیش‌فرض true است. اگر از پارامتر access در readers.conf استفاده می‌کنید، حتماً درباره نحوه لغو شدن allownewnews توسط آن مطالعه کنید.
اینکه آیا تلاش شود تا مقالات با ()mmap نگاشت شوند یا خیر. تنظیم این مقدار روی true در بیشتر سیستم‌ها عملکرد بهتری به همراه خواهد داشت، اما برخی سیستم‌ها با ()mmap مشکل دارند. اگر این مقدار روی false تنظیم شود، مقالات قبل از ارسال به خوانندگان در حافظه خوانده می‌شوند. این یک مقدار بولی است و پیش‌فرض true است.
یک اتصال کلاینت چه مدت (بر حسب ثانیه) می‌تواند بیکار بماند تا خارج شود. هنگام تنظیم این پارامتر، توجه داشته باشید که برخی از نرم‌افزارهای خواننده خبر از یک اتصال مشابه برای خواندن و ارسال استفاده می‌کنند و با قطع اتصال هنگام نگارش مقاله به دلیل زمان‌بندی خروج به‌خوبی برخورد نمی‌کنند. اگر سیستم مشکلی با اتصالات طولانی‌مدت متعدد ندارد، افزایش این مقدار به "3600" (یک ساعت) می‌تواند ایده خوبی باشد. مقدار پیش‌فرض "1800" (سی دقیقه) است.
مدت زمانی (بر حسب ثانیه) که nnrpd قبل از قطع اتصال، منتظر اولین دستور از سوی اتصال خواننده می‌ماند. این یک مهلت زمانی دفاعی است که هدف آن محافظت از سرور خبری در برابر کلاینت‌های بدرفتار خواننده است که تعداد زیادی اتصال را بدون بستن آن‌ها باز کرده و رها می‌کنند. مقدار پیش‌فرض "10" (ده ثانیه) است که اگر کلاینت‌های زیادی از طریق پیوندهای شبکه کند متصل شوند ممکن است نیاز به افزایش داشته باشد.
چه تعداد اسلات حافظه پنهان برای ترجمه شناسه‌های پیام به نشانه‌های ذخیره‌سازی رزرو شود. هنگام ارائه داده‌های نمای کلی به کلاینت‌ها (NEWNEWS، OVER و غیره)، nnrpd(8) می‌تواند نشانه ذخیره‌سازی مرتبط با شناسه پیام را در حافظه پنهان ذخیره کند و از هزینه جستجوی آن در فایل history صرفه‌جویی نماید؛ برای برخی پیکربندی‌ها، تنظیم این پارامتر می‌تواند بیش از ۹۰٪ از زمان واقعی یک نشست را ذخیره کند. مقدار پیش‌فرض "64000" است.
برای سرورهایی که مقالات را می‌خوانند، تعیین می‌کند که آیا مخزن مقاله روی حافظه NFS است یا خیر. در صورت تنظیم، INN تلاش می‌کند تا مقالات و داده‌های نمای کلی را مجبور کند مستقیماً از مخزن NFS خوانده شوند به جای اینکه از نسخه‌های پنهان‌شده خوانده شوند. تنها در صورتی باید این پارامتر را تنظیم کنید که در حال تلاش برای استفاده از یک مخزن اشتراکی NFS روی ماشینی باشید که به عنوان یک خواننده در یک کلاستر عمل می‌کند. این یک مقدار بولی است و پیش‌فرض false است.
اگر nfsreader تنظیم شده باشد، INN از مقدار nfsreaderdelay برای به تأخیر انداختن زمان ظاهری ورود مقالات به کلاینت‌ها به این میزان استفاده می‌کند. توجه داشته باشید که تنها پاسخ‌ها به دستورات GROUP و NEWNEWS تحت تأثیر قرار می‌گیرند. این مقدار باید بر اساس مهلت‌های زمانی حافظه پنهان NFS به‌صورت محلی تنظیم شود. مقدار پیش‌فرض "60"، یعنی یک دقیقه است.
اینکه آیا nnrpd باید وجود یک مقاله را قبل از فهرست کردن آن به عنوان موجود در پاسخ به یک دستور NNTP (مانند HDR، LISTGROUP، NEWNEWS، OVER، XPAT) بررسی کند یا خیر. کاربرد اصلی این تنظیم جلوگیری از بازگرداندن اطلاعات توسط nnrpd درباره مقالاتی است که دیگر روی سرور وجود ندارند اما هنوز داده‌های نمای کلی آن‌ها در دسترس است. بررسی وجود با یک "SMretrieve" بدون قید و شرط دستورات نمای کلی را کند می‌کند؛ با فعال بودن همزمان expiretombstone (به زیر مراجعه کنید)، بررسی از یک جستجوی هش درون حافظه استفاده می‌کند و ارزان‌تر از غیرفعال کردن بررسی در بک‌اندهای tradspool/timehash/timecaf است. تعادل همچنان باقی است: فعال کردن این گزینه تعداد خطاهای "article is missing" دیده‌شده توسط کلاینت را کاهش می‌دهد. این یک مقدار بولی است و پیش‌فرض true است.

هنگامی که expiretombstone نیز فعال باشد، nnrpd در مسیر بررسی وجود مقاله به فایل گزارش cancels.tombstone در pathdb مراجعه می‌کند: نشانه‌ای که به عنوان لغوشده ثبت شده باشد بدون فراخوانی "SMretrieve" به عنوان از بین‌رفته گزارش می‌شود، و به نشانه‌ای که در سنگ‌قبر وجود ندارد اعتماد می‌شود که هنوز وجود دارد (با صرف‌نظر از فراخوانی سیستمی) برای روش‌های ذخیره‌سازی که خودمنقضی‌شونده نیستند. بک‌اندهای خودمنقضی‌شونده (CNFS) همچنان از طریق "SMretrieve" عبور می‌کنند زیرا چرخش بافر حلقوی سنگ‌قبر را دور می‌زند. سنگ‌قبر به صورت تنبل در اولین استفاده به ازای هر اتصال بارگذاری شده و با "stat" در هر فراخوانی تازه‌سازی می‌شود؛ مجموعه هش تجزیه‌شده تنها زمانی بازسازی می‌شود که mtime یا اندازه فایل تغییر کند. اجرای stat روی همان مسیر در حافظه پنهان dentry مقیم است و بسیار ارزان‌تر از فراخوانی‌های سیستمی به ازای هر مقاله است که مسیر سریع از آن‌ها صرف‌نظر می‌کند، بنابراین لغوهای ثبت‌شده توسط فرآیندهای دیگر در بررسی وجود بعدی برای اتصالات طولانی‌مدت قابل مشاهده می‌شوند.

هر اتصال nnrpd یک کپی مستقل از مجموعه هش تجزیه‌شده را نگه می‌دارد که تقریباً ۵۰ بایت به ازای هر لغو هزینه دارد؛ سایت‌هایی با حجم بسیار بالای لغو بین اجراهای expire و خوانندگان همزمان بسیار باید حافظه را متناسب با آن اندازه بگیرند. از دست رفتن داده‌ها نسبت به مسیر بدون قید و شرط "SMretrieve" به رویدادهای خارج از باند محدود می‌شود که سنگ‌قبر نمی‌تواند ببیند (حذف‌های دستی در فایل‌سیستم که sm -r را دور می‌زنند، خرابی فایل‌سیستم)؛ لغوهای آغازشده توسط مدیر با sm -r و لغوهای innd ردیابی می‌شوند.

مهم: در بک‌اندهای غیرخودمنقضی‌شونده، مسیر سریع عدم وجود در سنگ‌قبر را به عنوان اثباتی بر وجود هنوز مقاله روی دیسک، بدون اعتبارسنجی در نظر می‌گیرد. مدیران باید مقالات را از طریق sm -r (که لغو را در سنگ‌قبر ثبت می‌کند) حذف کنند، نه با "rm" مستقیم روی مخزن، وگرنه به خوانندگان گفته می‌شود که مقاله حذف‌شده هنوز وجود دارد تا زمانی که expireover بعدی نمای کلی را تطبیق دهد.

توجه داشته باشید که مسیر سریع به expiretombstone نیز وابسته است؛ هر دو باید true باشند تا اعمال شود. شمارنده "artcheck" در nnrpdoverstats تنها مسیر کند "SMretrieve" را منعکس می‌کند، بنابراین فیلد syslog زمانی که مسیر سریع بخش اعظم کار را انجام می‌دهد کوچک‌تر به نظر می‌رسد.

همچنین ممکن است بخواهید پارامتر groupexactcount در readers.conf(5) را ببینید که محاسبه تعداد تخمینی مقاله بازگردانده‌شده در دستورات NNTP (مانند GROUP، LIST COUNTS، LISTGROUP) را کنترل می‌کند.

هنگامی که nnrpd(8) از innd(8) ایجاد (spawn) می‌شود، این فلگ‌ها به عنوان آرگومان به پردازش nnrpd ارسال می‌شوند. این تنظیم بر نمونه‌هایی از nnrpd که در حالت دیمن آغاز می‌شوند، یا نمونه‌هایی که از طریق یک پردازش شنونده دیگر مانند inetd(8) یا xinetd(8) آغاز می‌شوند تأثیری ندارد. نقل‌قول شل و کاراکترهای ویژه پشتیبانی نمی‌شوند. این یک مقدار رشته‌ای است و پیش‌فرض آن تنظیم‌نشده است.
اگر روی مقداری غیر از "0" تنظیم شود، در صورتی که میانگین بار سیستم بالاتر از این مقدار باشد اتصالات به nnrpd رد خواهند شد. مقدار پیش‌فرض "16" است.
به‌طور معمول، innd(8) برای تمامی اتصالات ورودی از میزبان‌هایی که در incoming.conf فهرست نشده‌اند یک نسخه فورک از nnrpd(8) ایجاد می‌کند. اگر این پارامتر روی true تنظیم شود، آن اتصالات در عوض با کد خطای 502 رد خواهند شد. این باید برای یک سرور فقط-ترانزیت که از خوانندگان پشتیبانی نمی‌کند، یا اگر nnrpd در حالت دیمن اجرا می‌شود یا از inetd راه‌اندازی می‌شود، روی true تنظیم گردد. این یک مقدار بولی است و پیش‌فرض false است.
اینکه آیا به خوانندگان اجازه اتصال داده شود حتی اگر سرور متوقف (paused) یا مهار (throttled) شده باشد. این تنها در صورتی کاربرد دارد که nnrpd(8) از innd(8) ایجاد شده باشد نه اینکه از inetd یا در حالت دیمن اجرا شود. این یک مقدار بولی است و پیش‌فرض false است.
اینکه آیا سیستم ردیابی رفتار کلاینت فعال شود یا خیر. اطلاعات ردیابی‌شده در pathlog/tracklogs/log-ID ثبت می‌شوند، که در آن ID توسط PID برنامه nnrpd و زمان راه‌اندازی تعیین می‌شود. در حال حاضر اطلاعات ثبت‌شده شامل اتصال اولیه و ارسال است؛ تنها اطلاعات کلاینت‌های فهرست‌شده در nnrpd.track ثبت می‌شود. علاوه بر این، هر مقاله ارسال‌شده در pathlog/trackposts/track.message-id ذخیره خواهد شد، که در آن message-id شناسه پیام پست است. این یک مقدار بولی است و پیش‌فرض false است.
اینکه آیا تلاش شود مقالات نمای کلی tradindexed با ()mmap نگاشت شوند یا خیر. تنظیم این روی true در بیشتر سیستم‌ها عملکرد بهتری خواهد داشت، اما برخی سیستم‌ها با ()mmap مشکل دارند. اگر روی false تنظیم شود، نمای کلی قبل از ارسال به خوانندگان در حافظه خوانده می‌شود. این یک مقدار بولی است و پیش‌فرض true است.

برنامه INN دارای پشتیبانی اختیاری برای تولید خودکار اطلاعات کلیدواژه از متن بدنه مقاله و قرار دادن آن اطلاعات در نمای کلی برای استفاده کلاینت‌هایی است که می‌دانند چگونه آن را جستجو کنند (دستورات HDR، OVER و XPAT). پارامترهای زیر آن ویژگی را کنترل می‌کنند که باید آزمایشی در نظر گرفته شود. نشانه‌گذاری متنی بسیار ساده آن تنها روی مقالات متنی ساده ASCII کار می‌کند، و کاملاً فاقد درک هر چیزی غیر از زبان انگلیسی است. مقالات کدگذاری‌شده در Base64 یا Quoted-Printable، دارای ساختار MIME، یا دورتر از انگلیسی در فیلد سرایند Keywords تولیدشده دارای داده‌های بی‌معنی خواهند بود.

اگر فید بزرگی دریافت می‌کنید، این ویژگی ممکن است بسیار کند باشد و احتمالاً برای خواننده معمولی خبر مفید نخواهد بود؛ فعال کردن این ویژگی توصیه نمی‌شود مگر اینکه قصد خاصی برای بهره‌برداری از آن داشته باشید.

اینکه آیا پشتیبانی از تولید کلیدواژه باید فعال شود یا خیر. این یک مقدار بولی است و پیش‌فرض false است.

اگر مقاله‌ای از قبل شامل فیلد سرایند Keywords باشد، هیچ تولید کلیدواژه‌ای انجام نمی‌شود و فیلد سرایند Keywords اصلی دست‌نخورده باقی می‌ماند.

برای استفاده از این ویژگی، کتابخانه regex باید در دسترس باشد و INN با فلگ --enable-keywords پیکربندی شده باشد. در غیر این صورت، هیچ کلیدواژه‌ای تولید نخواهد شد، حتی اگر این مقدار بولی روی true تنظیم شده باشد. همچنین باید فیلد سرایند Keywords را با extraoverviewadvertised یا extraoverviewhidden به نمای کلی اضافه کنید.

برای مقالات بزرگ‌تر از این مقدار بر حسب بایت، کلیدواژه تولید نخواهد شد (زیرا انجام این کار زمان بسیار زیادی می‌برد). مقدار پیش‌فرض "100000" (تقریباً ۱۰۰ کیلوبایت) است.
حداکثر تعداد بایت‌های اختصاص‌داده‌شده برای داده‌های کلیدواژه. اگر تعداد کلیدواژه‌ها بیشتر از آن باشد که در این تعداد بایت هنگام جداسازی با کاما جا شود، بقیه کنار گذاشته می‌شوند. مقدار پیش‌فرض "512" است.
حداکثر تعداد کلیدواژه‌هایی که برای یک مقاله تولید خواهند شد. (کد تولید کلیدواژه تلاش خواهد کرد کلمات زائد در انگلیسی را کنار بگذارد، بنابراین تعداد کلیدواژه‌هایی که واقعاً در نمای کلی نوشته می‌شوند معمولاً حتی اگر حداکثر تعداد کلیدواژه‌ها یافت شود، کمتر از این خواهد بود.) مقدار پیش‌فرض "250" است.

این پارامترها تنها توسط nnrpd(8)، inews(1) و سایر برنامه‌هایی که ارسال‌ها را می‌پذیرند یا تولید می‌کنند استفاده می‌شوند. چند مجموعه ویژه از تنظیمات وجود دارند که پس از فهرست الفبایی اولیه به‌طور جداگانه تقسیم‌بندی شده‌اند.

اینکه آیا یک فیلد سرایند Injection-Date به تمامی ارسال‌های محلی اضافه شود یا خیر. این یک مقدار بولی است و پیش‌فرض true است.

توجه داشته باشید که هیچ فیلد سرایند Injection-Date به ارسال‌های محلی که از قبل شامل هر دو فیلد سرایند Message-ID و Date هستند افزوده نخواهد شد. این کار در انطباق با استانداردها انجام می‌شود تا احتمال ایجاد حلقه در پل ارتباطی ایمیل به حداقل برسد و اطمینان حاصل شود که در صورت تزریق چندگانه یک مقاله یکسان به عامل‌های تزریق متفاوت، مقاله تازه تزریق‌شده به عنوان یک مقاله جدید و جداگانه در نظر گرفته نشود.

اینکه آیا ویژگی posting-account به بدنه فیلد سرایند Injection-Info در تمامی ارسال‌های محلی اضافه شود و نام کاربری اختصاص‌یافته به کاربر در زمان اتصال یا پس از احراز هویت را مشخص کند یا خیر. این یک مقدار بولی است و پیش‌فرض false است. هیچ پشتیبانی درونی برای پنهان‌سازی (obfuscate) این مقدار وجود ندارد. در صورت تمایل، این کار باید با یک فیلتر Perl نوشته‌شده توسط کاربر انجام شود.
اینکه آیا یک صفت posting-host به بدنه فیلد سرایند Injection-Info در تمامی ارسال‌های محلی افزوده شود تا نام کامل دامنه (FQDN) (در صورت مشخص بودن، با جستجوی معکوس آدرس IP کلاینت) و آدرس IP سیستمی را که ارسال از آن دریافت شده است مشخص کند یا خیر. این یک مقدار بولی است و پیش‌فرض true است. توجه داشته باشید که INN یا این صفت را اضافه نمی‌کند یا نام (در صورت مشخص بودن) و آدرس IP کلاینت را اضافه می‌کند. هیچ پشتیبانی درونی برای مبهم‌سازی نام کلاینت وجود ندارد. در صورت تمایل، این کار باید با یک فیلتر Perl نوشته‌شده توسط کاربر انجام شود.

هنگامی که این پارامتر روی true تنظیم شود، یک FQDN (به دست آمده از جستجوی معکوس آدرس IP کلاینت یا در صورت ناشناخته بودن، خود آدرس IP) کلاینت نیز پس از شناسه تشخیصی "!.POSTED" به بدنه فیلد سرایند Path اضافه می‌شود.

اینکه آیا نسبت متن جدید به متن نقل‌قول‌شده در ارسال‌های محلی بررسی شود و در صورتی که این نسبت زیر ۵۰٪ باشد ارسال‌ها رد شوند یا خیر. متن گنجانده‌شده با جستجوی خطوطی که با ">"، "|" یا ":" آغاز می‌شوند شناسایی می‌گردد. این یک مقدار بولی است و پیش‌فرض false است.
مقدار صفت mail-complaints-to در فیلد سرایند Injection-Info که به تمام ارسال‌های محلی اضافه می‌شود. پیش‌فرض، آدرس ایمیل newsmaster است. (اگر newsmaster که در زمان ساخت انتخاب می‌شود و پیش‌فرض آن "usenet" است حاوی "@" نباشد، آدرس شامل newsmaster، یک "@" و مقدار fromhost خواهد بود.)
حاوی دامنه‌ای است که برای ساخت آدرس‌های ایمیل استفاده می‌شود. آدرس مدیر محلی خبر به صورت <user>@fromhost داده خواهد شد، که در آن <user> کاربر newsmaster تنظیم‌شده در زمان کامپایل است (به‌طور پیش‌فرض "usenet"). این تنظیم همچنین توسط mailpost(8) برای واجد شرایط کردن کامل آدرس‌ها و توسط inews(1) برای تولید فیلد سرایند Sender (و در صورت مفقود بودن، فیلد سرایند From) استفاده می‌شود. مقدار متغیر محیطی FROMHOST در صورت تنظیم، این مقدار را لغو می‌کند. پیش‌فرض، نام کامل دامنه (FQDN) میزبان محلی است.
حداکثر اندازه مقاله (بر حسب بایت) برای مقالاتی که به صورت محلی ارسال می‌شوند. مقالات بزرگ‌تر از این مقدار رد خواهند شد. مقدار "0" هر اندازه‌ای از مقاله را مجاز می‌داند، اما توجه داشته باشید که اگر از حافظه سیستم فراتر رود، nnrpd و innd کرش خواهند کرد. همچنین maxartsize را ببینید که برای تمام مقالات از جمله مقالاتی که به صورت محلی ارسال می‌شوند اعمال می‌گردد. مقدار پیش‌فرض "1000000" (تقریباً ۱ مگابایت) است.
آدرسی که باید ارسال‌های مربوط به گروه‌های نیازمند تأیید (moderated) به آن فرستاده شود. این تنها در صورتی استفاده می‌شود که فایل moderators وجود نداشته باشد، یا اگر گروه بررسی‌شده‌ای که مقاله‌ای در آن ارسال شده با هیچ مدخلی در آن فایل مطابقت نداشته باشد، و قالبی مشابه یک مدخل در فایل moderators دارد. در بیشتر موارد، "%s@moderators.isc.org" مقدار مناسبی برای این پارامتر است ("%s" به شکلی از نام گروه خبری بسط می‌یابد). برای جزئیات بیشتر درباره نحو، moderators(5) را ببینید. پیش‌فرض تنظیم‌نشده است. اگر این پارامتر تنظیم نشده باشد و مقاله‌ای در یک گروه تحت نظارت ارسال شود که مدخل منطبقی در فایل moderators ندارد، ارسال با خطا رد خواهد شد.
اینکه آیا یک فیلد سرایند Sender بر اساس احراز هویت خواننده تولید شود یا خیر. اگر این پارامتر تنظیم شود، یک فیلد سرایند Sender حاوی هویت اختصاص‌یافته توسط readers.conf به ارسال‌های محلی اضافه خواهد شد. اگر هویت اختصاص‌یافته شامل "@" نباشد، نام میزبان خواننده استفاده می‌شود. اگر این پارامتر تنظیم شود اما هویتی اختصاص داده نشود، فیلد سرایند Sender از تمام ارسال‌ها حذف خواهد شد حتی اگر ارسال‌کننده آن را درج کرده باشد. این یک مقدار بولی است و پیش‌فرض false است.
در صورت تنظیم، nnrpd(8) و rnews(1) تمامی مقالات ارسال‌شده محلی را به جای تلاش برای تزریق محلی به میزبان مشخص‌شده تحویل می‌دهند. همچنین nnrpdpostport را ببینید. اگر xrefslave برابر با true باشد این پارامتر همیشه باید تنظیم شود. مقدار پیش‌فرض تنظیم‌نشده است.
پورت روی سرور راه دور برای اتصال جهت ارسال، هنگامی که nnrpdposthost استفاده می‌شود. مقدار پیش‌فرض "119" است.
آنچه باید در بدنه فیلد سرایند Organization قرار گیرد اگر توسط ارسال‌کننده خالی گذاشته شده باشد. مقدار متغیر محیطی ORGANIZATION در صورت تنظیم، این مقدار را لغو می‌کند. پیش‌فرض تنظیم‌نشده است، که به INN می‌گوید فیلد سرایند Organization را درج نکند.
اگر true باشد، nnrpd(8) مقالات جدید را به جای تلاش برای ارسال آن‌ها به innd(8) در صف مخزن قرار می‌دهد (spool می‌کند). اگر false باشد، nnrpd مقالات را تنها در صورتی در مخزن صف‌بندی می‌کند که در تلاش برای ارسال آن‌ها به innd با خطا مواجه شود. تنظیم این روی true در صورتی می‌تواند مفید باشد که nnrpd باید هر چه سریع‌تر به کلاینت پاسخ دهد؛ با این حال، هنگام تنظیم، مقالات برای خوانندگان ظاهر نخواهند شد تا زمانی که به innd تحویل داده شوند. برنامه nnrpd این کار را انجام نخواهد داد؛ دستور "rnews -U" باید به صورت دوره‌ای اجرا شود تا مقالات صف‌بندی‌شده را گرفته و ارسال کند. این یک مقدار بولی است و پیش‌فرض false است.
اینکه آیا فیلدهای سرایند To، Cc و Bcc از تمام ارسال‌های محلی از طریق nnrpd(8) حذف شوند یا خیر. هدف اصلی این تنظیم جلوگیری از سوءاستفاده از سرور خبری با ارسال به یک گروه تحت نظارت و گنجاندن فیلدهای سرایند To یا Cc در پست است تا سرور خبری مقاله را به آدرس‌های دلخواه ارسال کند. اکنون INN به روش‌های دیگری در برابر این سوءاستفاده محافظت می‌کند، مشروط بر اینکه mta روی دستوری تنظیم شده باشد که شامل "%s" بوده و به آن احترام بگذارد، بنابراین این تنظیم عموماً دیگر مورد نیاز نیست. این یک مقدار بولی است و پیش‌فرض false است.

برنامه nnrpd(8) دارای پشتیبانی از کنترل ارسال‌کنندگان پرحجم از طریق یک الگوریتم پس‌نشینی نمایی (exponential backoff) است، همان‌طور که توسط پارامترهای زیر پیکربندی شده است.

پس‌نشینی نمایی ارسال به این صورت کار می‌کند: کلاینت‌های خبری بر اساس آدرس IP (یا نام کاربری، backoffauth در زیر را ببینید) نمایه می‌شوند. هر بار که پستی از یک آدرس IP دریافت می‌شود، زمان ارسال ذخیره می‌شود (به همراه زمان خواب قبلی، به زیر مراجعه کنید). پس از تعداد قابل پیکربندی از ارسال‌ها در یک دوره زمانی قابل پیکربندی، nnrpd(8) شروع به خوابیدن برای دوره‌های زمانی فزاینده قبل از ارسال واقعی هر چیزی می‌کند (بنابراین پس‌نشینی ارسال فعال می‌شود). ارسال‌ها همچنان پذیرفته می‌شوند، اما با نرخی که به طور فزاینده کاهش می‌یابد.

پس از فعال شدن پس‌نشینی، طول مدت خواب بر اساس اختلاف زمانی بین آخرین ارسال و ارسال فعلی محاسبه می‌شود. اگر این اختلاف کمتر از backoffpostfast باشد، زمان خواب جدید برابر خواهد بود با ۱ + (زمان خواب قبلی * backoffk). اگر این اختلاف کمتر از backoffpostslow اما بیشتر از backoffpostfast باشد، زمان خواب جدید برابر با زمان خواب قبلی خواهد بود. اگر این اختلاف بیشتر از backoffpostslow باشد، زمان خواب جدید صفر است و پس‌نشینی ارسال برای این ارسال‌کننده غیرفعال می‌شود. (توجه داشته باشید که این بدان معنا نیست که پس‌نشینی ارسال نمی‌تواند بعداً در نشست مجدداً فعال شود.)

پس‌نشینی نمایی ارسال فعال نخواهد شد مگر اینکه backoffdb تنظیم شده باشد و backoffpostfast و backoffpostslow روی مقادیری غیر از مقادیر پیش‌فرض خود تنظیم گردند.

در اینجا پارامترهایی آمده‌اند که پس‌نشینی نمایی ارسال را کنترل می‌کنند:

اینکه آیا پس‌نشینی‌های ارسال به جای آدرس IP مبدأ بر اساس کاربر نمایه شوند یا خیر. شما باید از احراز هویت در nnrpd(8) استفاده کنید تا مقدار true معنایی داشته باشد. این یک مقدار بولی است و پیش‌فرض false است.
مسیر به دایرکتوری قابل نوشتن توسط کاربر news که حاوی پایگاه‌داده پس‌نشینی خواهد بود. هیچ پیش‌فرضی برای این پارامتر وجود ندارد؛ برای فعال کردن پس‌نشینی نمایی باید مسیری به یک دایرکتوری قابل ایجاد یا قابل نوشتن ارائه دهید.
مقداری که زمان خواب قبلی در آن ضرب می‌شود اگر کاربر همچنان خیلی سریع ارسال کند. مقدار "2" زمان خواب را به ازای هر ارسال بیش از حد دو برابر می‌کند. مقدار پیش‌فرض "1" است.
ارسال‌هایی از همان هویت که در مدت زمانی کمتر از این مقدار (بر حسب ثانیه) می‌رسند، باعث افزایش زمان خواب در الگوریتم پس‌نشینی خواهند شد. مقدار پیش‌فرض "0" است.
ارسال‌هایی از همان هویت که در مدت زمانی بیشتر از این مقدار (بر حسب ثانیه) می‌رسند، الگوریتم پس‌نشینی را بازنشانی خواهند کرد. روش دیگر برای نگاه کردن به این ثابت این است که متوجه شویم ارسال‌کنندگان مجاز به تولید حداکثر 86400/backoffpostslow ارسال در روز خواهند بود. مقدار پیش‌فرض "1" است.
این تعداد ارسال قبل از فعال شدن الگوریتم پس‌نشینی مجاز است. مقدار پیش‌فرض "10000" است.

در اینجا پارامترهای مورد استفاده توسط nnrpd(8) برای ارائه پشتیبانی TLS/SSL آمده‌اند.

پارامترهای مربوط به گواهی‌ها عبارتند از:

مسیر به فایلی حاوی گواهی‌های ریشه مرجع صدور گواهی (CA)، که برای ارائه زنجیره اعتماد به کلاینت TLS استفاده می‌شود. این پارامتر تنها در صورتی استفاده می‌شود که nnrpd با پشتیبانی TLS/SSL ساخته شده باشد. مقدار پیش‌فرض یک رشته خالی است.
مسیر به دایرکتوری حاوی گواهی‌های ریشه مرجع صدور گواهی. هر فایل در این دایرکتوری باید حاوی یک گواهی CA باشد، و نام فایل باید مقدار درهم‌سازی (هش) نام موضوع CA باشد. برای اطلاعات بیشتر به مستندات OpenSSL مراجعه کنید. این پارامتر تنها در صورتی استفاده می‌شود که nnrpd با پشتیبانی TLS/SSL ساخته شده باشد. مقدار پیش‌فرض pathetc است.
مسیر به فایلی حاوی گواهی سرور جهت ارائه به کلاینت‌های TLS. این پارامتر تنها در صورتی استفاده می‌شود که nnrpd با پشتیبانی TLS/SSL ساخته شده باشد. مقدار پیش‌فرض pathetc/cert.pem است.

اگر می‌خواهید از یک زنجیره کامل گواهی استفاده کنید، می‌توانید مستقیماً آن را در tlscertfile قرار دهید (مانند دستورالعمل SSLCertificateFile در آپاچی). متناوباً، می‌توانید یک گواهی منفرد را در tlscertfile قرار داده و از tlscafile برای گواهی‌های اضافی مورد نیاز جهت تکمیل زنجیره، مانند یک گواهی ریشه مرجع جداگانه استفاده کنید.

به‌طور ملموس‌تر، هنگام استفاده از گواهی‌های Let's Encrypt، فایل‌های Certbot را می‌توان به صورت زیر نصب کرد:

tlscapath:      /etc/letsencrypt/live/news.server.com
tlscertfile:    /etc/letsencrypt/live/news.server.com/fullchain.pem
tlskeyfile:     /etc/letsencrypt/live/news.server.com/privkey.pem

یا:

tlscapath:      /etc/letsencrypt/live/news.server.com
tlscafile:      /etc/letsencrypt/live/news.server.com/chain.pem
tlscertfile:    /etc/letsencrypt/live/news.server.com/cert.pem
tlskeyfile:     /etc/letsencrypt/live/news.server.com/privkey.pem

اطمینان حاصل کنید که مجوزهای دسترسی به درستی تنظیم شده باشند تا کاربر news یا گروه news بتواند این دایرکتوری‌ها و فایل‌ها را بخواند (به‌طور معمول، باید به /etc/letsencrypt/live/news.server.com و /etc/letsencrypt/archive/news.server.com که کلیدهای واقعی در آنجا قرار دارند دسترسی داشته باشد، و کلید خصوصی نباید برای همه کاربران قابل خواندن باشد).

اگر ترجیح می‌دهید به فایل‌های خارج از دایرکتوری Let's Encrypt اشاره کنید، می‌توانید یک قلاب پس از تمدید (post-renewal hook) برای Let's Encrypt اضافه کنید تا فایل‌های تولیدشده را در مکان دیگری کپی کرده و دسترسی‌های مورد انتظار را به آن‌ها بدهد.

مسیر به فایلی حاوی کلید رمزنگاری برای گواهی سرور نام‌گذاری‌شده در tlscertfile. این ممکن است همان tlscertfile باشد اگر هنگام ایجاد گواهی، کلید را در همان فایل قرار داده باشید (برای مثال اگر نام فایل یکسانی به هر دو گزینه -out و -keyout در "openssl req" داده باشید). این پارامتر تنها در صورتی استفاده می‌شود که nnrpd با پشتیبانی TLS/SSL ساخته شده باشد. مقدار پیش‌فرض pathetc/key.pem است.

این فایل باید تنها توسط کاربر news قابل خواندن باشد وگرنه nnrpd از استفاده از آن خودداری خواهد کرد.

در نهایت، در اینجا پارامترهایی آمده‌اند که می‌توانند برای سخت‌گیرانه‌تر کردن سطح امنیت ارائه‌شده توسط TLS/SSL در صورتی که حملات جدید قابل بهره‌برداری در NNTP روی پروتکل TLS یا برخی مجموعه‌های رمزنگاری پشتیبانی‌شده کشف شوند، استفاده شوند:

رشته‌ای که مجموعه‌های رمزنگاری (cipher suites) مورد پشتیبانی OpenSSL را برای TLS 1.2 و پایین‌تر توصیف می‌کند. برای جزئیات به مستندات دستور ciphers(1) در OpenSSL مراجعه کنید. پیش‌فرض تنظیم‌نشده است، که از فهرست مجموعه رمزنگاری پیش‌فرض OpenSSL استفاده می‌کند.
رشته‌ای که مجموعه‌های رمزنگاری مورد پشتیبانی OpenSSL را برای TLS 1.3 توصیف می‌کند. برای جزئیات به مستندات دستور ciphers(1) در OpenSSL مراجعه کنید. پیش‌فرض تنظیم‌نشده است، که از فهرست مجموعه رمزنگاری پیش‌فرض OpenSSL استفاده می‌کند.

توجه داشته باشید که یک پارامتر پیکربندی مجموعه رمزنگاری جداگانه برای TLS 1.3 مورد نیاز است زیرا مجموعه‌های رمزنگاری TLS 1.3 با TLS 1.2 سازگار نیستند و بالعکس. برای جلوگیری از مشکلاتی که در آن پیکربندی قدیمی مجموعه رمزنگاری TLS 1.2 در پارامتر tlsciphers به‌طور سهوی تمام مجموعه‌های رمزنگاری TLS 1.3 را غیرفعال کند، پیکربندی inn.conf جدا شده است.

اینکه آیا پشتیبانی از فشرده‌سازی در سطح TLS/SSL فعال یا غیرفعال شود، در صورتی که پروتکل مذاکره‌شده از آن پشتیبانی کند (به‌ویژه TLS 1.3 دیگر از آن پشتیبانی نمی‌کند). این یک مقدار بولی است و پیش‌فرض false است، به این معنی که فشرده‌سازی غیرفعال است تا از بهترین شیوه‌های جاری برای استفاده امن از TLS در پروتکل‌های کاربردی پیروی شود (RFC 8143 را برای NNTP ببینید).

توجه داشته باشید که فعال کردن فشرده‌سازی سطح TLS/SSL تنها در صورتی امکان‌پذیر خواهد بود که کتابخانه OpenSSL که INN با آن ساخته شده است از آن ویژگی پشتیبانی کند.

نام منحنی بیضوی مورد استفاده برای تبادل کلید زودگذر (ephemeral). برای مشاهده فهرست منحنی‌های پشتیبانی‌شده توسط OpenSSL، از دستور "openssl ecparam -list_curves" استفاده کنید.

پیش‌فرض تنظیم‌نشده است، به این معنی که یک منحنی مناسب به‌طور خودکار انتخاب می‌شود (اگر نسخه OpenSSL شما حداقل 1.0.2 باشد یا از LibreSSL استفاده می‌کنید) یا از منحنی NIST P-256 استفاده می‌شود.

این گزینه تنها در صورتی مؤثر است که نسخه OpenSSL شما دارای پشتیبانی ECDH باشد.

اینکه آیا به کلاینت یا سرور اجازه داده شود مجموعه رمزنگاری ترجیحی، الگوریتم امضا یا منحنی بیضوی مورد استفاده برای یک اتصال ورودی را تعیین کند. این یک مقدار بولی است و پیش‌فرض true است، به این معنی که سرور بر اساس ترجیحات خود انتخاب خواهد کرد.
فهرست نسخه‌های پروتکل TLS/SSL برای پشتیبانی. پروتکل‌های معتبر عبارتند از SSLv2، SSLv3، TLSv1، TLSv1.1، TLSv1.2 و TLSv1.3. مقدار پیش‌فرض تنها اجازه دادن به پروتکل‌های امن TLS است: 
tlsprotocols: [ TLSv1.2 TLSv1.3 ]

توجه داشته باشید که پروتکل‌های فهرست‌شده تنها در صورتی فعال خواهند شد که کتابخانه OpenSSL که INN با آن ساخته شده است از آن‌ها پشتیبانی کند. در صورتی که OpenSSL از پروتکل‌های جدیدتر از TLSv1.3 پشتیبانی کند، آن‌ها به‌طور خودکار فعال خواهند شد (که در هر حال از نظر امنیتی مشکلی ندارد، زیرا فرض می‌شود پروتکل‌های جدیدتر امن‌تر هستند).

پروتکل "SSLv2" رسماً توسط RFC 6176 در سال ۲۰۱۱، "SSLv3" توسط RFC 7568 در سال ۲۰۱۵، و "TLSv1.0" و "TLSv1.1" توسط RFC 8996 در سال ۲۰۲۱ منسوخ اعلام شدند.

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

اینکه آیا innwatch(8) از rc.news آغاز شود یا خیر. این یک مقدار بولی است و پیش‌فرض true است.
فضای آزاد در pathoutgoing، بر حسب واحدهای خروجی inndf(8) (معمولاً کیلوبایت)، که در آن innd(8) توسط innwatch(8) مهار (throttle) خواهد شد، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "4000" است.
فضای آزاد در pathdb، بر حسب واحدهای خروجی inndf(8) (معمولاً کیلوبایت)، که در آن innd(8) توسط innwatch(8) مهار خواهد شد، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "25000" است.
میانگین بار ضربدر ۱۰۰ که در آن innd(8) توسط innwatch(8) مجدداً راه‌اندازی خواهد شد (لغو مکث یا مهار قبلی)، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "1000" است (یعنی میانگین بار 10.00).
میانگین بار ضربدر ۱۰۰ که در آن innd(8) توسط innwatch(8) مهار خواهد شد، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "2000" است (یعنی میانگین بار 20.00).
میانگین بار ضربدر ۱۰۰ که در آن innd(8) توسط innwatch(8) متوقف (pause) خواهد شد، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "1500" است (یعنی میانگین بار 15.00).
چه مدت (بر حسب ثانیه) innwatch(8) بین هر بررسی INN به خواب برود. مقدار پیش‌فرض "600" است.
آی‌نودهای (inodes) آزاد در patharticles که در آن innd(8) توسط innwatch(8) مهار خواهد شد، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "200" است.
فضای آزاد در patharticles و pathoverview، بر حسب واحدهای خروجی inndf(8) (معمولاً کیلوبایت)، که در آن innd(8) توسط innwatch(8) مهار خواهد شد، با فرض یک innwatch.ctl پیش‌فرض. مقدار پیش‌فرض "25000" است.

این پارامترها مشخص می‌کنند که INN چه اطلاعاتی را در گزارش‌ها (لاگ‌ها) ثبت کند.

اینکه آیا هنگام آغاز innd(8)، برنامه cnfsstat(8) نیز آغاز شود یا خیر. برنامه cnfsstat وضعیت تمام بافرهای چرخشی CNFS را به صورت دوره‌ای در syslog ثبت می‌کند (بازه زمانی پیش‌فرض برای "cnfsstat -l" در حال حاضر ۶۰۰ ثانیه است). این یک مقدار بولی است و پیش‌فرض false است.
اینکه آیا innd باید گزارش وضعیت را به صورت فایل HTML بنویسد یا متن ساده. فایل وضعیت HTML در pathhttp/inn_status.html قرار می‌گیرد، در حالی که فایل وضعیت متنی ساده در pathlog/inn.status نوشته می‌شود. این یک مقدار بولی است و پیش‌فرض true است (فایل وضعیت HTML نوشته می‌شود). همچنین پارامتر status را ببینید.
چه تعداد مقاله در یک کانال ورودی پردازش شود قبل از اینکه فعالیت آن ثبت شود. مقدار پیش‌فرض "200" است.
اینکه آیا اندازه مقالات پذیرفته‌شده (بر حسب بایت) باید در فایل گزارش مقاله نوشته شود یا خیر. این برای آمارهای نرخ جریان مفید بوده و توصیه می‌شود. این یک مقدار بولی است و پیش‌فرض true است.
این مقدار را روی true تنظیم کنید تا دستورات "ctlinnd cancel" در syslog ثبت شوند. این یک مقدار بولی است و پیش‌فرض false است.
چه تعداد گزارش قدیمی توسط scanlogs(8) نگهداری شود. برنامه scanlogs(8) عموماً توسط news.daily(8) اجرا می‌شود و کپی‌های فشرده‌شده از این تعداد روز لاگ‌های قدیمی را بایگانی خواهد کرد. مقدار پیش‌فرض "3" است.
اینکه آیا نام تأییدشده میزبان فیددهنده راه دور باید به جای آخرین مدخل در بدنه فیلد سرایند Path، در لاگ مقاله برای مقالات ورودی ثبت شود یا خیر. تنها دلیلی که ممکن است این مقدار روی false تنظیم شود ناشی از برخی تداخل‌ها با فلگ‌های newsfeeds است؛ برای اطلاعات بیشتر newsfeeds(5) را ببینید. این یک مقدار بولی است و پیش‌فرض true است.
اینکه آیا نام سایت‌هایی که مقالات پذیرفته‌شده به آن‌ها ارسال خواهند شد در فایل لاگ مقاله درج شود یا خیر. این برای اشکال‌زدایی و آمار مفید است. این یک مقدار بولی است و پیش‌فرض true است.
اینکه آیا innd باید نسخه کوتاه‌شده‌ای از گزارش وضعیت خود را هر status ثانیه در syslog بنویسد یا خیر. این یک مقدار بولی است و پیش‌فرض true است. اگر روی true تنظیم شد، پارامتر status را برای جزئیات بیشتر درباره نحوه فعال‌سازی گزارش‌گیری وضعیت ببینید.
اینکه آیا innd باید خطی در فایل لاگ news برای گزارش گروه‌های خبری ناخواسته (یعنی گروه‌های خبری که به‌صورت محلی توسط سرور خبری نگهداری نمی‌شوند) اضافه کند یا خیر. این یک مقدار بولی است و پیش‌فرض true است. ممکن است زمانی که wanttrash روی true تنظیم شده است، تنظیم آن روی false مفید باشد.
اینکه آیا آمارهای نمای کلی nnrpd باید از طریق syslog ثبت شوند یا خیر. این می‌تواند برای سنجش عملکرد نمای کلی مفید باشد. این یک مقدار بولی است و پیش‌فرض true است.
اینکه آیا نشانه API ذخیره‌سازی برای مقالات پذیرفته‌شده (مورد استفاده توسط nntplink) در لاگ مقاله قرار گیرد یا خیر. این یک مقدار بولی است و پیش‌فرض false است.
آمار تاریخچه برای تجزیه و تحلیل با contrib/stathist در کجا نوشته شود؛ این را می‌توان با ctlinnd(8) در حالی که innd در حال اجرا است تغییر داد. ثبت گزارش رخ نمی‌دهد مگر اینکه مسیری ارائه شود، و هیچ مقدار پیش‌فرضی وجود ندارد.
هر چند وقت یک‌بار (بر حسب ثانیه) innd(8) باید یک گزارش وضعیت بنویسد. گزارش در pathhttp/inn_status.html یا pathlog/inn.status بسته به مقدار htmlstatus نوشته می‌شود. اگر این مقدار روی "0" یا "false" تنظیم شود، گزارش‌گیری وضعیت غیرفعال می‌گردد. مقدار پیش‌فرض "600" است (یعنی گزارش‌ها هر ۱۰ دقیقه نوشته می‌شوند).
هر چند وقت یک‌بار (بر حسب ثانیه) innd(8) باید زمان‌بندی‌های عملکرد را به syslog گزارش دهد. اگر روی "0" تنظیم شود، زمان‌بندی عملکرد غیرفعال می‌گردد. فعال کردن این به شدت توصیه می‌شود، و innreport(8) می‌تواند خلاصه مناسبی از زمان‌بندی‌ها تولید کند. اگر روی "0" تنظیم شود، زمان‌بندی‌های عملکرد در nnrpd(8) نیز غیرفعال می‌شوند، اگرچه nnrpd همیشه هنگام خروج آمارها را گزارش می‌دهد و بنابراین هر مقدار غیرصفر برای آن معادل است. مقدار پیش‌فرض "600" است (یعنی زمان‌بندی‌های عملکرد هر ۱۰ دقیقه گزارش می‌شوند).

پارامترهای زیر می‌توانند برای تنظیم دقیق عملکرد سطح پایین INN تغییر داده شوند. به طور کلی، شما نباید نیازی به تغییر هیچ‌یک از آن‌ها به جز احتمالاً rlimitnofile داشته باشید مگر اینکه سرور با مشکل مواجه شده باشد.

چه تعداد شکست در خواندن یا نوشتن رخ دهد تا یک کانال به خواب برود یا بسته شود. مقدار پیش‌فرض "5" است.
هر بار که تلاش برای نوشتن EAGAIN یا EWOULDBLOCK برمی‌گرداند، innd(8) برای تعداد ثانیه‌های فزاینده‌ای قبل از تلاش مجدد صبر خواهد کرد. این ضریب برای زمان خواب است. اگر با فیدهای کانالی که نمی‌توانند سرعت خود را حفظ کنند مشکل دارید، ممکن است تغییر این مقدار به "2" یا "3" خوب باشد، زیرا آن‌گاه هنگامی که کانال پر می‌شود INN به جای اینکه دو دقیقه صبر کند، در عرض چند ثانیه دوباره تلاش خواهد کرد. مقدار پیش‌فرض "120" است.
مدت زمان (بر حسب ثانیه) انتظار میان بررسی کانال‌های غیرفعال. مقدار پیش‌فرض "600" است.
چه تعداد ثانیه صبر شود قبل از اینکه یک کانال مجدداً راه‌اندازی شود. مقدار پیش‌فرض "300" است.
آستانه برای تصمیم‌گیری در مورد اینکه آیا داده‌های از قبل خوانده‌شده به بالای بافر منتقل شوند یا بافر گسترش یابد. بافر شرح داده شده در اینجا برای خواندن داده‌های NNTP استفاده می‌شود. افزایش این مقدار ممکن است عملکرد را بهبود بخشد، اما نباید در سیستم‌هایی با حافظه ناکافی افزایش یابد. مقادیر مجاز بین "0" و "1048576" هستند (مقادیر خارج از محدوده به عنوان "1048576" در نظر گرفته می‌شوند) و مقدار پیش‌فرض "16384" است.
چه تعداد نوشتن مقاله میان به‌روزرسانی فایل‌های active و history فاصله بیفتد. مقدار پیش‌فرض "10" است.

این یک مصالحه بین سرعت بالاتر و از دست رفتن داده‌های بیشتر در صورت کرش innd (یا کرش سیستم، قطع برق و غیره) است. هر چه این پارامتر بالاتر باشد، همگام‌سازی‌های کم‌تری انجام می‌شود. این در واقع بسامد نقاط وارسی (checkpoints) است: حداکثر تعداد مقالاتی که ممکن است در صورت بروز کرش یتیم شوند زیرا در فایل history ثبت نشده بودند. علاوه بر این، عدم اعمال به‌روزرسانی‌ها در فایل active بعداً مشکلات دیگری ایجاد خواهد کرد، مانند شماره‌های مقاله تکراری و خطاهای متناظر هنگام ذخیره مقالات جدید. (اگر innd کرش کرده باشد، می‌توانید این خطاها را با بازسازی فایل history و نمای کلی با makehistory(8) برطرف کنید. فایل active پس از آن عملیات به طور خودکار دوباره شماره‌گذاری خواهد شد.)

هنگام استفاده از buffindexed، بازیابی داده‌های نمای کلی (یعنی پاسخ دادن به OVER یا اجرای expireover) باعث نگاشت حافظه‌ای (mmapping) تمام بلوک‌های داده نمای کلی می‌شود که شامل داده‌های نمای کلی درخواستی برای گروه خبری هستند. اما برای گروه‌های خبری با حجم بالا مانند control.cancel، این ممکن است باعث mmapping بیش از حد به طور همزمان شده و منجر به مشکلات منابع سیستم گردد. برای جلوگیری از این، اگر مقدار مورد نیاز برای نگاشت حافظه از keepmmappedthreshold (به کیلوبایت) بیشتر شود، buffindexed تنها یک بلوک نمای کلی (۸ کیلوبایت) را mmap می‌کند. این پارامتر مختص روش ذخیره‌سازی نمای کلی buffindexed است. مقدار پیش‌فرض "1024" (۱ مگابایت) است.
اگر روی هر مقداری غیر از "0" تنظیم شود، حداکثر اندازه بافر (بر حسب بایت) برای خواندن دستور NNTP این مقدار را خواهد داشت. این مقدار نباید در سیستم‌هایی که در پردازش و ذخیره مقالات کند هستند بزرگ باشد، زیرا منجر به این می‌شود که innd(8) زمان زیادی را روی هر کانال صرف کند و کانال‌های دیگر را منتظر نگه دارد. مقدار پیش‌فرض BUFSIZ تعریف‌شده در stdio.h است (معمولاً بین "1024" و "8192" در بیشتر محیط‌ها، setbuf(3) را ببینید).
چند بار تلاش برای ()fork انجام شود قبل از اینکه متوقف شود. مقدار پیش‌فرض "10" است.
چه تعداد اتصال ورودی می‌توانند در صف انتظار گوش دادن (listen backlog) برای innd، nnrpd و دو روش ذخیره‌سازی نمای کلی ("ovdb" و "ovsqlite") قرار گیرند. مقدار پیش‌فرض "128" است و در صورتی که متوجه شدید برخی درخواست‌های اتصال قطع می‌شوند باید افزایش یابد.
اگر روی مقداری غیر از "0" تنظیم شود، تمامی پردازش‌های فرزند innd(8) دارای این مقدار nice(2) خواهند بود. این معمولاً برای دادن اولویت پایین‌تر (مقدار nice بالاتر) به تمام پردازش‌های فرزند innd(8) استفاده می‌شود تا innd(8) بتواند سهم عمده پردازنده را در زمان نیاز به دست آورد. مقدار پیش‌فرض "4" است.
اگر روی مقداری بزرگ‌تر از "0" تنظیم شود، تمامی پردازش‌های nnrpd(8) که یک دستور NEWNEWS را دریافت و پردازش می‌کنند خود را با این مقدار nice(2) می‌کنند (که به سایر پردازش‌های nnrpd اولویت بالاتری می‌دهد). مقدار پیش‌فرض "0" است. توجه داشته باشید که اگر این مقدار روی مقداری کمتر از nicennrpd (یا nicekids اگر nnrpd(8) از innd(8) ایجاد شده باشد) تنظیم شود، نادیده گرفته خواهد شد.
اگر روی مقداری بزرگ‌تر از "0" تنظیم شود، تمامی پردازش‌های nnrpd(8) خود را به این مقدار nice(2) می‌کنند. این به سایر پردازش‌های خبری اولویت بالاتری می‌دهد و می‌تواند به overchan(8) کمک کند تا با اخبار ورودی همراه شود (اگر هدف این است، اطمینان حاصل کنید که overchan(8) نیز از طریق nicekids روی اولویت پایین‌تری تنظیم نشده باشد). مقدار پیش‌فرض "0" است، که باعث می‌شود پردازش‌های nnrpd(8) ایجادشده از innd(8) از مقدار nicekids استفاده کنند، در حالی که nnrpd(8) اجراشده به عنوان دیمن از اولویت پیش‌فرض سیستم استفاده خواهد کرد. توجه داشته باشید که برای پردازش‌های nnrpd(8) ایجادشده از innd(8)، اگر این مقدار روی مقداری کمتر از nicekids تنظیم شود نادیده گرفته خواهد شد.
برای این تعداد ثانیه قبل از متوجه شدن کانال‌های غیرفعال صبر شود. برای این تعداد ثانیه قبل از اینکه innd مقالات را در زمانی که متوقف (paused) است یا تعداد خطاهای نوشتن کانال از badiocount فراتر می‌رود پردازش کند، صبر شود. مقدار پیش‌فرض "300" است.
چه مدت (بر حسب ثانیه) یک کانال ورودی innd(8) می‌تواند غیرفعال بماند قبل از اینکه innd آن را ببندد. مقدار پیش‌فرض "3600" (یک ساعت) است.
حداکثر تعداد توصیف‌گرهای فایلی که innd(8) یا innfeed(8) می‌توانند به طور همزمان باز داشته باشند. اگر innd(8) یا innfeed(8) تلاش کنند توصیف‌گرهای فایل بیشتری نسبت به این مقدار باز کنند، ممکن است برنامه مهار شده یا به شکل دیگری دچار اختلال عملکرد یا کاهش کارایی شود. تعداد توصیف‌گرهای فایل باز تقریباً برابر است با حداکثر تعداد فیدهای ورودی و دسته‌های خروجی برای innd(8) به علاوه تعداد جریان‌های خروجی برای innfeed(8) و اگر از روش نمای کلی tradindexed استفاده می‌کنید، مقدار پارامتر overcachesize. اگر rlimitnofile روی یک مقدار منفی تنظیم شود، حد پیش‌فرض سیستم‌عامل استفاده خواهد شد؛ این معمولاً در سیستم‌هایی غیر از Solaris کافی خواهد بود. تقریباً تمام سیستم‌عامل‌ها دارای نوعی محدودیت سخت حداکثری هستند که این مقدار نمی‌تواند فراتر از آن افزایش یابد، معمولاً ۲۵۶، ۱۰۲۴ یا ۶۵۵۳۶. مقدار پیش‌فرض این پارامتر "-1" است.

تنظیم این پارامتر روی "256" در سیستم‌های Solaris برای نسخه‌های ۳۲ بیتی Solaris یا برنامه‌های ۳۲ بیتی که روی Solaris شصت و چهار بیتی اجرا می‌شوند، و همچنین نسخه‌های ۶۴ بیتی Solaris قبل از 11.0 به شدت توصیه می‌شود. برای جزئیات بیشتر مستندات Solaris درباره توصیف‌گرهای فایل در https://support.oracle.com/knowledge/Sun%20Microsystems/1005979_1.html را ببینید.

نکته برای کاربران متخصصی که INN را از روی سورس کد کامپایل می‌کنند: اگر نیاز به استفاده از بیش از "FD_SETSIZE" توصیف‌گر فایل دارید (همان‌طور که در هدر سیستمی sys/select.h تعریف شده و معمولاً پیش‌فرض آن ۱۰۲۴ است)، می‌توانید این مقدار را برای نمونه با کامپایل مجدد INN همراه با گزینه "-DLARGE_FD_SETSIZE=4096" داده‌شده به کامپایلر، به "4096" افزایش دهید.

محل ذخیره‌سازی اخبار بایگانی‌شده. مقدار پیش‌فرض pathspool/archive است.
مسیر محلی که مقالات خبری در آن ذخیره می‌شوند (برای روش‌های ذخیره‌سازی غیر از CNFS). مقدار پیش‌فرض pathspool/articles است.
مسیر فایل‌های اجرایی دوتایی (binaries) اخبار. مقدار پیش‌فرض pathnews/bin است.
مسیر فایل‌هایی که پیام‌های کنترلی را مدیریت می‌کنند. کد مربوط به رسیدگی به هر نوع مجزای پیام کنترلی در اینجا قرار دارد. بسیار مراقب باشید چه فایلی با پسوند ".pl" در این دایرکتوری قرار می‌دهید، زیرا می‌تواند به یک خطر امنیتی شدید تبدیل شود. مقدار پیش‌فرض pathbin/control است.
مسیر فایل‌های پایگاه‌داده مورد استفاده و به‌روزرسانی‌شده توسط سرور (در حال حاضر active، active.times، history و نمایه‌های آن، و newsgroups). مقدار پیش‌فرض pathnews/db است.
مسیر فایل‌های پیکربندی اخبار. مقدار پیش‌فرض pathnews/etc است.
مسیر فیلترهای Perl و Python. مقدار پیش‌فرض pathbin/filter است.
جایی که هرگونه فایل HTML (مانند گزارش‌های وضعیت دوره‌ای) در آن قرار می‌گیرد. اگر گزارش‌های خبری باید به‌صورت بی‌درنگ روی وب در دسترس باشند، فایل‌های این دایرکتوری باید توسط یک وب‌سرور ارائه شوند. مقدار پیش‌فرض، مقدار pathnews/http است.
مکانی که اخبار دسته‌ای ورودی در آن ذخیره می‌شوند. مقدار پیش‌فرض pathspool/incoming است.
جایی که فایل‌های گزارش (لاگ) اخبار نوشته می‌شوند. مقدار پیش‌فرض pathnews/log است.
دایرکتوری خانگی کاربر news و معمولاً ریشه سلسله‌مراتب اخبار. هیچ پیش‌فرضی وجود ندارد؛ این پارامتر باید در inn.conf تنظیم شود وگرنه INN از شروع به کار خودداری خواهد کرد.
مکان پیش‌فرض برای فایل‌های فید خروجی. مقدار پیش‌فرض pathspool/outgoing است.
مسیر فایل‌های نمای کلی اخبار. مقدار پیش‌فرض pathspool/overview است.
مسیر فایل‌های مورد نیاز در زمان اجرای سرور و اطلاعات وضعیت زمان اجرا. این شامل فایل‌های قفل و سوکت‌ها برای ارتباط با innd(8) است. این دایرکتوری و سوکت‌های کنترلی درون آن باید از دسترسی کاربران غیرمجاز به جز کاربر news محافظت شوند. مقدار پیش‌فرض pathnews/run است.
ریشه سلسله‌مراتب مخزن (spool) اخبار. این پارامتر عمدتاً برای تعیین مقادیر پیش‌فرض سایر پارامترها و تعیین مسیر دایرکتوری backlog برای innfeed(8) استفاده می‌شود. مقدار پیش‌فرض pathnews/spool است.
جایی که INN فایل‌های موقت را در آن قرار می‌دهد. به دلایل امنیتی، این مسیر با دایرکتوری فایل‌های موقت سیستم یکسان نیست (INN تعداد زیادی فایل موقت با نام‌های قابل پیش‌بینی ایجاد می‌کند و تلاش چندان زیادی برای محافظت در برابر حملات پیوند نمادین و مانند آن انجام نمی‌دهد؛ این امر مشروط بر اینکه کاربران عادی نتوانند در دایرکتوری موقت آن بنویسند امن است). مقدار پیش‌فرض در زمان پیکربندی تنظیم می‌شود و پیش‌فرض آن pathnews/tmp است.

در اینجا یک مثال بسیار کمینه آمده است که تنها پارامترهای ضروری را تنظیم می‌کند.

mta:                "/usr/lib/sendmail -oi -oem %s"
ovmethod:           tradindexed
pathhost:           news.example.com
pathnews:           /usr/local/news
hismethod:          hisv6

برای یک مثال جامع‌تر، به نمونه فایل inn.conf توزیع‌شده با INN که به عنوان نقطه شروع نصب شده است مراجعه کنید؛ این فایل شامل تمامی مقادیر پیش‌فرض برای ارجاع است.

نوشته‌شده توسط Rich $alz <rsalz@uunet.uu.net> برای InterNetNews و از آن زمان تاکنون توسط افراد بی‌شمار دیگری اصلاح، به‌روزرسانی و بازسازماندهی شده است.

inews(1), innd(8), innwatch(8), libinn_dbz(3), libinn_uwildmat(3), makehistory(8), nnrpd(8), rnews(1).

تقریباً هر برنامه‌ای در INN به نحوی از این فایل استفاده می‌کند. موارد فوق تنها برنامه‌های اصلی و پراستفاده‌ترین‌ها هستند.

2026-06-12 INN 2.7.4