." -*- mode: troff; coding: utf-8 -*- ." Automatically generated by Pod::Man 5.0102 (Pod::Simple 3.45) ." ." Standard preamble: ." ======================================================================== .de Sp " Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb " Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve " End verbatim text .ft R .fi .. ." \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. .ie n \{\ . ds C` "" . ds C' "" 'br\} .el\{\ . ds C` . ds C' 'br\} ." ." Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' ." ." If the F register is >0, we'll generate index entries on stderr for ." titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index ." entries marked with X<> in POD. Of course, you'll have to process the ." output yourself in some meaningful fashion. ." ." Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF ." ======================================================================== ." .IX Title "READERS.CONF 5" .TH READERS.CONF 5 2025-03-29 "INN 2.7.4" "InterNetNews Documentation" ." For nroff, turn off justification. Always turn off hyphenation; it makes ." way too many mistakes in technical documents. .if n .ad l .nh .SH "نام (NAME)" readers.conf \- کنترل دسترسی و پیکربندی nnrpd .SH "در یک نگاه (IN A NUTSHELL)" .IX Header "IN A NUTSHELL" فایل \fIreaders.conf\fR پارامترهای مربوط به این که چه کسی مجاز به اتصال به عنوان یک خواننده گروه‌های خبری است و پس از اتصال مجاز به انجام چه کارهایی است را تعیین می‌کند. به خاطر داشته باشید که در \fIreaders.conf\fR، احراز هویت (authentication) و مجوزدهی (authorization) در بلوک‌های متفاوتی پیکربندی می‌شوند. ابتدا، هویت کاربر احراز شده و یک شناسه هویتی به او اختصاص می‌یابد (در یک بلوک \f(CW\*(C`auth\*(C'\fR). سپس به این هویت مجوز دسترسی به گروه‌های خبری مشخصی با حقوق معین اعطا می‌شود (در یک بلوک \f(CW\*(C`access\*(C'\fR). .PP در رابطه با احراز هویت، بلوک \f(CW\*(C`auth\*(C'\fR شما برای کاربرانی که با گذرواژه متصل می‌شوند می‌تواند به شکل زیر باشد: .PP .Vb 4 \& auth "foreignokay" { \& auth: "ckpasswd \-f /newsusers" \& default: "" \& } .Ve .PP برای آگاهی از نحوه تولید گذرواژه‌ها و استفاده از این فایل \fInewsusers\fR، به مستندات گزینه \fB\-f\fR در صفحه راهنمای ckpasswd(8) مراجعه فرمایید. .PP به این ترتیب، با استفاده از بلوک احراز هویت \f(CW\*(C`foreignokay\*(C'\fR، کاربری که با موفقیت با نام \f(CW\*(C`myusername\*(C'\fR احراز هویت شود، شناسه هویتی \f(CW\*(C`myusername\*(C'\fR را دریافت خواهد کرد. اگر احراز هویت با شکست مواجه شود، هویت پیش‌فرض \f(CW\*(C`\*(C'\fR به او اختصاص می‌یابد که بعداً در بلوک‌های \f(CW\*(C`access\*(C'\fR ارزیابی خواهد شد. .PP بلوک‌های احراز هویت از آخرین بلوک موجود در فایل \fIreaders.conf\fR تا اولین بلوک (از پایین به بالا) بررسی می‌شوند. به محض اینکه یک بلوک با شرایط اتصال مطابقت پیدا کند، هویت متناظر به کاربر اختصاص داده می‌شود. .PP در خصوص اعطای دسترسی و مجوزها، می‌توانیم در یک بلوک \f(CW\*(C`access\*(C'\fR برای کاربرانی که با موفقیت با گذرواژه احراز هویت شده‌اند، چنین تعریفی داشته باشیم: .PP .Vb 4 \& access "authenticatedpeople" { \& users: "*" \& newsgroups: "*,!junk,!control,!control.*" \& } .Ve .PP و سپس بسته به اینکه آیا کاربران احراز هویت‌نشده اصلاً دسترسی دریافت می‌کنند یا خیر، چیزی شبیه به یکی از دو مورد زیر تعریف می‌شود: .PP .Vb 4 \& access "restrictive" { \& users: "" \& newsgroups: "!*" \& } \& \& access "readonly" { \& users: "" \& read: "local.*" \& post: "!*" \& } .Ve .PP لطفاً توجه داشته باشید که بلوک \f(CW\*(C`authenticatedpeople\*(C'\fR باید پیش از بلوک‌های \f(CW\*(C`restrictive\*(C'\fR یا \f(CW\*(C`readonly\*(C'\fR در فایل \fIreaders.conf\fR قرار گیرد، زیرا بلوک‌های دسترسی از آخرین بلوک موجود در فایل \fIreaders.conf\fR تا اولین بلوک (از پایین به بالا) بررسی می‌شوند. به محض اینکه یک بلوک با هویت اختصاص‌یافته توسط یک بلوک احراز هویت مطابقت کند، انتخاب خواهد شد. بلوک دسترسی \f(CW\*(C`authenticatedpeople\*(C'\fR با تمام کاربرانی که هویت \f(CW\*(C`\*(C'\fR به آن‌ها داده نشده است تطابق دارد. .PP مثال‌ها و قابلیت‌های بیشتر در ادامه این صفحه راهنما به تفصیل شرح داده شده است (به‌ویژه بدون فایل گذرواژه، با PAM، یا با قلاب‌های Perl یا Python). .PP پس از ایجاد تغییرات در \fIreaders.conf\fR نیازی به بارگذاری مجدد هیچ سرویسی ندارید؛ هر بار که یک کلاینت خبرخوان به سرور متصل می‌شود، یک فرآیند جدید \fBnnrpd\fR ایجاد شده و پیکربندی خود را از دیسک می‌خواند. با این حال، پس از هر تغییر می‌توانید دستور \f(CW\*(C`inncheck\*(C'\fR را اجرا کنید تا اعتبارسنجی نحوی پایه‌ای روی فایل \fIreaders.conf\fR انجام شود. .SH "توضیحات (DESCRIPTION)" .IX Header "DESCRIPTION" فایل \fIreaders.conf\fR در دایرکتوری \fIpathetc\fR، کنترل دسترسی را برای nnrpd(8) مشخص می‌کند. این فایل کنترل می‌کند چه کسانی مجاز به اتصال به عنوان خواننده اخبار هستند و پس از اتصال چه کارهایی می‌توانند انجام دهند. \fBnnrpd\fR هر بار که یک کلاینت اخبار به سرور وصل می‌شود این فایل را بازخوانی می‌کند، حتی زمانی که در حالت دیمن با گزینه \fB\-D\fR در حال اجراست؛ این بدان معناست که هرگونه تغییر در این فایل بلافاصله بر تمامی اتصالات بعدی اعمال می‌شود. (مکان \fIreaders.conf\fR در \fIpathetc\fR صرفاً مسیر پیش‌فرض است؛ همین قالب برای هر فایلی که با \f(CW\*(C`nnrpd \-c\*(C'\fR مشخص شود نیز صدق می‌کند.) .PP دو نوع مدخل در \fIreaders.conf\fR وجود دارد: جفت‌های پارامتر/مقدار و گروه‌های پیکربندی. خطوط خالی و هر چیزی پس از علامت هش (\f(CW\*(C`#\*(C'\fR) نادیده گرفته می‌شوند، مگر آنکه نویسه \f(CW\*(C`#\*(C'\fR با \f(CW\*(C`\e\*(C'\fR اسکیپ شده باشد. حداکثر تعداد نویسه‌ها در هر خط ۸٬۱۹۱ نویسه است. .PP جفت‌های پارامتر/مقدار شامل یک کلمه کلیدی هستند که بلافاصله پس از آن یک دونقطه، حداقل یک نویسه فاصله و یک مقدار قرار می‌گیرد. بزرگی و کوچکی حروف در نام پارامتر حائز اهمیت است (پارامترها عموماً باید با حروف کوچک نوشته شوند)، و یک پارامتر می‌تواند شامل هر نویسه‌ای به جز دونقطه، \f(CW\*(C`#\*(C'\fR و فاصله باشد. به عنوان مثال: .PP .Vb 1 \& hosts: *.example.com .Ve .PP مقادیری که شامل فاصله هستند باید در گیومه دوتایی قرار گیرند، مانند: .PP .Vb 1 \& hosts: "*.example.com, *.example.net" .Ve .PP اگر پارامتر حاوی فاصله نباشد، مانند: .PP .Vb 1 \& hosts: *.example.com,*.example.net .Ve .PP نیازی به قرار دادن آن در گیومه نیست، اگرچه ممکن است برای شفافیت بیشتر مایل به انجام این کار باشید. .PP هیچ راهی برای ادامه دادن یک خط در خط بعدی وجود ندارد، و بنابراین نمی‌توان یک پارامتر تکی با مقداری بیش از حدود ۸٬۱۸۰ نویسه داشت. .PP بسیاری از پارامترها مقادیر بولی (boolean) می‌پذیرند. برای تمامی این پارامترها، مقدار می‌تواند به صورت \f(CW\*(C`true\*(C'\fR، \f(CW\*(C`yes\*(C'\fR یا \f(CW\*(C`on\*(C'\fR برای فعال‌سازی، و هر یک از مقادیر \f(CW\*(C`false\*(C'\fR، \f(CW\*(C`no\*(C'\fR یا \f(CW\*(C`off\*(C'\fR برای غیرفعال‌سازی مشخص شود. بزرگی و کوچکی حروف در این مقادیر بی‌تاثیر است. .PP دو نوع اصلی از گروه‌های پیکربندی وجود دارد: auth و access. گروه auth سازوکارهایی برای تعیین هویت کاربر (اینکه چه کسی است) فراهم می‌کند. گروه access با توجه به هویت کاربر، تعیین می‌کند که کاربر مجاز به انجام چه اقداماتی است. نگارش یک فایل \fIreaders.conf\fR برای سیستم شما یک فرآیند دو مرحله‌ای است: ابتدا اختصاص یک هویت به هر اتصال ورودی با استفاده از گروه‌های auth، و سپس اعطای دسترسی‌ها و امتیازات مناسب به هر هویت با استفاده از گروه‌های access. توصیه می‌کنیم گروه‌های auth و گروه‌های access را در فایل پیکربندی با یکدیگر درنیامیزید؛ اغلب منطقی‌تر است (در صورت عدم استفاده از پارامتر \fIkey\fR) که ابتدا تمامی گروه‌های auth و سپس تمام گروه‌های access در پایین قرار داده شوند. .PP هویت کاربر که توسط یک گروه auth تثبیت می‌شود، در صورت مشخص بودن دامنه به شکل یک آدرس ایمیل (مانند "@") و در غیر این صورت صرفاً به شکل "" خواهد بود. .PP اگر گزینه \fInnrpdauthsender\fR در \fIinn.conf\fR فعال باشد، هویت کاربر در فیلد سرآیند Sender مقالات ارسال‌شده توسط آن کاربر نیز درج می‌شود. برای جزئیات بیشتر به مستندات این گزینه در inn.conf(5) مراجعه کنید. .PP تعریف یک گروه auth به این صورت است: .PP .Vb 8 \& auth { \& hosts: \& auth: \& res: \& default: \& default\-domain: \& # ...possibly other settings \& } .Ve .PP شناسه به عنوان برچسبی برای گروه استفاده می‌شود و صرفاً برای مقاصد مستندسازی است. (اگر پیکربندی syslog شما تسهیلات \f(CW\*(C`news.debug\*(C'\fR را ثبت کند، مقدار در خروجی اشکال‌زدایی \fBnnrpd\fR ظاهر می‌شود. بررسی این خروجی می‌تواند در فهمیدن اینکه چرا پیکربندی شما آن‌طور که انتظار دارید عمل نمی‌کند بسیار مفید باشد.) .PP یک گروه auth مشخص تنها برای میزبان‌هایی اعمال می‌شود که نام یا آدرس IP آن‌ها با عبارت وایلد‌مت (wildmat) تعیین‌شده با پارامتر \fIhosts\fR تطابق داشته باشد (عبارت‌های وایلد‌مت جداشده با کاما مجاز هستند، اما \f(CW\*(C`@\*(C'\fR پشتیبانی نمی‌شود). به جای عبارت‌های وایلد‌مت، می‌توانید از نمادگذاری CIDR نیز برای تطبیق هر آدرس IP درون یک بلوک شبکه استفاده کنید؛ برای مثال، "10.10.10.0/24" با هر آدرس IP بین 10.10.10.0 و 10.10.10.255 شامل هر دو مطابقت خواهد داشت. .PP در صورت کامپایل شدن برنامه با کتابخانه‌های TLS/SSL یا SASL، یک گروه auth با پارامتر \fIrequire_encryption\fR تنظیم‌شده بر روی true، تنها زمانی اعمال می‌شود که اتصال ورودی از یک لایه رمزنگاری استفاده کند؛ خواه از همان ابتدا با ارسال پرچم \fB\-S\fR به \fBnnrpd\fR، خواه پس از مذاکره موفق STARTTLS، یا پس از احراز هویت موفق با استفاده از مکانیزم SASL که لایه رمزنگاری را مذاکره می‌کند. .PP برای هر اتصال از میزبانی که با آن عبارت وایلد‌مت یا بلوک شبکه مطابقت داشته باشد، هر (ممکن است چندین خط \fIres\fR در یک بلوک وجود داشته باشد؛ آن‌ها به ترتیب تا موفقیت یکی اجرا می‌شوند)، در صورت وجود، اجرا می‌شود تا هویت کاربر را صرفاً از اطلاعات اتصال تشخیص دهد. اگر تمام برنامه‌های تحلیل‌گر (resolvers) شکست بخورند، یا اگر پارامتر \fIres\fR وجود نداشته باشد، به کاربر هویت "@" اختصاص می‌یابد؛ به عبارت دیگر، مقادیر پارامترهای \fIdefault\fR و \fIdefault-domain\fR به کار گرفته می‌شوند. اگر تنها یک نام کاربری برگرداند، از مقدار به عنوان دامنه استفاده خواهد شد. .PP اگر کاربر بعداً از طریق دستورات AUTHINFO USER/PASS اقدام به احراز هویت کند، نام کاربری و گذرواژه ارائه‌شده به هر ارسال می‌گردد (ممکن است چندین خط \fIauth\fR، \fIperl_auth\fR یا \fIpython_auth\fR در یک بلوک حضور داشته باشند؛ آن‌ها به ترتیب تا زمان موفقیت یکی اجرا می‌شوند). اگر یکی از آن‌ها موفق شود و هویتی متفاوت از هویت تعیین‌شده در زمان اتصال اولیه بازگرداند، مجدداً با گروه‌های دسترسی موجود تطبیق داده می‌شود و کارهایی که کاربر مجاز به انجام آن‌ها است ممکن است تغییر یابد. رایج‌ترین برنامه \fBckpasswd\fR است که از چندین روش برای بررسی گذرواژه‌ها از جمله استفاده از PAM پشتیبانی می‌کند. برای جزئیات بیشتر صفحه راهنمای ckpasswd(8) را مطالعه کنید. .PP هنگام تطبیق گروه‌های auth، آخرین گروه auth موجود در فایل که با یک اتصال مشخص و ترکیب نام کاربری/گذرواژه تطابق داشته باشد اعمال می‌شود. .PP تعریف یک گروه access معمولاً به شکل زیر است: .PP .Vb 5 \& access { \& users: \& newsgroups: \& # ...possibly other settings \& } .Ve .PP باز هم، صرفاً برای مقاصد مستندسازی است. این ساختار بیان می‌کند تمام کاربرانی که هویت آن‌ها با تطابق دارد می‌توانند در تمامی گروه‌های خبری منطبق با بخوانند و پیام ارسال کنند (همانند قبل، عبارت‌های وایلد‌مت جداشده با کاما مجاز هستند، اما \f(CW\*(C`@\*(C'\fR پشتیبانی نمی‌شود). به صورت متناوب، می‌توانید از فرم زیر استفاده کنید: .PP .Vb 5 \& access { \& users: \& read: \& post: \& } .Ve .PP و کاربران منطبق قادر خواهند بود هر گروهی را که با مطابقت دارد بخوانند و در هر گروهی که با تطابق دارد ارسال خبر کنند. شما همچنین می‌توانید موارد متعدد دیگری را در گروه access تنظیم کرده و همچنین پارامترهای مختلف inn.conf(5) را صرفاً برای یک گروه خاص از کاربران بازنویسی (override) نمایید. .PP درست همانند گروه‌های auth، هنگام تطبیق گروه‌های access نیز آخرین گروه منطبق در فایل برای تعیین دسترسی‌های کاربر انتخاب می‌شود. یک استثنا برای این قاعده وجود دارد: اگر گروه auth منطبق با کلاینت شامل پارامتر \fIperl_access\fR یا \fIpython_access\fR باشد، اسکریپتی که به عنوان آرگومان داده شده برای تولید پویا یک گروه access به کار می‌رود. این گروه دسترسی جدید سپس برای تعیین حقوق دسترسی کلاینت استفاده شده و گروه‌های access موجود در فایل نادیده گرفته می‌شوند. .PP یک حالت خاص دیگر نیز وجود دارد که باید در نظر داشت. هنگام ایجاد قوانین پیچیده احراز هویت و اعطای مجوز، گاهی اوقات مفید است که هویت‌های ارائه‌شده توسط یک گروه auth معین صرفاً بر گروه‌های access خاصی اعمال گردند؛ به عبارت دیگر، به جای بررسی هویت در برابر پارامتر \fIusers\fR تمامی گروه‌های access، بررسی فقط در برابر پارامتر \fIusers\fR چند گروه دسترسی خاص انجام پذیرد. این کار به کمک پارامتر \fIkey\fR انجام می‌شود. برای مثال: .PP .Vb 5 \& auth example { \& key: special \& hosts: *.example.com \& default: \& } \& \& access example { \& key: special \& users: \& newsgroups: * \& addcanlockuser: none \& } .Ve .PP در این مثال، دو پارامتر \fIkey\fR این گروه auth را به این گروه access پیوند می‌دهند. برای هر اتصال ورودی منطبق با "*.example.com" (با این فرض که گروه auth دیگری در ادامه نیامده باشد که با این میزبان‌ها تطابق پیدا کند)، هیچ گروه دسترسی که فاقد \f(CW\*(C`key: special\*(C'\fR باشد حتی بررسی نخواهد شد. به همین ترتیب، گروه access فوق فقط در صورتی ارزیابی می‌شود که کاربر با یک گروه auth حاوی \f(CW\*(C`key: special\*(C'\fR احراز هویت شده باشد. این مکانیزم معمولاً چندان مورد نیاز نیست؛ چرا که تقریباً همیشه روش بهتری برای دستیابی به همین نتیجه وجود دارد. .PP همچنین در این مثال توجه داشته باشید که پارامتر \fIdefault-domain\fR تعریف نشده است، به این معنی که هیچ دامنه‌ای به نام کاربری پیش‌فرض الحاق نمی‌شود و هویت این اتصالات صرفاً "" خواهد بود. توجه داشته باشید که برخی از ابزارهای الحاقی INN ترجیح می‌دهند هویت‌های احراز هویت‌شده همیشه یک آدرس ایمیل کامل (شامل دامنه) باشند، بنابراین اگر از این ابزارهای الحاقی استفاده می‌کنید، ممکن است بخواهید سیستم خود را به این شیوه پیکربندی کنید. از آنجا که چندین فرد مختلف می‌توانند هویت یکسان "" را دریافت کنند، هیچ هش اختصاصی کاربر برای Cancel-Lock نباید تولید گردد. .PP فایل‌های پیکربندی را می‌توان با استفاده از نحو زیر در فایل‌های پیکربندی دیگر گنجاند: .PP .Vb 1 \& include .Ve .PP بدین ترتیب، فایلی با نام فراخوانی و گنجانده می‌شود. این نحو فقط در سطح بالای فایل (top-level) مجاز است. .PP در ادامه فهرست کامل پارامترهای مجاز برای گروه‌های auth و گروه‌های access ارائه شده است، و پس از آن چند مثال کاربردی برای شفاف‌تر شدن این مفاهیم آورده شده است. .SH "پارامترهای گروه احراز هویت (AUTH GROUP PARAMETERS)" .IX Header "AUTH GROUP PARAMETERS" یک گروه auth بدون وجود حداقل یکی از پارامترهای \fIres\fR، \fIauth\fR، \fIperl_auth\fR، \fIpython_auth\fR یا \fIdefault\fR کاملاً بی‌معنی است (و در عمل نادیده گرفته می‌شود). .IP \fIauth\fR 4 .IX Item "auth" یک خط فرمان ساده برای احراز هویت‌کننده کاربر (کاراکترهای متا در شل پشتیبانی نمی‌شوند). اگر یک مسیر کامل داده نشود، برنامه اجراشده باید در دایرکتوری \fIpathbin\fR/auth/passwd قرار داشته باشد. احراز هویت‌کننده برنامه‌ای است که برای رسیدگی به نام کاربری و گذرواژه ارائه‌شده توسط کاربر، از طریق سازوکاری مانند AUTHINFO USER/PASS استفاده می‌شود. همانند \fIres\fR، یک گروه auth می‌تواند چندین پارامتر \fIauth\fR داشته باشد؛ آن‌ها به ترتیب آزموده می‌شوند و خروجی نخستین موردی که موفق شود به کار می‌رود. همچنین \fIperl_auth\fR را ببینید. .Sp رایج‌ترین احراز هویت‌کننده مورد استفاده ckpasswd(8) است؛ برای اطلاعات بیشتر به صفحه راهنمای آن رجوع کنید. .IP \fIdefault\fR 4 .IX Item "default" نام کاربری پیش‌فرض برای اتصالات منطبق با این گروه auth. این نام کاربری در زمان اتصال، در صورت شکست تمامی برنامه‌های تحلیل‌گر یا در غیاب پارامترهای \fIres\fR، به کاربر نسبت داده می‌شود. توجه داشته باشید که این مقدار می‌تواند یک نام کاربری ساده باشد، که در این صورت \fIdefault-domain\fR (در صورت وجود) پس از یک \f(CW\*(C`@\*(C'\fR به انتهای آن افزوده می‌شود، یا یک رشته هویتی کامل شامل \f(CW\*(C`@\*(C'\fR باشد که در این حالت عیناً استفاده خواهد شد. .IP \fIdefault-domain\fR 4 .IX Item "default-domain" رشته دامنه پیش‌فرض برای این گروه auth. اگر تحلیل‌گر کاربر یا برنامه احراز هویت دامنه‌ای ارائه ندهد، یا اگر از نام کاربری پیش‌فرض استفاده شود و فاقد \f(CW\*(C`@\*(C'\fR باشد، از این دامنه برای تشکیل هویت کاربر استفاده می‌شود. (توجه داشته باشید که در بسیاری از سیستم‌ها، اصولاً نیازی نیست هویت کاربران همراه با نام دامنه مشخص شود، که در این حالت نیازی به استفاده از این پارامتر نیست.) .IP \fIhosts\fR 4 .IX Item "hosts" فهرستی جداشده با کاما از میزبان‌های دوردست، الگوهای وایلد‌مت منطبق با نام‌های میزبان یا آدرس‌های IP، یا بلوک‌های شبکه IP در قالب نمادگذاری CIDR. اگر کاربری از میزبانی متصل شود که با این پارامتر تطابق ندارد، این گروه auth با اتصال تطبیق داده نشده و نادیده گرفته می‌شود. .Sp توجه داشته باشید که اگر الگوهای متعددی دارید که نمی‌توان آن‌ها را در الگوهای جامع‌تر ادغام کرد (مانند شمار زیادی از سیستم‌های منفرد پراکنده در شبکه که باید دسترسی داشته باشند)، ممکن است پارامتر \fIhosts\fR از حداکثر طول خط یعنی ۸٬۱۹۲ نویسه فراتر برود. در این صورت، لازم است آن گروه auth را به چندین گروه auth تفکیک کنید که هر کدام بخشی از میزبان‌ها را در پارامتر \fIhosts\fR خود قید کرده باشند و همگی یک هویت کاربری یکسان را تخصیص دهند. .Sp در صورتی که این پارامتر ارائه نشود، تمامی میزبان‌ها مطابقت خواهند داشت. .IP \fIkey\fR 4 .IX Item "key" اگر این پارامتر مشخص شده باشد، هر اتصالی که با این گروه auth تطابق پیدا کند، اختیارات و امتیازات خود را صرفاً از زیرمجموعه‌ای از گروه‌های access تعیین می‌کند که حاوی یک پارامتر key منطبق باشند. .IP \fIlocaladdress\fR 4 .IX Item "localaddress" فهرستی جداشده با کاما از الگوهای میزبان یا آدرس محلی با همان نحوی که در پارامتر \fIhosts\fR استفاده شده است. اگر این پارامتر قید شود، گروه auth آن تنها با اتصالاتی مطابقت خواهد داشت که به یک رابط شبکه محلی منطبق برقرار شده باشند. (بدیهی است که این پارامتر تنها برای سرورهایی با چندین رابط شبکه کاربرد دارد.) .Sp در صورت عدم ارائه این پارامتر، تمام آدرس‌های محلی مطابقت داده می‌شوند. .IP \fIperl_access\fR 4 .IX Item "perl_access" مسیری به یک اسکریپت Perl برای تولید پویای یک گروه access. اگر یک گروه auth با موفقیت تطابق یابد و دارای پارامتر \fIperl_access\fR باشد، اسکریپت پرل داده‌شده در آرگومان برای ایجاد یک گروه access استفاده خواهد شد. این گروه سپس حقوق دسترسی کلاینت را تعیین کرده و تمامی گروه‌های access تعریف‌شده در \fIreaders.conf\fR را نادیده می‌گیرد. صرفاً و تنها در حالتی که یک گروه auth موفق حاوی پارامتر \fIperl_access\fR باشد، گروه‌های access فایل \fIreaders.conf\fR نادیده گرفته شده و حقوق کلاینت به صورت پویا معین می‌شود. این پارامتر تنها زمانی معتبر است که INN با پشتیبانی از Perl کامپایل شده باشد (دادن گزینه \fB\-\-with\-perl\fR به \f(CW\*(C`configure\*(C'\fR). اطلاعات بیشتر در فایل \fIdoc/hook\-perl\fR قابل دسترسی است. .IP \fIperl_auth\fR 4 .IX Item "perl_auth" مسیری به یک اسکریپت Perl برای احراز هویت. پارامتر \fIperl_auth\fR دقیقاً مشابه \fIauth\fR عمل می‌کند، با این تفاوت که اسکریپت نام‌برده را از طریق قلاب Perl و نه با یک برنامه خارجی فراخوانی می‌نماید. استفاده چندگانه/ترکیبی از پارامترهای \fIauth\fR، \fIperl_auth\fR و \fIpython_auth\fR درون هر گروه auth مجاز است؛ هر خط به ترتیبی که نوشته شده آزموده خواهد شد. \fIperl_auth\fR قدرت بیشتری نسبت به \fIauth\fR دارد زیرا اطلاعات تکمیلی درباره کلاینت را در اختیار برنامه احراز هویت می‌گذارد و امکان بازگرداندن یک رشته خطا و یک نام کاربری را فراهم می‌کند. این پارامتر فقط زمانی معتبر است که INN با پشتیبانی Perl کامپایل شده باشد (\fB\-\-with\-perl\fR به \f(CW\*(C`configure\*(C'\fR ارسال شده باشد). اطلاعات تکمیلی در \fIdoc/hook\-perl\fR موجود است. .IP \fIpython_access\fR 4 .IX Item "python_access" یک اسکریپت Python برای تولید پویای یک گروه access. اگر یک گروه auth با موفقیت تطابق پیدا کند و حاوی پارامتر \fIpython_access\fR باشد، اسکریپت مشخص‌شده در آرگومان (بدون پسوند \f(CW\*(C`.py\*(C'\fR آن) واقع در دایرکتوری \fIpathfilter\fR برای ایجاد یک گروه access به کار گرفته می‌شود. این گروه سپس حقوق دسترسی کلاینت را معین کرده و بر تمام گروه‌های access در \fIreaders.conf\fR تقدم می‌یابد. .Sp تنها در حالتی که یک گروه auth منطبق حاوی پارامتر \fIpython_access\fR باشد، گروه‌های access درون فایل \fIreaders.conf\fR نادیده گرفته می‌شوند و حقوق کلاینت به شکل پویا تعیین می‌گردد. .Sp این پارامتر تنها زمانی معتبر است که INN با پشتیبانی Python ساخته شده باشد (دادن \fB\-\-with\-python\fR به \f(CW\*(C`configure\*(C'\fR). اطلاعات بیشتر در فایل \fIdoc/hook\-python\fR ارائه شده است. .IP \fIpython_auth\fR 4 .IX Item "python_auth" یک اسکریپت Python برای احراز هویت. پارامتر \fIpython_auth\fR دقیقاً مشابه \fIauth\fR است، با این تفاوت که اسکریپت ارائه‌شده (بدون پسوند \f(CW\*(C`.py\*(C'\fR آن) واقع در دایرکتوری \fIpathfilter\fR را از طریق قلاب Python به جای یک برنامه خارجی اجرا می‌کند. استفاده چندگانه یا ترکیبی از پارامترهای \fIauth\fR، \fIperl_auth\fR و \fIpython_auth\fR درون هر گروه auth مجاز است؛ هر خط به ترتیبی که در فایل آمده اجرا خواهد شد. \fIpython_auth\fR توانایی‌های بالاتری نسبت به \fIauth\fR دارد زیرا اطلاعات بیشتری پیرامون کلاینت در اختیار برنامه احراز هویت می‌گذارد و امکان برگرداندن یک رشته خطا و یک نام کاربری را دارد. .Sp این پارامتر تنها زمانی معتبر است که INN با پشتیبانی Python کامپایل شده باشد (ارسال \fB\-\-with\-python\fR به \f(CW\*(C`configure\*(C'\fR). اطلاعات بیشتر را می‌توانید در \fIdoc/hook\-python\fR بیابید. .IP \fIpython_dynamic\fR 4 .IX Item "python_dynamic" یک اسکریپت Python برای اعمال پویای کنترل دسترسی بر اساس هر گروه خبری به طور جداگانه. اگر یک گروه auth موفقیت‌آمیز باشد و حاوی پارامتر \fIpython_dynamic\fR باشد، اسکریپت داده‌شده (بدون پسوند \f(CW\*(C`.py\*(C'\fR آن) در دایرکتوری \fIpathfilter\fR، هر بار که کاربر قصد مشاهده یک گروه خبری یا خواندن یا ارسال مقاله را داشته باشد، برای تعیین حقوق کلاینت فراخوانی می‌شود. حقوق دسترسی تعیین‌شده توسط \fIpython_dynamic\fR مقادیر پارامترهای گروه دسترسی از قبیل \fInewsgroups\fR، \fIread\fR و \fIpost\fR را بازنویسی می‌کند. .Sp این پارامتر تنها زمانی معتبر است که INN با پشتیبانی Python کامپایل شده باشد (دادن \fB\-\-with\-python\fR به \f(CW\*(C`configure\*(C'\fR). اطلاعات بیشتر در فایل \fIdoc/hook\-python\fR آمده است. .IP \fIrequire_encryption\fR 4 .IX Item "require_encryption" اگر مقدار آن برابر با true قرار داده شود، اتصال ورودی فقط در صورتی با این گروه auth تطابق پیدا می‌کند که رمزنگاری‌شده باشد؛ خواه از آغاز اتصال در صورت ارسال گزینه \fB\-S\fR به \fBnnrpd\fR، خواه پس از اجرای موفق STARTTLS، یا پس از احراز هویت موفق با استفاده از یک مکانیزم SASL که لایه رمزنگاری را مذاکره می‌نماید. این پارامتر تنها زمانی معتبر است که INN با پشتیبانی TLS/SSL یا SASL کامپایل شده باشد (به طور پیش‌فرض اگر کتابخانه‌های SSL و crypto از OpenSSL یا کتابخانه Cyrus SASL در زمان پیکربندی یافت شوند؛ در غیر این صورت گزینه‌های \fB\-\-with\-openssl\fR و \fB\-\-with\-sasl\fR در \f(CW\*(C`configure\*(C'\fR را بررسی فرمایید). .IP \fIres\fR 4 .IX Item "res" یک خط فرمان ساده برای تحلیل‌گر کاربر (کاراکترهای متا در شل پشتیبانی نمی‌شوند). در صورت عدم ارائه مسیر کامل، برنامه اجرایی باید در دایرکتوری \fIpathbin\fR/auth/resolv قرار گرفته باشد. یک تحلیل‌گر (resolver) برنامه‌ای برای احراز هویت است که تلاش می‌کند هویت کاربر متصل را صرفاً با استفاده از داده‌های اتصال تشخیص دهد (به بیان دیگر، کاربر هنوز نام کاربری و گذرواژه‌ای وارد نکرده است). مثالی از یک تحلیل‌گر، برنامه‌ای است که هویت را از طریق بازخوانی مکانیزم ident یا از روی نام میزبان کاربر تشخیص می‌دهد. .Sp یک گروه auth می‌تواند چندین پارامتر \fIres\fR داشته باشد که به ترتیب فهرست‌شدن آزموده خواهند شد. نتیجه حاصل از اولین موردی که با موفقیت اجرا شود ملاک قرار می‌گیرد. .Sp به عنوان روشی جایگزین، می‌توان از یک بلوک res به جای پارامتر \fIres\fR استفاده نمود. پارامترهای معتبر در این بلوک‌های res عبارتند از: .RS 4 .IP \fIlog\fR 2 .IX Item "log" رشته‌ای برای درج در فایل لاگ \fIpathlog\fR/news.notice (با پیشوند \f(CW\*(C`res also\-log:\*(C'\fR) پیش از آزمودن برنامه تحلیل‌گر. یک گروه res می‌تواند چندین پارامتر \fIlog\fR داشته باشد که به ترتیب قیدشدن ثبت خواهند شد. .IP \fIprogram\fR 2 .IX Item "program" این پارامتر در یک بلوک res الزامی است. کاربرد آن دقیقاً مشابه پارامتر \fIres\fR است که مستقیماً در بلوک auth استفاده می‌شود. .Sp .Vb 3 \& auth { \& res: \& } .Ve .Sp بنابراین ساختار فوق معادل است با: .Sp .Vb 5 \& auth { \& res { \& program: \& } \& } .Ve .RE .RS 4 .RE .SH "پارامترهای گروه دسترسی (ACCESS GROUP PARAMETERS)" .IX Header "ACCESS GROUP PARAMETERS" .IP \fIaccess\fR 4 .IX Item "access" مجموعه‌ای از حروف که مجوزهای اعطاشده به کلاینت را مشخص می‌کند. این حروف از مجموعه زیر انتخاب می‌شوند: .RS 4 .IP A 4 .IX Item "A" کلاینت می‌تواند مقالاتی با فیلد سرآیند Approved ارسال کند (به بیان دیگر، می‌تواند مقالات را برای گروه‌های خبری مدیریت‌شده و نیازمند تایید، تصویب کند). به طور پیش‌فرض این کار مجاز نیست. .IP I 4 .IX Item "I" کلاینت می‌تواند مقالات را با دستور IHAVE تزریق کند. دقت داشته باشید که برای تزریق مقالات با دستور IHAVE، کاربر باید مجوز POST (گزینه \f(CW\*(C`P\*(C'\fR) را نیز دارا باشد. مقالاتی که با IHAVE تزریق می‌شوند مانند مقالات ارسال‌شده با POST در نظر گرفته می‌شوند؛ بدین معنا که این مقالات نباید پیش‌تر تزریق شده باشند (نباید دارای فیلدهای سرآیندی مانند Injection-Info باشند). .IP L 4 .IX Item "L" کلاینت می‌تواند در گروه‌های خبری که برای عدم پذیرش ارسال محلی تنظیم شده‌اند، پست ارسال کند (فیلدهای وضعیت \f(CW\*(C`j\*(C'\fR، \f(CW\*(C`n\*(C'\fR و \f(CW\*(C`x\*(C'\fR در فایل active(5)). .IP N 4 .IX Item "N" کلاینت می‌تواند از دستور NEWNEWS استفاده کند که تنظیمات سراسری سیستم را بازنویسی می‌نماید. .IP P 4 .IX Item "P" کلاینت اجازه ارسال مقاله (post) دارد. .IP R 4 .IX Item "R" کلاینت اجازه خواندن مقاله (read) دارد. .RE .RS 4 .Sp توجه داشته باشید که اگر این پارامتر تعریف شود، گزینه \fIallownewnews\fR در \fIinn.conf\fR برای اتصالات منطبق با این گروه access نادیده گرفته می‌شود و امکان استفاده کلاینت از دستور NEWNEWS تماماً به حضور نویسه \f(CW\*(C`N\*(C'\fR در رشته access بستگی دارد. اگر مایل به پشتیبانی از NEWNEWS هستید، مطمئن شوید که هنگام استفاده از این پارامتر، \f(CW\*(C`N\*(C'\fR را در رشته access قرار دهید. .Sp همچنین اگر این پارامتر تعریف شود و حرف \f(CW\*(C`R\*(C'\fR در رشته access موجود نباشد، کلاینت فارغ از مقادیر پارامترهای \fInewsgroups\fR یا \fIread\fR امکان خواندن مقالات را نخواهد داشت. به همین ترتیب، اگر این پارامتر مشخص گردد و \f(CW\*(C`P\*(C'\fR در آن نباشد، کلاینت نمی‌تواند مقاله‌ای ارسال کند. این شیوه استفاده از پارامتر \fIaccess\fR منسوخ و گمراه‌کننده است؛ اکیداً توصیه می‌شود که در صورت استفاده از پارامتر \fIaccess\fR، حروف \f(CW\*(C`R\*(C'\fR و \f(CW\*(C`P\*(C'\fR همیشه در رشته access گنجانده شوند و برای کنترل دقیق دسترسی‌ها از پارامترهای \fInewsgroups\fR، \fIread\fR و \fIpost\fR بهره گرفته شود. (برای اعطای دسترسی فقط‌خواندنی بدون امکان ارسال، می‌توانید صرفاً پارامتر \fIread\fR را بدون پارامتر \fIpost\fR تعریف کنید.) .RE .IP \fIaddcanlockuser\fR 4 .IX Item "addcanlockuser" اگر روی \f(CW\*(C`none\*(C'\fR تنظیم شود، ارسال‌های این کاربران فاقد هش اختصاصی کاربر در فیلد سرآیند Cancel-Lock خواهند بود (فقط هش مدیر سرور تولید می‌شود). هیچ فیلد سرآیند Cancel-Key نیز در درخواست‌های لغو (cancel) یا جایگزینی (supersede) درج نخواهد شد. این یک مقدار متنی است و پیش‌فرض آن \f(CW\*(C`username\*(C'\fR می‌باشد؛ بدین معنا که یک هش اختصاصی بر اساس هویت تخصیص‌یافته به این اتصال تولید می‌گردد. .Sp مقدار ممکن دیگر برای این پارامتر \f(CW\*(C`ip\*(C'\fR است، که در این حالت یک هش اختصاصی بر اساس آدرس IP اتصال به کار می‌رود (که باید یک IP ثابت باشد تا بتواند واقعاً هویت کاربران را مشخص سازد). .Sp برای اطلاعات بیشتر در خصوص ساختار قفل لغو به inn\-secrets.conf(5) مراجعه کنید. دلیل اصلی برای وجود این پارامتر، غیرفعال‌سازی این مکانیزم احراز هویت در مواقعی است که یک هویت یا آدرس IP یکسان توسط گروه access به چندین نفر مختلف اختصاص می‌یابد؛ در غیر این صورت، هر یک از این افراد می‌توانند درخواست لغو مقاله‌ای را ارسال کنند که در اصل توسط فرد دیگری با همان هویت یا آدرس IP ارسال شده بوده است. .IP \fIdomain\fR 4 .IX Item "domain" در صورت تنظیم، مقدار این پارامتر به عنوان بخش دامنه (بخش سمت راست پس از علامت \f(CW\*(C`@\*(C'\fR) در شناسه‌های Message-ID تولیدشده خودکار، و همچنین نام سرور قیدشده در فیلدهای سرآیند Injection-Info استفاده می‌شود. .Sp به طور پیش‌فرض، مقدار این پارامتر از پارامتر هم‌نام آن در \fIinn.conf\fR به ارث می‌رسد. با این حال، اگر \fIdomain\fR صریحاً در \fIreaders.conf\fR مقداردهی نشده باشد، رفتار تشریح‌شده در بالا فعال نمی‌شود مگر اینکه پارامتر \fIvirtualhost\fR بر روی true تنظیم گردد. .Sp همچنین ممکن است بخواهید پارامتر \fIfromhost\fR (به ارث رسیده از \fIinn.conf\fR) را برای نشانی ثبت شکایات در فیلد سرآیند Injection-Info مشخص نمایید، در صورتی که مقدار پیش‌فرض آن نیاز به تغییر دارد و پارامتر \fIcomplaints\fR تنظیم نشده یا مقدار \fInewsmaster\fR فاقد \f(CW\*(C`@\*(C'\fR است. .IP \fIgroupexactcount\fR 4 .IX Item "groupexactcount" این پارامتر آستانه‌ای را مشخص می‌کند که پایین‌تر از آن، \fBnnrpd\fR باید به جای ارائه یک مقدار تخمینی، تعداد دقیق مقالات موجود در گروه‌های خبری را گزارش دهد. تعداد دقیق مقالات معمولاً یک بار در روز در حین فرآیند منقضی‌سازی توسط \fBexpirover\fR (که توسط \fBnews.daily\fR فراخوانی می‌شود) به‌روزرسانی می‌گردد، و همچنین با ورود مقالات جدید آپدیت می‌شود، اما در روش‌های ذخیره‌سازی خود-منقضی‌شونده مانند CNFS با لغو یا بازنویسی مقالات لزوماً به‌روز نمی‌شود. .Sp هنگامی که تعداد تخمینی مقالات اکیداً کمتر از \fIgroupexactcount\fR باشد، \fBnnrpd\fR مقالات موجود را بازشماری کرده و عدد دقیق را بازمی‌گرداند. اگر \fIgroupexactcount\fR روی \f(CW\*(C`0\*(C'\fR تنظیم شود، \fBnnrpd\fR همواره بازشماری دقیق انجام خواهد داد. اگر روی \f(CW\*(C`1\*(C'\fR تنظیم شود، هرگز بازشماری نخواهد کرد. .Sp گرچه ارائه شمارش دقیق مقالات اجباری نیست، اما ممکن است برای تشخیص گروه‌های خبری خالی با نمایش عدد دقیق \f(CW\*(C`0\*(C'\fR به جای تخمین \f(CW\*(C`1\*(C'\fR بسیار سودمند باشد (در این وضعیت، کلاینت خبرخوان ممکن است نشان دهد ۱ مقاله در گروه موجود است، سپس تلاش به دریافت مقاله می‌کند و در نهایت هیچ پیامی به کاربر نشان نمی‌دهد). .Sp تنظیم مقادیر بالا برای این پارامتر توصیه نمی‌شود زیرا سرعت پاسخ‌دهی به کلاینت‌های اخبار را به شدت کاهش می‌دهد (شمارش مجدد مقالات به ویژه در گروه‌های شلوغ و پرمقاله فرآیندی زمان‌بر است). .Sp این یک مقدار عددی صحیح است و پیش‌فرض آن \f(CW\*(C`5\*(C'\fR می‌باشد. .IP \fIkey\fR 4 .IX Item "key" در صورت حضور این پارامتر، این گروه access تنها زمانی برای تعیین اختیارات کاربران در نظر گرفته می‌شود که کاربر با گروه auth دارای همین پارامتر \fIkey\fR مطابقت یافته باشد. .IP \fIlocaltime\fR 4 .IX Item "localtime" اگر فیلدهای سرآیند Date یا Injection-Date در مقاله ارسالی وجود نداشته باشد، \fBnnrpd\fR معمولاً این فیلدها را در قالب زمان هماهنگ جهانی (UTC) درج می‌کند. اگر این پارامتر روی true تنظیم شود، فیلد سرآیند Date در قالب منطقه زمانی محلی درج خواهد شد. (با این حال، فیلد سرآیند Injection-Date طبق رفتار پارامتر \fIaddinjectiondate\fR در \fIinn.conf\fR اضافه شده و در قالب UTC باقی خواهد ماند.) این یک پارامتر بولی است و پیش‌فرض آن false می‌باشد. .Sp این پارامتر امکان مدیریت حالتی خاص و نامتداول را فراهم می‌آورد. این گزینه در اصل برای کاربرانی است که \fIمی‌خواهند\fR منطقه زمانی محلی خود را نشان دهند (که می‌تواند در انواع خاصی از بحث‌ها اطلاعات مفیدی باشد)، ولی کلاینت آن‌ها به دلایلی این کار را انجام نمی‌دهد و می‌توانند ترتیبی دهند که سرور در همان منطقه زمانی کلاینت قرار داشته باشد. .IP \fImax_rate\fR 4 .IX Item "max_rate" اگر این پارامتر تعریف شده باشد (و مقداری غیرصفر داشته باشد)، برای کد محدودسازی نرخ تبادل داده در \fBnnrpd\fR استفاده خواهد شد. کلاینت تنها با این حداکثر سرعت (بر حسب بایت در ثانیه) قادر به دانلود خواهد بود. توجه کنید که در صورت استفاده از لایه رمزنگاری، محدودسازی روی جریان داده پیش از رمزنگاری اعمال می‌شود. .IP \fInewsgroups\fR 4 .IX Item "newsgroups" کاربران منطبق با این گروه access مجاز به خواندن و ارسال مقاله در تمامی گروه‌های خبری مطابق با این فهرست جداشده با کاما از الگوهای وایلد‌مت هستند. یک رشته خالی معادل \f(CW\*(C`newsgroups: *\*(C'\fR است؛ اگر این پارامتر تعریف نشود، اتصال رد خواهد شد (مگر اینکه به جای آن از \fIread\fR و/یا \fIpost\fR استفاده شده باشد). .IP \fInewsmaster\fR 4 .IX Item "newsmaster" به عنوان آدرس تماس در پیام راهنمای بازگردانده شده از nnrpd(8) به کار می‌رود، البته در صورتی که پارامتر virtualhost: روی true تنظیم شده باشد. .IP \fIperlfilter\fR 4 .IX Item "perlfilter" اگر روی false قرار گیرد، مقالات ارسالی این کاربران از فیلتر Perl عبور نخواهند کرد، حتی اگر این فیلتر در سیستم فعال باشد. این یک مقدار بولی است و پیش‌فرض آن true می‌باشد. .IP \fIpost\fR 4 .IX Item "post" مشابه پارامتر \fInewsgroups\fR است، اما کلاینت فقط مجوز ارسال مقاله به گروه‌های خبری منطبق را پیدا می‌کند. این پارامتر عموماً در کنار \fIread\fR برای تفکیک الگوهای مجاز خواندن و ارسال به کار می‌رود (معمولاً برای اینکه کاربر اجازه خواندن گروه‌های بیشتری را نسبت به گروه‌های مجاز برای ارسال داشته باشد). این پارامتر نمی‌تواند همراه با پارامتر \fInewsgroups\fR در یک گروه access مشترک قرار گیرد. .IP \fIpythonfilter\fR 4 .IX Item "pythonfilter" اگر روی false قرار گیرد، مقالات ارسالی این کاربران از فیلتر Python عبور داده نمی‌شوند حتی اگر فیلتر فعال باشد. این مقدار بولی است و پیش‌فرض آن true می‌باشد. .Sp این پارامتر در حال حاضر تاثیری ندارد زیرا فیلترینگ Python هنوز در \fBnnrpd\fR پیاده‌سازی نشده است. اگر مایل به فیلتر کردن مقالات با Python هستید، باید از سازوکار تعبیه‌شده در \fBinnd\fR بهره ببرید. .IP \fIread\fR 4 .IX Item "read" مشابه پارامتر \fInewsgroups\fR است، اما کلاینت صرفاً مجوز خواندن مقالات در گروه‌های خبری منطبق را پیدا می‌کند. این پارامتر اغلب همراه با \fIpost\fR برای تعریف گروه‌های فقط‌خواندنی به کار می‌رود؛ این گزینه نمی‌تواند با پارامتر \fInewsgroups\fR در یک گروه access قرار گیرد. (اگر از \fIread\fR استفاده شود و پارامتر \fIpost\fR وجود نداشته باشد، کلاینت دسترسی کاملاً فقط‌خواندنی خواهد داشت.) .IP \fIreject_with\fR 4 .IX Item "reject_with" اگر این پارامتر تنظیم شده باشد، اتصال کلاینت منطبق با این بلوک با ارسال پیام \f(CW\*(C`Permission denied\*(C'\fR حاوی متن این پارامتر (یک رشته بیانگر دلیل) قطع خواهد شد. برخی کلاینت‌های خبرخوان این دلیل را به کاربر نمایش می‌دهند. .IP \fIstrippath\fR 4 .IX Item "strippath" اگر مقدار آن true باشد، فیلد سرآیند Path ارائه‌شده توسط کاربر در مقاله ارسالی حذف می‌شود به جای اینکه در آغاز فیلد سرآیند Path مقاله قرار گیرد. این یک مقدار بولی است و پیش‌فرض آن false می‌باشد. .IP \fIusers\fR 4 .IX Item "users" امتیازات ارائه‌شده توسط این گروه access برای هر هویت کاربری که با این فهرست جداشده با کاما از الگوهای وایلد‌مت مطابقت داشته باشد اعمال می‌گردد. اگر این پارامتر مشخص نشود، گروه access به تمام کاربران اختصاص می‌یابد (و اساساً معادل \f(CW\*(C`users: *\*(C'\fR است). .IP \fIvirtualhost\fR 4 .IX Item "virtualhost" این پارامتر را روی true تنظیم کنید تا \fBnnrpd\fR به گونه‌ای عمل کند که گویی روی سروری با نامی متفاوت از نام اصلی خود در حال اجراست. در این وضعیت پارامتر \fIdomain\fR باید یا در \fIinn.conf\fR یا در همین گروه access مقداردهی شده باشد. بدنه فیلد سرآیند Xref تمامی مقالات و اطلاعات نمای کلی (overview) ارائه‌شده به کلاینت‌ها تغییر خواهد کرد تا چنین به نظر برسد که از سرور تعیین‌شده در \fIdomain\fR هستند، و مقالات ارسالی نیز از آن نام سرور در بدنه‌های سرآیند Message-ID و Injection-Info استفاده خواهند نمود. (علاوه بر این، اگر پرچم \fB\-I\fR به \fBnnrpd\fR ارسال شده باشد، به برنامه‌های ارسال‌کننده پیشنهاد می‌شود شناسه‌های Message-ID حاوی رشته ارائه‌شده با \fB\-I\fR تولید کنند.) .Sp به طور مشابه، فیلدهای سرآیند Path که به کلاینت‌ها نمایش داده شده یا در مقالات ارسالی درج می‌گردند، از مقدار \fIdomain\fR استفاده خواهند کرد (اگر \fIpathhost\fR در گروه access تنظیم نشده باشد یا مقداری همسان با \fIinn.conf\fR داشته باشد) یا از مقدار \fIpathhost\fR استفاده می‌کنند (اگر \fIpathhost\fR در گروه access روی مقداری متفاوت از \fIinn.conf\fR تنظیم شده باشد). .Sp همچنین، بخش دامنه (سمت راست پس از علامت \f(CW\*(C`@\*(C'\fR) در نشانی ایمیل newsmaster که در پیام راهنمای بازگردانده‌شده از \fBnnrpd\fR ذکر می‌شود، در صورتی که \fInewsmaster\fR فاقد بخش دامنه باشد، از مقدار \fIdomain\fR استفاده خواهد کرد. .Sp حداقل یکی از پارامترهای \fIdomain\fR یا \fIpathhost\fR در گروه access باید مقداری متمایز از \fIinn.conf\fR داشته باشد، در غیر این صورت \fBnnrpd\fR با خطا متوقف شده و شروع به کار نخواهد کرد. .Sp توجه داشته باشید که فعال کردن این پارامتر سرور را ملزم می‌سازد تمامی مقالات را پیش از ارائه به کلاینت اصلاح کند، که ممکن است کارایی سیستم را تا حدی کاهش دهد. .PP به علاوه، تمامی پارامترهای زیر در گروه‌های access معتبر هستند و تنظیمات سراسری در \fIinn.conf\fR را بازنویسی می‌نمایند. برای مشاهده توضیحات این پارامترها به inn.conf(5) رجوع کنید: .PP .Vb 7 \& addinjectiondate, addinjectionpostingaccount, \& addinjectionpostinghost, backoff_auth, backoff_db, backoff_k, \& backoff_postfast, backoff_postslow, backoff_trigger, \& checkincludedtext, clienttimeout, complaints, fromhost, \& localmaxartsize, moderatormailer, nnrpdauthsender, nnrpdcheckart, \& nnrpdoverstats, nnrpdposthost, nnrpdpostport, organization, \& pathhost, readertrack, spoolfirst, strippostcc. .Ve .SH "خلاصه (SUMMARY)" .IX Header "SUMMARY" در اینجا خلاصه‌ای از مراحلی که هنگام برقراری اتصال یک کلاینت رخ می‌دهد آمده است: .IP \(bu 4 تمامی گروه‌های auth پیمایش می‌شوند و گروه‌هایی که با شرایط کلاینت مطابقت ندارند (به دلیل عدم تطابق \fIhosts\fR، \fIlocaladdress\fR، \fIrequire_encryption\fR و غیره) کنار گذاشته می‌شوند. .IP \(bu 4 گروه‌های auth باقی‌مانده از انتها به ابتدا بررسی می‌شوند و تلاش می‌شود بر اتصال جاری اعمال گردند. این امر شامل اجرای برنامه‌های \fIres\fR در صورت تعریف شدن، و در غیر این صورت اعمال مقدار \fIdefault\fR است. نخستین گروه auth (از پایین فایل) که یک کاربر معتبر بازگرداند، به عنوان گروه auth فعال برگزیده می‌شود. .IP \(bu 4 اگر هیچ گروه auth کاربر معتبری ارائه ندهد (هیچ‌یک دارای پارامتر \fIdefault\fR نبوده و برنامه \fIres\fR موفقی نداشته باشند) اما برخی از گروه‌های auth دارای خطوط \fIauth\fR باشند (که بیانگر احتمال احراز هویت کاربر و کسب مجوز در مراحل بعدی است)، اتصال فاقد گروه auth معتبر تلقی می‌گردد (بدین معنا که گروه‌های access به کلی نادیده گرفته می‌شوند)، اما اتصال قطع نمی‌شود. در عوض، کد وضعیت ۴۸۰ (به معنای نیاز به احراز هویت) برای تمام درخواست‌ها ارسال می‌شود تا زمانی که کاربر هویت خود را احراز نماید. .IP \(bu 4 هنگامی که کاربر احراز هویت می‌کند، گروه‌های auth مجدداً بررسی می‌شوند و صرفاً گروه‌های منطبقی که حداقل دارای یک خط \fIauth\fR، \fIperl_auth\fR یا \fIpython_auth\fR باشند مد نظر قرار می‌گیرند. این گروه‌های auth از انتها به ابتدا بررسی شده و برنامه‌های \fIauth\fR و اسکریپت‌های \fIperl_auth\fR یا \fIpython_auth\fR اجرا می‌شوند. نخستین گروه auth (از پایین فایل) که یک کاربر معتبر بازگرداند، به عنوان گروه auth فعال انتخاب می‌گردد. .IP \(bu 4 صرف‌نظر از اینکه گروه auth چگونه تعیین شده باشد، به محض برقراری گروه، از آن برای انتساب هویت کاربر با استفاده از خروجی موفق خط \fIres\fR، \fIauth\fR، \fIperl_auth\fR یا \fIpython_auth\fR (یا در صورت لزوم مقدار \fIdefault\fR)، و افزودن \fIdefault-domain\fR در صورت نیاز، استفاده می‌شود. (در حالتی که پارامتر \fIperl_access\fR یا \fIpython_access\fR وجود داشته باشد.) .IP \(bu 4 در نهایت، با پیمایش گروه‌های access از پایین به بالا و یافتن نخستین تطابق، یک گروه access انتخاب می‌گردد. (اگر گروه auth تعیین‌شده حاوی یک خط \fIperl_access\fR یا \fIpython_access\fR باشد، گروه access تولیدشده به شکل پویا توسط اسکریپت جایگزین می‌گردد.) سپس دسترسی‌ها و اختیارات کاربر بر پایه گروه access انتخاب‌شده به او داده می‌شود. .SH "مثال‌ها (EXAMPLES)" .IX Header "EXAMPLES" شاید ساده‌ترین مثال کاربردی از یک فایل کامل \fIreaders.conf\fR این باشد که به تمامی اتصالات از دامنه "example.com"، به جز دستگاه باب (Bob)، دسترسی خواندن و ارسال مقاله در تمامی گروه‌ها داده شود و هیچ دسترسی برای اتصالات سایر مبداها برقرار نگردد: .PP .Vb 4 \& auth example.com { \& hosts: "*.example.com, example.com, !bob.example.com" \& default: "" \& } \& \& access full { \& users: "" \& newsgroups: * \& addcanlockuser: none \& } .Ve .PP توجه داشته باشید که قلمرو دسترسی فوق می‌توانست بدون کلید \fIusers\fR نیز نوشته شود، که در آن صورت برای هر هویت کاربری اعمال می‌شد (هرچند در این مثال، هویت کاربری اختصاص‌یافته به تمام اتصالات منطبق \f(CW\*(C`\*(C'\fR خواهد بود). با این حال توصیه می‌شود یک کلید صریح \fIusers\fR درج گردد تا مشخص باشد بلوک دسترسی دقیقاً برای چه کسانی اعمال می‌شود. .PP از آنجا که تنها قلمرو auth تعریف‌شده صرفاً با میزبان‌های دامنه "example.com" تطابق دارد، اتصالات سایر میزبان‌ها بلافاصله رد خواهند شد. .PP اگر سیستم‌هایی دارید که فقط باید دسترسی خواندن به سرور داشته باشند، می‌توانید مثال بالا را با افزودن یک گروه auth و access دیگر اندکی تغییر دهید: .PP .Vb 4 \& auth lab { \& hosts: "*.lab.example.com" \& default: \& } \& \& access lab { \& users: \& read: * \& } .Ve .PP اگر این تعاریف پس از مثال قبلی در فایل قرار گیرند، برای هر کاربری که از دستگاهی در دامنه lab.example.com متصل شود تقدم خواهند داشت (چرا که در جایگاه پایین‌تری در فایل قرار گرفته‌اند)، و همه صرفاً دسترسی خواندن خواهند داشت و امکان ارسال نخواهند داشت. .PP در اینجا مثالی مشابه برای یک سرور خبری آورده شده است که اتصالات را از هر کجایی می‌پذیرد اما کاربر را ملزم به وارد کردن نام کاربری و گذرواژه می‌سازد. نام کاربری و گذرواژه ابتدا در یک پایگاه‌داده خارجی بررسی شده و سپس از PAM استفاده می‌شود: .PP .Vb 4 \& auth all { \& auth: "ckpasswd \-f /newsusers" \& auth: ckpasswd \& } \& \& access full { \& users: * \& newsgroups: * \& } .Ve .PP هنگامی که کاربر برای نخستین بار متصل می‌شود، هیچ کلید \fIres\fR و هیچ مقدار پیش‌فرضی وجود ندارد، بنابراین هیچ هویت معتبری دریافت نمی‌کند و اتصال با هیچ گروه دسترسی (حتی گروه‌های دارای \f(CW\*(C`users: *\*(C'\fR) تطابق نخواهد یافت. چنین کاربرانی تا زمانی که احراز هویت ننمایند، تنها پاسخ‌های "نیاز به احراز هویت" از \fBnnrpd\fR دریافت خواهند کرد. .PP اگر آن‌ها بعداً احراز هویت کنند، نام کاربری و گذرواژه ابتدا با اجرای \fBckpasswd\fR با گزینه \fB\-f\fR روی یک فایل خارجی از گذرواژه‌های رمزنگاری‌شده بررسی می‌شود و سپس از PAM (در صورت کامپایل شدن INN با پشتیبانی PAM) برای اعتبارسنجی گذرواژه بهره می‌برد (و در صورت شکست، گذرواژه در برابر فیلد گذرواژه بازگردانده‌شده از getpwnam(3) بررسی می‌گردد). اگر هر دوی آن‌ها ناموفق باشند، کاربر همچنان فاقد هویت خواهد بود؛ در غیر این صورت، یک هویت به او تخصیص می‌یابد (معمولاً همان نام کاربری ارائه‌شده با دامنه‌ای در صورت تعریف، هرچند یک احراز هویت‌کننده از نظر فنی می‌تواند هویتی کاملاً متفاوت تعیین کند)، و گروه access با آن تطابق یافته و دسترسی کامل اعطا می‌شود. .PP بررسی چگونگی ترکیب مثال‌های بالا می‌تواند آموزنده باشد؛ گروه‌های عمومی همواره در ابتدا قرار می‌گیرند. ترتیب گروه‌های auth در عمل تفاوتی ایجاد نمی‌کند، چرا که گروه \f(CW\*(C`hosts: example.com\*(C'\fR تنها پیش از ارسال نام کاربری/گذرواژه اعمال می‌شود و گروه \f(CW\*(C`auth: ckpasswd\*(C'\fR صرفاً پس از آن تطابق دارد؛ ترتیب فقط در حالتی اهمیت داشت که هر دو گروه برای هر دو وضعیت صدق می‌کردند. اما ترتیب گروه‌های access در این سناریو حائز اهمیت است، به شرطی که خطوط \fInewsgroups\fR تفاوت داشته باشند؛ گروه access بدون خط \fIusers\fR باید در ابتدا قرار گیرد و گروه دارای \f(CW\*(C`users: \*(C'\fR پس از آن بیاید. .PP در اینجا نمونه‌ای از یک حالت متداول دیگر ارائه شده است: سروری که فقط به اتصالات یک دامنه محلی اجازه اتصال می‌دهد و یک سلسله‌مراتب اضافی دارد که دسترسی به آن نیازمند گذرواژه است. .PP .Vb 5 \& auth "example.com" { \& hosts: "*.example.com" \& auth: "ckpasswd \-f /newsusers" \& default: "anonymous" \& } \& \& access regular { \& newsgroups: "*,!example.restricted.*" \& addcanlockuser: none \& } \& \& access full { \& users: "*,!anonymous" \& newsgroups: * \& } .Ve .PP در این مثال، کاربران احراز هویت‌نشده هویت \f(CW\*(C`anonymous\*(C'\fR را دریافت می‌کنند که تنها با اولین گروه access تطابق دارد و در نتیجه دسترسی به سلسله‌مراتب "example.restricted.*" دریافت نمی‌کند. برای کاربران ناشناس نباید هیچ عنصر اختصاصی در Cancel-Lock تولید شود. هر کاربری که با گذرواژه موجود در فایل \fInewsusers\fR احراز هویت کند، دسترسی کامل به تمامی گروه‌ها را به دست می‌آورد. با این وجود توجه کنید که تنها بلوک احراز هویت به نام‌های میزبان در دامنه example.com محدود شده است؛ اتصالات خارج از آن دامنه هرگز اجازه دسترسی نیافته و فرصتی برای احراز هویت نیز نخواهند داشت. .PP در اینجا یک مثال بسیار جامع‌تر آورده شده است. این سناریو برای سازمانی است که سلسله‌مراتب داخلی "example.*" را صرفاً در اختیار کاربران پوسته (shell) محلی روی دستگاه‌هایی می‌گذارد که به identd(8) آن‌ها می‌توان اطمینان کرد. کاربران Dialup باید نام کاربری و گذرواژه‌ای وارد کنند که در برابر RADIUS ارزیابی می‌شود. کاربران دوردست باید نام کاربری و گذرواژه‌ای ارائه دهند که با پایگاه‌داده سرور اخبار اعتبارسنجی می‌شود. در نهایت، کارمندان مدیر سیستم (کاربران "joe" و "jane") می‌توانند در همه جا پست ارسال کنند (شامل گروه‌های "example.admin.*" که برای بقیه فقط‌خواندنی است)، و از فیلتر Perl معاف هستند. به عنوان یک قابلیت تکمیلی، در ارسال‌های کاربران dialup، فیلد سرآیند Sender با هویت احراز هویت‌شده آن‌ها جایگزین می‌گردد. .PP از آنجا که این سازمان دارای چند گروه خبری مدیریت‌شده (moderated) داخلی است، کادر مدیریت همچنین می‌توانند پیام‌هایی با سرآیند Approved ارسال کنند، اما کاربران عادی این امکان را ندارند. .PP .Vb 5 \& auth default { \& auth: "ckpasswd \-f /newsusers" \& default: \& default\-domain: example.com \& } \& \& auth shell { \& hosts: *.shell.example.com \& res: ident \& auth: ckpasswd \& default: \& default\-domain: shell.example.com \& } \& \& auth dialup { \& hosts: *.dialup.example.com \& auth: radius \& default: \& default\-domain: dialup.example.com \& } \& \& access shell { \& users: *@shell.example.com \& read: * \& post: "*, !example.admin.*" \& } \& \& access dialup { \& users: *@dialup.example.com \& newsgroups: *,!example.* \& nnrpdauthsender: true \& } \& \& access other { \& users: "*@example.com, !@example.com" \& newsgroups: *,!example.* \& } \& \& access fail { \& users: "@*" \& newsgroups: !* \& } \& \& access admin { \& users: "joe@*,jane@*" \& newsgroups: * \& access: "RPA" \& perlfilter: false \& } .Ve .PP به استفاده از دامنه‌های گوناگون برای تفکیک ساده کاربران dialup از کاربران shell توجه کنید. روش دیگر برای این کار استفاده از پارامترهای \fIkey\fR بود، اما این شیوه رشته‌های هویتی ملموس‌تری ایجاد می‌کند. همچنین توجه داشته باشید که گروه دسترسی fail نه تنها اتصالات ناموفق کاربران خارجی را مهار می‌کند، بلکه اتصالات ناموفق کاربران shell و dialup را نیز پیش از احراز هویت پوشش می‌دهد. برای نمونه رشته هویتی تخصیص‌یافته به کاربران dialup پیش از احراز هویت RADIUS، هم با گروه دسترسی dialup و هم با گروه fail همخوانی دارد (زیرا رشته "@dialup.example.com" است)، اما از آنجا که گروه fail در انتها قرار دارد، تقدم پیدا می‌کند. .PP گروه auth مربوط به shell دارای یک پارامتر \fIauth\fR است تا کاربران "joe" و "jane" بتوانند در صورت تمایل، از احراز هویت نام کاربری و گذرواژه برای دستیابی به امتیازات ویژه خود استفاده کنند حتی اگر با حسابی دیگر در ماشین‌های shell وارد شده باشند (یا اگر سرویس ident کار نکند). هنگامی که آن‌ها برای نخستین بار متصل می‌شوند، دسترسی پیش‌فرض آن حساب کاربری را دارند، اما می‌توانند احراز هویت کنند تا دسترسی‌های گسترده خود را به دست آورند. .PP همچنین دقت کنید که اگر کاربران "joe" و "jane" از حساب‌های شخصی خود استفاده کنند، امتیازات ویژه خود را بدون در نظر گرفتن شیوه اتصال (خواه از طریق dialup، ماشین‌های shell یا حتی از راه دور با نام کاربری و گذرواژه) به دست خواهند آورد. .PP در نهایت، در اینجا یک نمونه بسیار ساده از پیکربندی برای یک سرور عمومی برای یک سلسله‌مراتب خبری مشخص آورده شده است. .PP .Vb 4 \& auth default { \& hosts: * \& default: \& } \& \& access default { \& users: \& newsgroups: example.* \& addcanlockuser: none \& } .Ve .PP دقت فرمایید که کلاینت‌ها مجاز به خواندن هیچ گروه دیگری نیستند؛ این محدودیت صرفاً به عنوان یک اقدام احتیاطی برای جلوگیری از دسترسی آن‌ها به گروه‌های مدیریتی یا خواندن پیام‌های کنترلی اعمال شده است. هنگام اجرای چنین سرور عمومی، در نظر داشته باشید که بسیاری از سلسله‌مراتب‌های عمومی ممکن است بعداً دریافت شده و مجدداً به شبکه اصلی یوزنت تزریق شوند؛ بنابراین اکیداً توصیه می‌شود که یک فیلتر Perl یا Python برای رد کردن هرگونه پیام ارسال متقابل (crosspost) شده به خارج از سلسله‌مراتب محلی شما و همچنین پیام‌های حاوی سرآیند Supersedes اجرا کنید. این کار مانع از آن می‌شود که پیام‌های ارسال‌شده در سلسله‌مراتب عمومی شما در صورت درز به بیرون، به سایر بخش‌های شبکه یوزنت لطمه وارد سازند. .PP برای حالت‌های پیچیده‌تر، یا اگر صرفاً ترجیح می‌دهید از یک پایگاه‌داده برای نگهداری اطلاعات احراز هویت و/یا مجوزدهی استفاده نمایید، می‌توانید از اسکریپت‌های Perl یا Python برای احراز هویت پویای کاربران و/یا ایجاد بلوک‌های دسترسی آن‌ها بهره بگیرید. آنگاه می‌توانید تمامی اطلاعات مرتبط (کاربر، گذرواژه، گروه‌های خبری مجاز برای خواندن، گروه‌های خبری مجاز برای ارسال و غیره) را برای نمونه در یک پایگاه‌داده SQLite قرار داده و از یک اسکریپت \fInnrpd_auth.pl\fR یا \fInnrpd_auth.py\fR برای احراز هویت کاربران، و/یا یک اسکریپت \fInnrpd_access.pl\fR یا \fInnrpd_access.py\fR برای اعطای دسترسی استفاده فرمایید. در این صورت، در \fIreaders.conf\fR تنها کافی است تعریف زیر را بگنجانید: .PP .Vb 4 \& auth checkcredentials { \& perl_auth: "/path/to/script/nnrpd_auth.pl" \& perl_access: "/path/to/script/nnrpd_access.pl" \& } .Ve .PP یا: .PP .Vb 4 \& auth checkcredentials { \& python_auth: "nnrpd_auth" \& python_access: "nnrpd_access" \& } .Ve .PP مزیت این اسکریپت‌های خارجی در این است که می‌توانید هر قاعده‌ای را که مایلید برنامه‌نویسی کنید، احتمالاً بر مبنای یک پایگاه‌داده مشترک بین سرویس خبری شما و سایر سرویس‌هایی که به کاربران خود ارائه می‌دهید. مدیریت صدها یا هزاران کاربر با اسکریپت‌های خارجی بسیار ساده‌تر از به‌کارگیری بلوک‌های ثابت \fIreaders.conf\fR و یک فایل متنی ساده (flat file) برای اعتبارسنجی تک‌تک کاربران است. .SH "ملاحظات امنیتی (SECURITY CONSIDERATIONS)" .IX Header "SECURITY CONSIDERATIONS" به طور کلی، در صورت امکان باید از گذرواژه‌های جداگانه برای پروتکل NNTP استفاده شود؛ خود پروتکل NNTP از گذرواژه‌ها در برابر رهگیری محافظت نمی‌کند، و بسیاری از پیاده‌سازی‌ها (از جمله این نرم‌افزار) حساب‌ها را در صورت ورود ناموفق قفل نکرده و مانعی برای حملات حدس گذرواژه ایجاد نمی‌نمایند. بنابراین بهتر است اطمینان حاصل شود که افشای یک گذرواژه حداقل اثرات نامطلوب را بر جای گذارد. .PP احراز هویت با استفاده از دستورات AUTHINFO USER/PASS به صورت رمزنگاری‌نشده در بستر شبکه منتقل می‌گردد. بنابراین باید به ویژه در مورد گذرواژه‌های سیستمی (مانند \f(CW\*(C`auth: ckpasswd \-s\*(C'\fR) نهایت احتیاط به کار گرفته شود. گذرواژه‌ها را می‌توان با استفاده از پروتکل NNTP بر روی TLS/SSL یا از طریق تونل‌های ssh محافظت نمود، و این استفاده را می‌توان با یک پیکربندی اصولی سرور الزامی کرد تا تنها گروه‌های auth خاصی در شرایط امن اعمال شوند. همچنین می‌توان از مکانیزم‌های قدرتمند SASL برای احراز هویت بهره برد. چند توصیه در این زمینه: .IP \(bu 4 برای محدود ساختن اتصالات روی پورت استاندارد NNTP (پورت ۱۱۹) به استفاده از لایه رمزنگاری جهت تطابق برخی (یا تمامی) گروه‌های auth، از پارامتر \fIrequire_encryption\fR استفاده کنید. دقت داشته باشید که یک کلاینت می‌تواند از STARTTLS برای مذاکره بر سر یک اتصال رمزنگاری‌شده TLS استفاده نماید. همچنین می‌توان در حین احراز هویت با AUTHINFO SASL یک لایه امن را مذاکره کرد. .IP \(bu 4 اگر شبکه محلی خود را امن می‌دانید (اما نه اینترنت را)، می‌توانید گروه‌های auth با پارامتر محدودکننده \fIhosts\fR تعریف کنید؛ این گروه‌ها در بالای فایل قرار می‌گیرند و گروه‌های با دامنه شمول سراسری در پایین‌تر قرار خواهند گرفت. .IP \(bu 4 اجرای \fBnnrpd\fR را همراه با پرچم \fB\-S\fR (چه در حالت دیمن با \fB\-D\fR، یا از طریق سوپرسرورهایی نظیر \fBinetd\fR) روی پورت NNTPS (پورت ۵۶۳) برای کلاینت‌هایی که از TLS/SSL پشتیبانی می‌کنند در نظر بگیرید. برای جزئیات نحوه پیکربندی به nnrpd(8) رجوع کنید. شما می‌توانید از پارامتر \fIrequire_encryption\fR یا فلگ \fB\-c\fR برای مشخص ساختن یک فایل \fIreaders.conf\fR مجزا در این سناریو بهره ببرید. .IP \(bu 4 اگر می‌خواهید یک گروه auth را محدود نمایید تا صرفاً با اتصالات لوپ‌بک (loopback) مطابقت پیدا کند (برای کاربرانی که خبرخوان را روی localhost اجرا می‌کنند یا از طریق تونل ssh متصل شده‌اند)، از پارامتر \fIlocaladdress\fR استفاده نمایید. .SH "تاریخچه (HISTORY)" .IX Header "HISTORY" نوشته‌شده توسط Aidan Cully برای InterNetNews. به طور عمده توسط Russ Allbery بازنویسی و گسترش یافته است. .SH "همچنین ببینید (SEE ALSO)" .IX Header "SEE ALSO" auth_krb5(8), ckpasswd(8), inn.conf(5), innd(8), inn\-secrets.conf(5), libinn_uwildmat(3), newsfeeds(5), nnrpd(8).