RELOCATED(5) File Formats Manual RELOCATED(5)

relocated - قالب جدول جابه‌جاشدگان پست‌فیکس (Postfix)

postmap /etc/postfix/relocated


جدول اختیاری relocated(5) اطلاعاتی را فراهم می‌کند که در پیام‌های برگشتی (bounce) با مضمون «کاربر به new_location منتقل شده است» به‌کار می‌روند.

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

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

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

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

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

جستجوهای جدول به بزرگ و کوچکی حروف حساس نیستند (case insensitive).

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

  • به‌طور پیش‌فرض، Postfix پیشوند تغییرناپذیر «5.1.6 User has moved to » را به نتیجه جستجوی جدول اضافه می‌کند و قالب یک ورودی جدول به‌صورت زیر است: 
    pattern      new_location

    که در آن new_location اطلاعات تماس مانند نشانی ایمیل، یا احتمالاً نشانی پستی یا شماره تلفن را مشخص می‌کند.

  • در نسخه Postfix 3.11 و بالاتر می‌توان به‌صورت اختیاری این پیشوند تغییرناپذیر را غیرفعال کرد. مقدار «relocated_prefix_enable = no» را در main.cf تنظیم کنید و ورودی‌های relocated_maps را به همراه کد وضعیت بهبودیافته سازگار با RFC 3463 و متن دلخواه خود مشخص نمایید؛ برای نمونه: 
    pattern      5.1.6 Mailbox has moved to user@example
pattern      5.2.0 Mailbox is unavailable
pattern      5.2.1 Mailbox is disabled
  • خطوط خالی و خطوطی که تنها شامل فاصله‌های سفید هستند نادیده گرفته می‌شوند، همانند خطوطی که نخستین نویسه غیرفاصله‌ای آن‌ها «#» است.
  • یک خط منطقی با یک متن غیرفاصله‌ای آغاز می‌شود. خطی که با فاصله سفید شروع شود ادامه یک خط منطقی محسوب می‌گردد.

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

با user@domain مطابقت دارد. این فرم نسبت به تمام فرم‌های دیگر اولویت دارد.
هنگامی که site برابر $myorigin باشد، هنگامی که site در $mydestination فهرست شده باشد، یا هنگامی که site در $inet_interfaces یا $proxy_interfaces فهرست شده باشد، با user@site مطابقت دارد.
@domain
با سایر نشانی‌ها در domain مطابقت دارد. این فرم کمترین اولویت را دارد.

هنگامی که بخش محلی (localpart) یک نشانی ایمیل شامل نویسه جداکننده اختیاری گیرنده باشد (برای نمونه، user+foo@domain)، ترتیب جستجو به‌صورت زیر خواهد بود: user+foo@domain، user@domain، user+foo، user و @domain.

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

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

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

نتایج همانند نتایج جستجو در فایل‌های نمایه‌سازی‌شده هستند، با این ویژگی افزوده که زیررشته‌های داخل پرانتز در الگو می‌توانند به‌صورت $1، $2 و غیره جای‌گذاری شوند.

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

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

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


قالب جدول قراردادهای نقل‌قول (quoting conventions) را درک نمی‌کند.

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

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

موجود در Postfix نسخه 3.11 و بالاتر:

افزودن پیشوند «5.1.6 User has moved to » به ابتدای تمامی نتایج جستجوی relocated_maps.

سایر پارامترهای مهم:

نشانی‌های رابط شبکه محلی که این سامانه ایمیل روی آن‌ها پیام دریافت می‌کند.
فهرست دامنه‌هایی که از طریق ترابری تحویل ایمیل local_transport$ تحویل داده می‌شوند.
نام دامنه‌ای که ایمیل‌های ارسال‌شده محلی به‌نظر می‌رسد از آن می‌آیند، و ایمیل‌های ارسال‌شده محلی به آن تحویل داده می‌شوند.
نشانی‌های رابط شبکه دوردست که این سامانه ایمیل از طریق یک پراکسی یا واحد ترجمه نشانی شبکه (NAT) روی آن‌ها پیام دریافت می‌کند.

trivial-rewrite(8), ارجاع‌دهنده نشانی
postmap(1), مدیر جدول جستجوی Postfix
postconf(5), پارامترهای پیکربندی

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

DATABASE_README, نمای کلی جدول جستجوی Postfix
ADDRESS_REWRITING_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