TRANSPORT(5) File Formats Manual TRANSPORT(5)

transport - قالب جدول انتقال (transport) در Postfix

postmap /etc/postfix/transport
postmap -q "string" /etc/postfix/transport
postmap -q - /etc/postfix/transport <inputfile


جدول اختیاری transport(5) یک نگاشت از نشانی‌های ایمیل به سازوکارهای انتقال تحویل پیام و مقصدهای گام بعدی (next-hop) را مشخص می‌کند. سازوکارهای انتقال تحویل پیام مانند local یا smtp در فایل master.cf تعریف می‌شوند، و مقصدهای گام بعدی معمولاً نام میزبان یا نام دامنه هستند. این جدول توسط دیمن trivial-rewrite(8) جستجو می‌شود.

این نگاشت، انتخاب پیش‌فرض transport:nexthop را که درون Postfix تعبیه شده است لغو می‌کند (بازنویسی می‌کند):

این مقدار پیش‌فرض برای تحویل نهایی به دامنه‌های فهرست‌شده با mydestination، و برای مقصدهای [ipaddress] که با $inet_interfaces یا $proxy_interfaces مطابقت دارند، است.

به ترتیب اولویت نزولی، مقصد nexthop از transport_maps، local_transport، یا از دامنه گیرنده گرفته می‌شود.

این مقدار پیش‌فرض برای تحویل نهایی به دامنه‌های فهرست‌شده با virtual_mailbox_domains است.

به ترتیب اولویت نزولی، مقصد nexthop از transport_maps، virtual_transport، یا از دامنه گیرنده گرفته می‌شود.

این مقدار پیش‌فرض برای تحویل از راه دور به دامنه‌های فهرست‌شده با relay_domains است.

به ترتیب اولویت نزولی، مقصد nexthop از transport_maps، relay_transport، sender_dependent_relayhost_maps، relayhost، یا از دامنه گیرنده گرفته می‌شود.

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

به ترتیب اولویت نزولی، مقصد nexthop از transport_maps، sender_dependent_default_transport_maps، default_transport، sender_dependent_relayhost_maps، relayhost، یا از دامنه گیرنده گرفته می‌شود.

به‌طور معمول، جدول transport(5) به عنوان یک فایل متنی مشخص می‌شود که به عنوان ورودی دستور postmap(1) برای ایجاد یک فایل نمایه‌سازی‌شده جهت جستجوی سریع به کار می‌رود.

دستور «postmap /etc/postfix/transport» را برای بازسازی فایل نمایه‌سازی‌شده از نوع پیش‌فرض پس از تغییر فایل متنی اجرا کنید، یا «postmap type:/etc/postfix/transport» را برای تعیین صریح یک نوع اجرا نمایید.

نوع پیش‌فرض فایل نمایه‌سازی‌شده با پارامتر default_database_type پیکربندی می‌شود. بسته به پلتفرم، این مقدار ممکن است یکی از موارد lmdb:، cdb:، hash: یا dbm: (بدون «:» پایانی) باشد.

هنگامی که جدول از روش‌های دیگر مانند NIS، LDAP یا SQL ارائه می‌شود، همان جستجوهایی که برای فایل‌های نمایه‌سازی‌شده معمولی انجام می‌شود، صورت می‌گیرد. مدیریت چنین پایگاه‌های داده‌ای خارج از حیطه کاری Postfix است.

از طرف دیگر، جدول می‌تواند به عنوان یک نگاشت عبارت منظم ارائه شود که الگوها به صورت عبارات منظم داده می‌شوند، یا جستجوها می‌توانند به یک سرور مبتنی بر TCP هدایت شوند. در این موارد، جستجوها به روشی اندکی متفاوت انجام می‌شوند که در ادامه در بخش‌های «جدول‌های عبارات منظم» یا «جدول‌های مبتنی بر TCP» شرح داده شده است.

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

قالب ورودی برای دستور postmap(1) به شرح زیر است:

هنگامی که pattern با نشانی یا دامنه گیرنده تطابق داشته باشد، از result متناظر استفاده می‌شود.
خطوط خالی و توضیحات
خطوط خالی و خطوطی که تنها حاوی فاصله‌اند نادیده گرفته می‌شوند، همچنین خطوطی که اولین نویسه غیرفاصله‌ای آن‌ها یک «#» است.
متن چندخطی
یک خط منطقی با متنی غیر از نویسه‌های فاصله آغاز می‌شود. خطی که با فاصله آغاز شود، ادامه یک خط منطقی به شمار می‌آید.

مؤلفه pattern یک نشانی ایمیل، یک نام دامنه، یا سلسله‌مراتبی از نام دامنه را مشخص می‌کند، همان‌گونه که در بخش «ترتیب جستجو در جدول» شرح داده شده است.

مقدار result به شکل transport:nexthop است و نحوه یا مکان تحویل ایمیل را مشخص می‌کند. این موضوع در بخش «قالب نتیجه» توضیح داده شده است.

در جستجو از فایل‌های نمایه‌سازی‌شده مانند DB یا DBM، یا از جدول‌های تحت شبکه مانند NIS، LDAP یا SQL، الگوها به ترتیبی که در زیر آمده است بررسی و آزمایش می‌شوند:

تحویل ایمیل مربوط به user+extension@domain از طریق transport به nexthop.
تحویل ایمیل مربوط به user@domain از طریق transport به nexthop.
تحویل ایمیل مربوط به domain از طریق transport به nexthop.
.domain transport:nexthop
تحویل ایمیل مربوط به هر زیردامنه‌ای از domain از طریق transport به nexthop. این مورد تنها زمانی اعمال می‌شود که رشته transport_maps در تنظیمات پیکربندی parent_domain_matches_subdomains فهرست نشده باشد. در غیر این صورت، یک نام دامنه هم با خودش و هم با زیردامنه‌هایش تطابق می‌یابد.
* transport:nexthop
الگوی ویژه * نشان‌دهنده هر نشانی دلخواهی است (یعنی به عنوان الگوی عام عمل می‌کند و مختص جدول‌های انتقال Postfix است).

یادداشت ۱: نشانی گیرنده تهی (null) به صورت $empty_address_recipient@$myhostname جستجو می‌شود (پیش‌فرض: mailer-daemon@hostname).

یادداشت ۲: جستجوی user@domain یا user+extension@domain در نسخه 2.0 و بالاتر Postfix در دسترس است.

نتیجه جستجو به شکل transport:nexthop است. فیلد transport سازوکار انتقال تحویل ایمیل مانند smtp یا local را مشخص می‌کند. فیلد nexthop مشخص می‌سازد که ایمیل در کجا و چگونه تحویل داده شود.

فیلد transport نام یک سازوکار انتقال تحویل ایمیل را مشخص می‌کند (اولین نام از ورودی یک سرویس تحویل ایمیل در فایل master.cf در Postfix).

فیلد nexthop معمولاً یک دامنه گیرنده یا نام میزبان را مشخص می‌کند. در مورد کلاینت SMTP/LMTP در Postfix، فیلد nexthop می‌تواند شامل فهرستی از مقصدهای nexthop باشد که با کاما یا نویسه فاصله از هم جدا شده‌اند (Postfix نسخه 3.5 و بالاتر).

ساختار نوشتاری یک مقصد nexthop وابسته به سازوکار انتقال (transport) است. در SMTP، سرویس روی یک درگاه غیرپیش‌فرض را به صورت host:service مشخص کنید، و جستجوهای DNS برای رکورد MX (مبادله‌گر ایمیل) را با [host] یا [host]:port غیرفعال نمایید. هنگامی که به جای نام میزبان از نشانی IP استفاده می‌کنید، شکل [] الزامی است.

یک فیلد تهی (null) برای transport و فیلد تهی برای nexthop به معنای «تغییر نده» است: از همان سازوکار تحویل و اطلاعات nexthop استفاده کن که در صورت عدم وجود کل جدول انتقال استفاده می‌شدند.

یک فیلد غیرتهی برای transport همراه با فیلد تهی برای nexthop، اطلاعات nexthop را به دامنه گیرنده بازنشانی می‌کند.

یک فیلد تهی برای transport همراه با فیلد غیرتهی برای nexthop، اطلاعات transport را تغییر نمی‌دهد.

برای تحویل مستقیم ایمیل‌های داخلی، در حالی که برای تمام ایمیل‌های دیگر از یک رله ایمیل (mail relay) استفاده می‌شود، یک مدخل تهی برای مقصدهای داخلی تعیین کنید (سازوکار تحویل یا اطلاعات nexthop را تغییر ندهید) و برای تمام مقصدهای دیگر از یک الگوی عام (wildcard) استفاده کنید.

my.domain    :
.my.domain   :
*            smtp:outbound-relay.my.domain

برای ارسال ایمیل‌های مربوط به example.com و زیردامنه‌های آن از طریق انتقال uucp به میزبان UUCP با نام example:

example.com      uucp:example
.example.com     uucp:example

هنگامی که هیچ مقصد nexthop مشخص نشده باشد، Postfix از موارد زیر استفاده می‌کند (به ترتیب اولویت از کم به زیاد): دامنه گیرنده، مقصد nexthop مشخص‌شده با relayhost، با sender_dependent_relayhost_maps (تنها برای تحویل‌های راه دور)، با سازوکار انتقال مربوط به رده دامنه نشانی (بخش توضیحات در بالا را ببینید)، یا با sender_dependent_default_transport_maps (تنها برای تحویل‌های راه دور). برای نمونه، مثال زیر ایمیل برای user@example.com را از طریق انتقال slow به یک مبادله‌گر ایمیل برای example.com هدایت می‌کند. سازوکار انتقال slow می‌تواند طوری پیکربندی شود که در هر لحظه حداکثر یک فرآیند تحویل را اجرا کند:

example.com      slow:

هنگامی که هیچ سازوکار انتقالی مشخص نشده باشد، Postfix از سازوکار انتقالی استفاده می‌کند که با رده دامنه نشانی تطابق دارد (بخش توضیحات در بالا را ببینید)، یا از سازوکار انتقال مشخص‌شده با sender_dependent_default_transport_maps (تنها برای تحویل‌های راه دور). نمونه زیر تمام ایمیل‌های مربوط به example.com و زیردامنه‌های آن را به میزبان gateway.example.com ارسال می‌کند:

example.com      :[gateway.example.com]
.example.com     :[gateway.example.com]

در مثال بالا، علامت [] مانع از جستجوهای MX می‌شود. این کار از ایجاد حلقه‌های مسیریابی ایمیل در زمانی که دستگاه شما میزبان MX اصلی برای example.com است جلوگیری می‌کند.

در مورد تحویل از طریق SMTP یا LMTP، می‌توان به جای نام میزبان صرف، host:service را مشخص کرد:

example.com      smtp:bar.example:2025

این پیکربندی، ایمیل‌های user@example.com را به میزبان bar.example روی درگاه 2025 هدایت می‌کند. به جای شماره درگاه عددی می‌توان از یک نام نمادین استفاده کرد. اگر جستجوهای MX باید غیرفعال شوند، علامت [] را دور نام میزبان مشخص کنید.

تحویل‌ها از طریق SMTP یا LMTP از چندین مقصد پشتیبانی می‌کنند (Postfix نسخه 3.5 و بالاتر):

example.com      smtp:bar.example, foo.example

این پیکربندی پیش از تلاش برای تحویل به foo.example، برای تحویل به bar.example تلاش می‌کند.

از ارسال‌کننده خطا (error mailer) می‌توان برای برگشت زدن (bounce) ایمیل استفاده کرد:

.example.com     error:mail for *.example.com is not deliverable

این کار باعث می‌شود تمام ایمیل‌های ارسال‌شده به user@anything.example.com برگشت بخورند.

این بخش چگونگی تغییر در جستجوهای جدول را در حالتی که جدول در قالب عبارات منظم ارائه شود شرح می‌دهد. برای مشاهده شرح ساختار نوشتاری جدول جستجوی عبارت منظم، regexp_table(5) یا pcre_table(5) را ببینید.

هر الگو یک عبارت منظم است که روی کل نشانی در حال جستجو اعمال می‌شود. بنابراین، some.domain.hierarchy از طریق دامنه‌های والد خود جستجو نمی‌شود، و همچنین user+foo@domain به صورت user@domain جستجو نخواهد شد.

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

سرور trivial-rewrite(8) جایگزینی عبارات منظم مانند $1 و غیره را در جدول‌های جستجوی عبارت منظم مجاز نمی‌داند، زیرا این کار ممکن است یک رخنه امنیتی ایجاد کند (Postfix نسخه 2.3 و بالاتر).

این بخش چگونگی تغییر در جستجوهای جدول را در حالتی که جستجوها به یک سرور مبتنی بر TCP هدایت شوند شرح می‌دهد. برای مشاهده شرح پروتکل جستجوی کلاینت/سرور TCP، به tcp_table(5) مراجعه کنید. این قابلیت تا نسخه 2.4 در Postfix (شامل خود آن) در دسترس نیست.

هر عملیات جستجو از کل نشانی گیرنده به طور یکباره استفاده می‌کند. بنابراین، some.domain.hierarchy از طریق دامنه‌های والد خود جستجو نمی‌شود، و همچنین user+foo@domain به صورت user@domain جستجو نخواهد شد.

نتایج مشابه جستجو در فایل‌های نمایه‌سازی‌شده هستند.

پارامترهای زیر در main.cf ارتباط ویژه‌ای با این موضوع دارند. متن زیر تنها خلاصه‌ای از پارامترها را ارائه می‌دهد. برای جزئیات بیشتر به همراه مثال‌ها، postconf(5) را ببینید.

گیرنده ایمیل‌هایی که به نشانی تهی (null) ارسال شده‌اند.
فهرستی از ویژگی‌های Postfix که در آن‌ها الگوی «example.com» بدون نیاز به الگوی صریح «.example.com»، با زیردامنه‌های example.com نیز تطابق دارد.
جدول‌های جستجوی اختیاری با نگاشت‌هایی از نشانی گیرنده به (سازوکار انتقال تحویل پیام، مقصد گام بعدی).

trivial-rewrite(8), بازنویسی و حل و فصل نشانی‌ها
master(5), قالب فایل master.cf
postconf(5), پارامترهای پیکربندی
postmap(1), مدیریت جدول‌های جستجوی Postfix

از دستور «postconf readme_directory» یا «postconf html_directory» برای پیدا کردن این اطلاعات استفاده کنید.

ADDRESS_REWRITING_README, راهنمای بازنویسی نشانی
DATABASE_README, بررسی کلی جدول‌های جستجوی Postfix
FILTER_README, فیلتر محتوای خارجی

مجوز نرم‌افزار Secure Mailer باید همراه با این نرم‌افزار توزیع شود.

Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA