نام (NAME)

opendkim - فیلتر امضا و اعتبارسنجی DKIM برای MTAها

خلاصه دستور (SYNOPSIS)

opendkim [-A] [-b modes] [-c canon] [-G|-g] [-d domain[,...]] [-D] [-e name] [-f] [-F time] [-k keyfile] [-l] [-L min] [-n] [-o hdrlist] [-O] [-p socketspec] [-P pidfile] [-Q] [-r] [-s selector] [-S signalg] [-t testfiles] [-T secs] [-u userid[:group]] [-v] [-V] [-W] [-x configfile] [-X]

توضیحات (DESCRIPTION)

opendkim استاندارد DKIM را برای امضا و اعتبارسنجی پیام‌های ایمیل بر اساس هر دامنه پیاده‌سازی می‌کند.

opendkim از رابط milter که در ابتدا به عنوان بخشی از نسخه 8.11 از sendmail(8) توزیع شد، برای ارائه خدمات امضا یا اعتبارسنجی DKIM برای ایمیل‌های در حال عبور از یک MTA آگاه از milter استفاده می‌کند.

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

مجموعه‌های داده (DATA SETS)

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

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

نوع مورد استفاده به ساختار رشته مشخصات بستگی دارد. توجه داشته باشید که لزوماً همه این‌ها برای همه نصب‌ها پشتیبانی نمی‌شوند؛ بیشتر آن‌ها به در دسترس بودن یک کتابخانه شخص ثالث خاص در زمان کامپایل وابسته هستند.

به طور خاص:

a): اگر رشته با "file:" شروع شود، بخش باقیمانده رشته به عنوان ارجاع به یک فایل متنی ساده (flat file) در نظر گرفته می‌شود که حاوی عناصر مجموعه داده است، هر کدام در یک خط. اگر یک خط حاوی مقادیر جدا شده با فاصله سفید باشد، آن خط برای تعریف یک کلید و مقدار متناظر آن در نظر گرفته می‌شود. خطوط خالی نادیده گرفته می‌شوند و نویسه هش ("#") نشان‌دهنده شروع یک توضیح است. اگر یک مقدار حاوی چندین مدخل باشد، مدخل‌ها باید با دونقطه (:) از هم جدا شوند.
b): اگر رشته با "refile:" شروع شود، بخش باقیمانده رشته به عنوان مشخص‌کننده فایلی در نظر گرفته می‌شود که شامل مجموعه‌ای از الگوها (یکی در هر خط) و مقادیر مرتبط با آن‌ها است. الگو از ابتدای خط تا اولین فاصله سفید در نظر گرفته می‌شود و بخش بعد از آن فاصله سفید به عنوان مقداری که هنگام تطابق آن الگو استفاده می‌شود، در نظر گرفته می‌شود. الگوها الگوهای ساده وایلدکارت هستند که با تمام متن‌ها مطابقت دارند، به جز اینکه نویسه ستاره ("*") به عنوان وایلدکارت در نظر گرفته می‌شود. اگر یک مقدار شامل چندین مدخل باشد، مدخل‌ها باید با دونقطه جدا شوند.
c): اگر رشته با "db:" شروع شود و برنامه با پشتیبانی از Sleepycat DB کامپایل شده باشد، بخش باقیمانده رشته به عنوان شناسه یک پایگاه داده Sleepycat حاوی کلیدها و مقادیر متناظر در نظر گرفته می‌شود. این موارد ممکن است فقط برای بررسی عضویت در مجموعه داده، یا برای ذخیره کلیدها و مقادیر متناظر استفاده شوند. اگر یک مقدار شامل چندین مدخل باشد، مدخل‌ها باید با دونقطه جدا شوند.
d): اگر رشته با "dsn:" شروع شود و کتابخانه OpenDKIM برای پشتیبانی از آن نوع پایگاه داده کامپایل شده باشد، باقیمانده رشته یک Data Store Name (DSN) است که نوع، پارامترهای مکان و اعتبار دسترسی را برای یک پایگاه داده ODBC یا SQL توصیف می‌کند. DSN به شکل زیر است:

backend://[user[:pwd]@][port+]host/dbase[/key=value[?...]]

که در آن backend نام سازوکار پایگاه داده پشتیبانی‌شده (مانند "mysql")، user و password اطلاعات ورود اختیاری برای پایگاه داده، port و host مقصد اتصال TCP برای اتصال به آن پایگاه داده، dbase نام پایگاه داده قابل دسترسی، و جفت‌های key=value باید حداقل مقادیر "table" ،"keycol" و "datacol" را مشخص کنند که نام جدول، نام ستون برای در نظر گرفتن به عنوان کلید، و نام ستون(ها) برای در نظر گرفتن به عنوان مقادیر (جدا شده با کاما) را تعیین می‌کنند. به عنوان مثال (همگی در یک خط):

mysql:://dbuser:dbpass@3306+dbhost/odkim/table=macros?keycol=host?datacol=v1,v2

یک پایگاه داده MySQL را تعریف می‌کند که روی درگاه 3306 روی میزبان "dbhost" گوش می‌دهد؛ شناسه کاربری "dbuser" و گذرواژه "dbpass" باید برای دسترسی به پایگاه داده استفاده شوند؛ نام پایگاه داده "odkim" است، و داده‌ها در ستون‌های "host" (کلیدها) و "v1" و "v2" (مقادیر) درون جدول "macros" قرار دارند. بنابراین این مثال هنگام یافتن یک تطابق، دو مقدار را برمی‌گرداند.

کلید همچنین ممکن است شامل یک مقدار "filter" باشد که در تمام SQLهای تولیدشده به عنوان یک عبارت AND پس از عبارت WHERE که معیارهای جستجو را اعلام می‌کند، گنجانده خواهد شد. به عنوان مثال، با توجه به مشخصات DSN فوق با یک مقدار "filter" اضافی "ID > 1000"، دستور SQL تولید شده برای پرس‌وجوی "foo" به این شکل خواهد بود:

SELECT v1,v2 FROM macros WHERE host = 'foo' AND ID > 1000

هیچ مقداری در DSN نباید حاوی هیچ‌یک از شش نویسه نشانه‌گذاری (":", "/", "@", "+", "?" و "=") باشد که برای جداسازی بخش‌های DSN استفاده می‌شوند. برای گنجاندن چنین نویسه‌هایی در یک مقدار، آن‌ها را به سبک quoted-printable کدگذاری کنید (به عنوان مثال، "=20" به یک نویسه فاصله تکی تبدیل می‌شود). کدگذاری فاصله‌ها نیز توصیه می‌شود.

e): اگر رشته با "ldap:" ،"ldaps:" یا "ldapi:" شروع شود، فرض می‌شود که مجموعه‌ای جدا شده با فاصله از یک یا چند آدرس URL پروتکل LDAP است که مجموعه‌ای از سرورها را برای پرس‌وجو مشخص می‌کند. اولی باید یک URL کامل LDAP مطابق RFC4516 باشد که الگوی پایه DN و دامنه اختیاری، فیلتر و نام‌های ویژگی‌ها را برای استفاده در پرس‌وجوها مشخص می‌کند. هنگام ساخت الگوی DN یا فیلتر، نشانه‌های ویژه "$d" و "$D" با کلید مورد پرس‌وجو جایگزین می‌شوند و کلید به اجزای جدا شده در نویسه‌های "." تقسیم می‌شود، به طوری که هر جزء با "dc=" آغاز و با "," خاتمه می‌یابد (بنابراین "example.com" به "dc=example,dc=com" تبدیل می‌شود). اگر یک مجموعه داده نیاز به بازگرداندن چندین مقدار داشته باشد، نام‌های ویژگی مناسب باید به ترتیب درست ارائه شوند تا چنین درخواست‌هایی برآورده شوند.
f): اگر رشته با "lua:" شروع شود، فرض می‌شود که به فایلی اشاره دارد که حاوی یک اسکریپت Lua است که هر زمان پرس‌وجویی انجام شود، اجرا می‌شود. کلید مربوط به پرس‌وجو در یک متغیر سراسری به نام "query" قرار می‌گیرد که اسکریپت فراخوانی‌شده می‌تواند به آن دسترسی داشته باشد. اسکریپت ممکن است هر تعداد مقداری را که برای نوع پرس‌وجوی در حال انجام لازم است، بازگرداند.
g): اگر رشته با "memcache:" شروع شود، فرض می‌شود به یک پایگاه داده حافظه موقت ارائه‌شده توسط memcached اشاره دارد. باقیمانده رشته فهرستی از میزبان‌ها است که با کاما از هم جدا شده‌اند و تلاش‌های پرس‌وجو باید به آن‌ها ارسال شود، که هر کدام به صورت اختیاری با ":" و یک شماره درگاه دنبال می‌شوند؛ آن فهرست باید با یک نویسه اسلش ("/") و رشته‌ای که به عنوان پیشوند پرس‌وجوهای ارسالی به حافظه موقت استفاده می‌شود، دنبال شود. به عنوان مثال:

memcache:localhost,otherhost/keyname

این پیکربندی از "localhost" یا "otherhost" برای انجام پرس‌وجوها استفاده می‌کند و تمام رشته‌های ارسال‌شده به مجموعه داده با پیشوند "keyname:" آغاز خواهند شد.

h): اگر رشته شامل هیچ‌یک از این پیشوندها نباشد اما به ".db" ختم شود، همان‌طور که در بالا توضیح داده شد یک پایگاه داده Sleepycat DB در نظر گرفته می‌شود (در صورتی که پشتیبانی از آن در زمان کامپایل فعال شده باشد).
i): اگر رشته شامل هیچ‌یک از این پیشوندها نباشد اما با نویسه اسلش ("/") شروع شود، همان‌طور که در بالا توضیح داده شد یک فایل متنی ساده (flat file) در نظر گرفته می‌شود.
j): اگر رشته با "csl:" شروع شود، رشته به عنوان یک فهرست جدا شده با کاما همان‌طور که در بند m در زیر توضیح داده شده در نظر گرفته می‌شود.
k): اگر رشته با "erlang:" شروع شود، فرض می‌شود که به تابعی اشاره دارد که فراخوانی آن به گره(های) مشخص‌شده توزیع‌شده Erlang ارسال می‌شود. ساختار مشخصات به شکل زیر است:

erlang:node@host[,...]:cookie:module:function

که در آن node[,...] فهرستی از گره‌های Erlang جدا شده با کاما است، cookie کوکی برای گره‌های شناخته‌شده راه‌اندازی توزیع‌شده Erlang است، module نام ماژول Erlang است که تابع مورد فراخوانی در آن قرار دارد، و function نام تابع Erlang برای فراخوانی است. به عنوان مثال (همگی در یک خط):

erlang:mynode@myhost,myothernode@myotherhost:chocolate:dkim:lookup

با اتصال به "mynode@myhost" یا "myothernode@myotherhost" (اتصال به گره‌ها به ترتیب امتحان می‌شود) با استفاده از "chocolate" به عنوان کوکی، به محیط توزیع‌شده Erlang ملحق می‌شود و از تابع "dkim:lookup/1" برای جستجوها استفاده می‌کند.

l): اگر رشته با "mdb:" شروع شود، به دایرکتوری‌ای اشاره دارد که حاوی یک پایگاه داده حافظه ارائه‌شده توسط libmdb از OpenLDAP است.
m): در هر حالت دیگر، رشته به عنوان یک فهرست جدا شده با کاما در نظر گرفته می‌شود. عناصر موجود در فهرست یا عناصر داده ساده‌ای هستند که بخشی از مجموعه را تشکیل می‌دهند، یا در مورد مدخلی به شکل "x=y"، همان‌طور که در بالا توضیح داده شد به صورت جفت‌های کلید-مقدار ذخیره می‌شوند.

گزینه‌ها (OPTIONS)

-A: راه‌اندازی مجدد خودکار در صورت بروز خطا. با احتیاط استفاده شود؛ اگر فیلتر بلافاصله پس از شروع به کار با شکست مواجه شود، این امر می‌تواند باعث یک حلقه تکرار فشرده fork(2) شود. این وضعیت را می‌توان با استفاده از برخی مقادیر در فایل پیکربندی برای محدود کردن راه‌اندازی مجدد تعدیل کرد. به opendkim.conf(5) مراجعه کنید.
-b modes: حالت‌های کاری را انتخاب می‌کند. modes ترکیبی از نویسه‌ها است که نشان می‌دهد چه حالت(هایی) از عملیات مورد نظر است. حالت‌های معتبر عبارتند از s (امضاکننده) و v (اعتبارسنج). مقدار پیش‌فرض sv است مگر در حالت آزمایشی (به -t در زیر مراجعه کنید) که در آن صورت پیش‌فرض v است.
-c canon: روش(های) قانونمندسازی (canonicalization) را برای استفاده هنگام امضای پیام‌ها انتخاب می‌کند. هنگام اعتبارسنجی، هدر DKIM-Signature: پیام، روش قانونمندسازی را مشخص می‌کند. مقادیر شناخته‌شده عبارتند از relaxed و simple همان‌طور که توسط مشخصات DKIM تعریف شده است. مقدار پیش‌فرض simple است. مقدار ممکن است شامل دو قانونمندسازی مختلف باشد که با یک نویسه اسلش ("/") از هم جدا شده‌اند، که در این حالت اولی بر هدرها و دومی بر بدنه پیام اعمال خواهد شد.
-d dataset: مجموعه‌ای از دامنه‌ها که ایمیل‌های آن‌ها باید توسط این فیلتر امضا شوند. ایمیل‌های دامنه‌های دیگر به جای امضا شدن، اعتبارسنجی خواهند شد.
-D: زیردامنه‌های فهرست‌شده توسط گزینه -d را نیز همانند خود دامنه‌ها امضا می‌کند.
-e name: مقدار name را از فایل پیکربندی (در صورت وجود) استخراج می‌کند.
-f: به طور معمول opendkim یک فرآیند منشعب (fork) کرده و بلافاصله خارج می‌شود و سرویس را در پس‌زمینه در حال اجرا می‌گذارد. این فلگ آن رفتار را متوقف می‌کند تا برنامه در پیش‌زمینه اجرا شود.
-g: پیمایش SigningTable را برای کلیدهای مفقود در KeyTable نادیده می‌گیرد. این گزینه بر تنظیم پیکربندی CheckSigningTable در opendkim.conf(5) ارجحیت دارد.
-G: پیمایش اجباری SigningTable برای یافتن کلیدهای مفقود در KeyTable هنگام بارگیری پیکربندی، با اولویت بر گزینه CheckSigningTable در فایل پیکربندی. در ترکیب با گزینه -n که در زیر توضیح داده شده است، می‌توانید فقط عملیات بررسی را انجام دهید.
-F time: زمان ثابتی را برای استفاده هنگام تولید امضاها مشخص می‌کند. نادیده گرفته می‌شود مگر اینکه در ترکیب با -t (به زیر مراجعه کنید) استفاده شود. زمان باید در قالب معمول time_t یونیکس (ثانیه‌ها از مبدا زمان epoch) بیان شود.
-k keyfile: محل یک کلید خصوصی با فرمت PEM را مشخص می‌کند که برای امضای تمام پیام‌ها استفاده می‌شود. در صورتی که به یک فایل پیکربندی ارجاع داده شود که KeyTable را تعریف می‌کند، این گزینه نادیده گرفته می‌شود.
-l: هرگونه فعالیت مهم را از طریق فراخوانی به syslog(3) ثبت (log) می‌کند.
-L min[%+]: به کد اعتبارسنجی دستور می‌دهد تا پیام‌هایی را که برای آن‌ها امضای ناقص دریافت شده است، رد کند. سه ساختار ممکن وجود دارد: min نشان می‌دهد که حداقل min بایت از پیام باید امضا شده باشد (یا اگر اندازه پیام کمتر از min باشد، تمام آن باید امضا شود)؛ min% الزام می‌کند که حداقل min درصد از پیام دریافتی باید امضا شده باشد؛ و min+ به این معنی که نباید بیش از min بایت داده امضا‌نشده به انتهای پیام پیوست شده باشد تا معتبر تلقی شود.
-n: فایل پیکربندی و آرگومان‌های خط فرمان را تجزیه کرده، خطاهای یافت‌شده را گزارش می‌دهد و سپس خارج می‌شود. مقدار خروج در صورتی که فیلتر بتواند بدون مشکل راه‌اندازی شود 0 و در غیر این صورت غیر صفر خواهد بود.
-o dataset: فهرستی از هدرها را مشخص می‌کند که باید هنگام تولید امضاها حذف شوند. اگر مدخلی در این فهرست، نام هدری را ذکر کند که توسط مشخصات DKIM الزامی شده است، آن مدخل نادیده گرفته می‌شود. مجموعه‌ای از هدرها در مشخصات DKIM به عنوان "نباید امضا شوند" (SHOULD NOT) فهرست شده‌اند؛ فهرست پیش‌فرض برای این پارامتر شامل آن هدرها است (Return-Path, Received, Comments, Keywords, Bcc, Resent-Bcc و DKIM-Signature). برای عدم حذف هیچ هدری، به سادگی از رشته "-" (یا هر رشته‌ای که با هیچ هدری مطابقت نداشته باشد) استفاده کنید.
-O: هرگونه فعالیت مهم را در خروجی استاندارد ثبت (log) می‌کند.
-p socketspec: سوکت مورد نیاز برای ایجاد توسط فیلتر را جهت دریافت اتصالات از sendmail(8) به منظور ارائه خدمات مشخص می‌کند. socketspec در یکی از دو قالب زیر است: local:path که یک سوکت دامنه یونیکس (UNIX domain socket) در path مشخص‌شده ایجاد می‌کند، یا inet:port[@host] یا inet6:port[@host] که یک سوکت TCP در port مشخص‌شده با استفاده از خانواده پروتکل درخواستی ایجاد می‌کند. اگر host به عنوان نام میزبان یا آدرس IP ارائه نشود، سوکت روی تمام رابط‌ها گوش فرا می‌دهد. یک آدرس IP دقیق باید در براکت قرار گیرد. اگر هیچ نوع سوکتی مشخص نشود، local فرض می‌شود، به این معنی که پارامتر به عنوان مسیری تفسیر می‌شود که سوکت باید در آن ایجاد شود. این پارامتر در اینجا یا در فایل پیکربندی الزامی است.
-P pidfile: فایلی را مشخص می‌کند که فیلتر باید شناسه فرآیند (PID) خود را در هنگام شروع در آن بنویسد.
-Q: حالت آزمایشی پرس‌وجو. فیلتر دو خط را از ورودی استاندارد می‌خواند؛ یکی شامل شرح پایگاه داده‌ای که باید باز شود و دیگری حاوی رشته‌ای به شکل "q/n" که در آن "q" پرس‌وجوی مورد نظر و "n" تعداد فیلدهای قابل بازیابی است.
-r: تمام پیام‌ها را برای انطباق با الزامات تعداد هدرهای RFC5322 بررسی می‌کند. پیام‌های غیر منطبق رد می‌شوند.
-s selector: نام انتخاب‌گر (selector) را برای استفاده هنگام امضای پیام‌ها تعریف می‌کند. برای جزئیات به مشخصات DKIM مراجعه کنید.
-S signalg: الگوریتم امضا را برای استفاده هنگام تولید امضاها انتخاب می‌کند. برای مشاهده فهرست الگوریتم‌های پشتیبانی‌شده از دستور 'opendkim -V' استفاده کنید. مقدار پیش‌فرض rsa-sha256 است (در صورت در دسترس بودن)، در غیر این صورت rsa-sha1 خواهد بود.
-t testfiles: یک یا چند پیام با قالب RFC5322 موجود در testfiles را ارزیابی (اعتبارسنجی) کرده و خارج می‌شود. مقدار testfiles باید فهرستی جدا شده با کاما از یک یا چند نام فایل باشد که یکی از آن‌ها در صورتی که پیام باید از ورودی استاندارد خوانده شود، می‌تواند "-" باشد.
-T secs: مهلت زمانی (timeout) پروتکل DNS را بر حسب ثانیه تنظیم می‌کند. مقدار 0 باعث انتظار نامحدود می‌شود. مقدار پیش‌فرض 5 است. در صورت عدم استفاده از بسته تحلیل‌گر ناهمگام (asynchronous resolver) نادیده گرفته می‌شود. همچنین به بخش "نکات" در زیر مراجعه کنید.
-u userid[:group]: تلاش می‌کند قبل از شروع عملیات، به userid مشخص‌شده تغییر هویت دهد. تمام گروه‌ها و شناسه گروه اصلی userid نام‌برده به فرآیند اختصاص می‌یابد مگر اینکه یک group جایگزین مشخص شده باشد. برای اطلاعات بیشتر به بخش "مجوزهای فایل" مراجعه کنید.
-v: میزان جزئیات خروجی را در طول حالت آزمایشی افزایش می‌دهد (به -t در بالا مراجعه کنید). برای درخواست مقادیر بیشتر خروجی، ممکن است بیش از یک بار مشخص شود.
-V: شماره نسخه و الگوریتم‌های قانونمندسازی و امضای پشتیبانی‌شده را چاپ کرده و بدون انجام هیچ کار دیگری خارج می‌شود.
-W: در صورت فعال بودن ثبت گزارش (به -l در بالا مراجعه کنید)، گزارش‌های بسیار مفصلی درباره منطق تصمیم‌گیری فیلتر برای امضا یا اعتبارسنجی یک پیام صادر می‌کند. حرف "W" مخفف "!Why" (چرا؟!) است، زیرا منطق تصمیم‌گیری پیچیده است و می‌تواند برای مدیرانی که با عملکرد آن آشنا نیستند گیج‌کننده باشد. شرحی از نحوه اتخاذ این تصمیم را می‌توان در بخش "نحوه عملکرد" این سند یافت. این امر باعث افزایش چشمگیر حجم داده‌های گزارش تولیدشده برای هر پیام می‌شود، بنابراین باید به استفاده برای اشکال‌زدایی محدود شود و برای عملیات عمومی فعال نشود.
-x configfile: فایل پیکربندی نام‌برده را می‌خواند. برای جزئیات به صفحه راهنمای opendkim.conf(5) مراجعه کنید. مقادیر موجود در فایل پیکربندی هنگام ارائه معادل‌های آن‌ها در خط فرمان بازنویسی می‌شوند تا زمانی که بارگیری مجدد پیکربندی رخ دهد. بخش "نحوه عملکرد" نحوه آغاز بارگیری مجدد را شرح می‌دهد. پیش‌فرض خواندن یک فایل پیکربندی از /etc/opendkim/opendkim.conf در صورت وجود است، یا در غیر این صورت اعمال مقادیر پیش‌فرض برای همه گزینه‌ها است.
-X: آیتم‌های فایل پیکربندی را که در داخل برنامه به عنوان "منسوخ" (deprecated) علامت‌گذاری شده‌اند، تحمل می‌کند. به طور معمول وقتی یک آیتم فایل پیکربندی از بسته حذف می‌شود، حداقل برای یک چرخه انتشار کامل به این شکل نشانه‌گذاری می‌شود. وجود یک آیتم منسوخ در فایل پیکربندی معمولاً باعث بازگرداندن خطا توسط فیلتر و امتناع از راه‌اندازی می‌شود. تنظیم این فلگ به فیلتر اجازه راه‌اندازی می‌دهد و یک هشدار ثبت می‌شود. در برخی از نسخه‌های بعدی که آیتم به طور کامل حذف شود، خطای متفاوتی ایجاد می‌شود و راه‌اندازی فیلتر امکان‌پذیر نخواهد بود. استفاده از این فلگ توصیه نمی‌شود؛ زیرا می‌تواند عملاً یک تغییر بزرگ در پیکربندی را با پیامدهای امنیتی جدی پنهان کند.

نحوه عملکرد (OPERATION)

یک پیام اعتبارسنجی خواهد شد مگر اینکه با معیارهای امضا مطابقت داشته باشد، که عبارتند از: (۱) دامنه در آدرس From: (در صورت وجود) باید توسط سوئیچ خط فرمان -d یا تنظیم Domain در فایل پیکربندی فهرست شده باشد، و (۲) (الف) کلاینت متصل به MTA احراز هویت کرده باشد، یا (ب) کلاینت متصل به MTA باید در فایل ارجاع داده شده توسط تنظیم InternalHosts در فایل پیکربندی فهرست شده باشد (یا در فهرست پیش‌فرض آن گزینه باشد)، یا (ج) کلاینت باید به یک درگاه دیمن متصل باشد که توسط تنظیم MTAs در فایل پیکربندی نام‌گذاری شده است، یا (د) MTA باید یک یا چند ماکرو تنظیم کرده باشد که با معیارهای تعیین شده توسط تنظیم MacroList در فایل پیکربندی مطابقت دارد.

برای مورد (الف) در بالا، آزمایش این است که آیا ماکروی "{auth_type}" در MTA تنظیم شده و حاوی هرگونه مقدار غیرخالی است یا خیر. این بدان معنی است که MTA باید مقدار آن ماکرو را قبل یا در طول مرحله پایان هدر (EOH) به فیلتر منتقل کند تا مقدار آن آزمایش شود. برای جزئیات، اسناد پیکربندی MTA خود را بررسی کنید.

برای مورد (۱) در بالا، سایر فیلدهای هدر را می‌توان با استفاده از تنظیم پیکربندی SenderHeaders انتخاب کرد. برای اطلاعات بیشتر به opendkim.conf(5) مراجعه کنید.

هنگام امضای یک پیام، یک هدر DKIM-Signature: به ابتدای پیام اضافه می‌شود. امضا با استفاده از کلید خصوصی ارائه شده محاسبه می‌شود. شما باید از نسخه‌ای از sendmail(8) استفاده کنید که به اندازه کافی جدید باشد تا بتواند عملیات افزودن هدر به ابتدا را انجام دهد (نسخه 8.13.0 یا بالاتر).

هنگام اعتبارسنجی یک پیام، یک هدر Authentication-Results: به ابتدا اضافه می‌شود تا وجود یک امضا و اینکه آیا با استفاده از کلید عمومی ارائه‌شده توسط کارگزار نام فرستنده در برابر بدنه پیام قابل تایید است یا خیر را نشان دهد. مقدار این هدر می‌تواند توسط عامل‌های کاربر ایمیل (MUA) برای مرتب‌سازی یا دور انداختن پیام‌هایی که امضا نشده‌اند یا قابل اعتبارسنجی نبوده‌اند استفاده شود.

با دریافت سیگنال SIGHUP یا SIGUSR1، اگر فیلتر با یک فایل پیکربندی راه‌اندازی شده باشد، فایل مجدداً خوانده شده و مقادیر جدید استفاده می‌شوند. توجه داشته باشید که هرگونه بازنویسی خط فرمان ارائه‌شده در زمان راه‌اندازی با انجام این کار از بین خواهد رفت. همچنین، مقادیر فایل پیکربندی زیر (و موارد خط فرمان متناظر آن‌ها، در صورت وجود) از طریق این فرآیند بازخوانی نمی‌شوند: AutoRestart (-A), AutoRestartCount, AutoRestartRate, Background, MilterDebug, PidFile (-P), POPDBFile, Quarantine (-q), QueryCache, Socket (-p), StrictTestMode, TestPublicKeys, UMask, UserID (-u). فیلتر به طور خودکار فایل پیکربندی را برای تغییرات بررسی نکرده و بازخوانی نمی‌کند.

ماکروهای MTA (MTA MACROS)

opendkim از سه ماکروی ارائه‌شده توسط MTA، به علاوه هر ماکروی مورد نیاز پیکربندی استفاده می‌کند. سه ماکروی پایه عبارتند از: "i" (شناسه پاکت، همچنین به عنوان شناسه وظیفه یا شناسه صف شناخته می‌شود)، که برای ثبت گزارش استفاده می‌شود؛ "daemon_name" (نام نمادین داده شده به نمونه MTA که اتصال را پذیرفته است)، که هنگام انجام آزمایش‌ها در برابر هر تنظیم "MTAs" استفاده می‌شود؛ و "auth_type"، که برای تعیین اینکه آیا کلاینت SMTP نزد MTA احراز هویت کرده است یا خیر استفاده می‌شود. اگر MTA آن‌ها را در اختیار opendkim قرار ندهد، این فیلتر قادر به اعمال آزمایش‌های متناظر یا ثبت گزارش‌های مفید نخواهد بود. برای تعیین نحوه تنظیم پیکربندی MTA خود در صورتی که برخی یا همه این‌ها در دسترس نیستند، با اسناد آن مشورت کنید.

مجوزهای فایل (FILE PERMISSIONS)

هنگامی که فیلتر به عنوان کاربر ارشد (superuser) راه‌اندازی می‌شود و تنظیم UserID (-u) استفاده می‌شود، فیلتر امتیازات ریشه خود را پس از انجام مراحل زیر با تغییر به کاربر مشخص‌شده واگذار می‌کند: (۱) فایل پیکربندی (در صورت وجود) بارگیری می‌شود؛ (۲) اگر از تنظیم KeyFile (-k) استفاده شود، آن کلید در حافظه بارگیری می‌شود؛ (۳) تمام مجموعه‌های داده در فایل پیکربندی باز می‌شوند، و مواردی که بر اساس فایل‌های متنی ساده هستند نیز در حافظه خوانده می‌شوند؛ و (۴) اگر ChangeRootDirectory تنظیم شده باشد، ریشه فرآیند به آن دایرکتوری تغییر می‌کند. این بدان معنی است که در هنگام بارگیری مجدد پیکربندی، فیلتر به این فایل‌ها یا فایل پیکربندی به عنوان کاربر ارشد دسترسی نخواهد داشت (و احتمالاً از یک ریشه متفاوت)، و هر فایل کلیدی که توسط KeyTable ارجاع داده شده است نیز توسط کاربر جدید دسترسی خواهد یافت.

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

محیط (ENVIRONMENT)

متغیر(های) محیطی زیر را می‌توان برای تنظیم رفتار این فیلتر استفاده کرد:

DKIM_TMPDIR: دایرکتوری مورد استفاده هنگام ایجاد فایل‌های موقت. پیش‌فرض /tmp است.

نکات (NOTES)

هنگام استفاده از مهلت‌های زمانی DNS (به گزینه -T در بالا مراجعه کنید)، مطمئن شوید که از مهلت زمانی بزرگتر از مهلت مورد استفاده برای تعامل بین sendmail و فیلتر استفاده نکنید. در غیر این صورت، MTA ممکن است در حالی که منتظر پاسخ از فیلتر است که آن هم به نوبه خود همچنان منتظر پاسخ DNS است، پردازش پیام را لغو کند.

انتظار می‌رود پایگاه داده احراز هویت POP یک فایل Sleepycat DB (که قبلاً با نام Berkeley DB شناخته می‌شد) در قالب هش با کلیدهای حاوی آدرس IP به صورت متن و بدون NULL پایانی باشد. مقادیر این رکوردها بررسی نمی‌شوند؛ فقط وجود چنین رکوردهایی مورد توجه است. فیلتر تلاش می‌کند تا قبل از خواندن از پایگاه داده، یک قفل مشترک (shared lock) بر روی آن ایجاد کند، بنابراین هر برنامه‌ای که در پایگاه داده می‌نویسد باید استفاده از قفل خود را به حداقل برساند، در غیر این صورت به نظر می‌رسد این فیلتر در حالی که منتظر تکمیل عملیات قفل است، معلق شده است.

ویژگی‌هایی که شامل مشخص کردن آدرس‌های IPv4 یا بلوک‌های CIDR هستند، از تابع inet_addr(3) برای تجزیه آن اطلاعات استفاده خواهند کرد. کاربران باید با نحوه مدیریت موارد غیر بدیهی توسط آن تابع آشنا باشند (به عنوان مثال، "192.0.2/24" و "192.0.2.0/24" یکسان نیستند).