آدرس catch-all چیست؟

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

دقیقاً چه اتفاقی می‌افتد؟

فرض کنید روی دامنه‌ی example.com فقط یک صندوق واقعی به نام info@example.com ساخته‌اید. اگر کسی نامه‌ای به sales@example.com بفرستد، سرور شما در همان مرحله‌ی گفت‌وگوی SMTP پاسخ خطا می‌دهد (چیزی شبیه 550 No Such User Here) و سرور فرستنده یک گزارش عدم تحویل برای نویسنده تولید می‌کند. نویسنده بلافاصله می‌فهمد آدرس را اشتباه نوشته است.

با فعال کردن catch-all و نشانه‌گرفتن آن روی info@example.com، همان نامه دیگر رد نمی‌شود و مستقیم در صندوق info می‌نشیند. پشت صحنه یک قاعده‌ی عام برای دامنه ثبت می‌شود؛ روی هاست اشتراکی که با کنترل‌پنل سی‌پنل یا Plesk عرضه می‌شود این کار با چند کلیک انجام می‌گیرد. در سی‌پنل نام این بخش Default Address است و در دایرکت‌ادمین Catch-All E-Mail.

سه رفتار ممکن برای آدرس‌های تعریف‌نشده

برخلاف تصور رایج، catch-all یک کلید روشن و خاموش نیست؛ سه انتخاب پیش روی شماست:

روی سرورهای مبتنی بر Exim، این سه حالت به‌ترتیب با سطرهای *: :fail: No Such User Here، *: info@example.com و *: :blackhole: در فایل نام‌های مستعار دامنه نوشته می‌شوند؛ در سی‌پنل مسیر آن /etc/valiases/example.com و در دایرکت‌ادمین /etc/virtual/example.com/aliases است. اگر سرویس ایمیل را روی سرور مجازی با دسترسی روت کامل خودتان اجرا می‌کنید، همین فایل‌ها را مستقیم هم می‌توانید ویرایش کنید؛ فقط پس از تغییر، مسیریابی آدرس را با exim -bt random1234@example.com بیازمایید تا مطمئن شوید قاعده همان‌طور که انتظار دارید عمل می‌کند.

چرا catch-all آهن‌ربای اسپم است؟

ارسال‌کنندگان انبوه، آدرس‌ها را حدس می‌زنند. برای مهار حجم پیامی که از این راه می‌رسد، نصب و تنظیم SpamAssassin کمترین کاری است که باید انجام دهید. آن‌ها فهرستی از نام‌های پرتکرار مثل admin، sales، billing، webmaster و صدها نام شخصی را به دامنه‌ی شما می‌چسبانند و امتحان می‌کنند. به این کار حمله‌ی برداشت دایرکتوری (Directory Harvest Attack) می‌گویند.

در حالت عادی تک‌تک این تلاش‌ها با خطای «چنین کاربری وجود ندارد» رد می‌شود؛ یعنی ارزان‌ترین لایه‌ی ضداسپم شما کار خودش را کرده است. catch-all دقیقاً همین لایه را برمی‌دارد و به سرور می‌گوید «هر چه رسید، قبول کن». نتیجه این است که صندوق مقصد ظرف چند هفته زیر انبوه نامه‌های بی‌ربط دفن می‌شود و نامه‌ی واقعی مشتری میان آن‌ها گم می‌شود. خطر جدی‌تر این است که میان همین انبوه، پیام‌های فیشینگ هم مستقیم به صندوق اصلی سازمان می‌رسند.

Backscatter؛ خطری که به اعتبار دامنه می‌زند

مشکل جدی‌تر وقتی پیدا می‌شود که سرور نامه را ابتدا می‌پذیرد و بعد تصمیم می‌گیرد قابل تحویل نیست: صندوق مقصد پر شده، فیلتر اسپم آن را رد کرده، یا مسیر بازارسال شکسته است. در این حالت سرور شما موظف است یک نامه‌ی برگشتی به فرستنده بفرستد، اما نشانی فرستنده در نامه‌های اسپم تقریباً همیشه جعلی است. پس نامه‌ی برگشتی شما به صندوق یک قربانی بی‌گناه می‌رود. به این پدیده backscatter می‌گویند و فهرست‌های سیاه ایمیل (RBL) مانند Backscatterer دقیقاً همین رفتار را رصد و آی‌پی‌ها را مسدود می‌کنند.

یک ترکیب خطرناک هم وجود دارد: catch-all به‌علاوه‌ی بازارسال به یک صندوق بیرونی مثل Gmail. در بازارسال ساده، نشانی فرستنده‌ی اصلی حفظ می‌شود و بررسی SPF در مقصد شکست می‌خورد، مگر آنکه از بازنویسی فرستنده (SRS) استفاده کنید. عملاً شما اسپم دیگران را با نام سرور خودتان به Gmail تحویل می‌دهید و اعتبار آی‌پی و دامنه‌تان را خرج می‌کنید. اگر رکوردهای MX دامنه را در یک سرویس مدیریت DNS نگه می‌دارید، پیش از هر تغییری با dig MX example.com +short مطمئن شوید نامه‌ها واقعاً به همان سروری می‌روند که فکر می‌کنید.

دور ریختن بهتر است یا بازارسال؟

هر کدام هزینه‌ی خودش را دارد. بازارسال دیدِ کامل می‌دهد و هیچ نامه‌ای گم نمی‌شود، اما همان سیل اسپم را وارد صندوق می‌کند. دور ریختن صندوق را تمیز نگه می‌دارد، ولی خطرناک‌تر است: فرستنده‌ای که آدرس را یک حرف اشتباه نوشته، نه نامه‌اش تحویل می‌شود و نه هیچ خطایی می‌گیرد. او مطمئن است پیامش رسیده و شما هرگز نمی‌فهمید چه چیزی را از دست داده‌اید.

به همین دلیل، حالت سوم یعنی رد کردن در همان مرحله‌ی SMTP بهترین پیش‌فرض است: نه نامه‌ای بی‌صدا حذف می‌شود، نه نامه‌ی برگشتی جعلی تولید می‌کنید. هشدار: پیش از انتخاب :blackhole: بدانید حذف بازگشت‌ناپذیر است و هیچ ردی در صندوق باقی نمی‌ماند؛ فقط لاگ سرور شاهد ماجراست.

جایگزین درست: نام‌های مستعار صریح

راه‌حل اصولی این است که به‌جای یک قاعده‌ی عام، هر آدرسی را که واقعاً استفاده می‌کنید صریح تعریف کنید. چند نمونه‌ی کاربردی:

• آدرس‌های نقشی مثل info@، sales@، support@ و billing@ را به‌صورت نام مستعار (Forwarder) به صندوق‌های واقعی وصل کنید؛ روش ساخت آن‌ها در آموزش ساخت ایمیل در سی پنل آمده است.
• برای همکاری که سازمان را ترک کرده، به‌جای روشن گذاشتن catch-all، آدرس او را برای یک بازه‌ی مشخص به جانشینش بازارسال کنید و بعد حذفش کنید.
• در بسیاری از سرورهای مبتنی بر Exim و Postfix، آدرس‌دهی با علامت مثبت پشتیبانی می‌شود؛ یعنی info+newsletter@example.com بدون ساختن هیچ صندوق تازه‌ای به info می‌رسد و می‌توانید بفهمید نشانی‌تان از کجا درز کرده است.

اگر واقعاً به catch-all نیاز دارید

گاهی در مهاجرت از یک سامانه‌ی قدیمی، فهرست کامل آدرس‌های فعال را در دست ندارید. در این حالت catch-all ابزار موقتی خوبی است، به شرط رعایت چند نکته: بازه‌ی زمانی مشخصی برایش تعیین کنید، مقصد را یک صندوق جداگانه با سهمیه‌ی محدود بگذارید نه صندوق اصلی سازمان، لاگ‌ها را هفتگی مرور کنید تا آدرس‌های واقعاً پرکاربرد را بیرون بکشید، و به‌محض ساختن نام‌های مستعار صریح آن را خاموش کنید. توجه کنید که از لحظه‌ی خاموش کردن، نامه‌های ارسالی به آدرس‌های تعریف‌نشده برگشت می‌خورند؛ پس اول نام‌های مستعار را بسازید، بعد catch-all را بردارید. اگر پیکربندی سرویس ایمیل یا کنترل‌پنل برایتان دردسرساز شده، خدمات پشتیبانی و مدیریت سرور نصب، پیکربندی و رفع مشکل کنترل‌پنل‌های میزبانی را پوشش می‌دهد.

جمع‌بندی

catch-all یعنی «هر نامه‌ای به هر آدرسی از این دامنه رسید، بپذیر». این کار یک مشکل کوچک (غلط تایپی گیرنده) را حل می‌کند و دو مشکل بزرگ (سیل اسپم و backscatter) می‌سازد. اگر امکانش هست، آدرس‌های تعریف‌نشده را رد کنید، آدرس‌های واقعی را صریح بسازید، و catch-all را فقط به‌عنوان یک ابزار موقتِ زمان‌دار در دوران مهاجرت به کار ببرید.