نصب spamassassin در دایرکت ادمین

SpamAssassin یک فیلتر امتیازمحور است: هر ایمیل ورودی را در برابر ده‌ها قانون می‌سنجد، به آن یک امتیاز می‌دهد و اگر امتیاز از آستانه‌ی تعیین‌شده بالاتر رفت، پیام را اسپم علامت می‌زند. در دایرکت‌ادمین نصب و فعال‌سازی آن با CustomBuild و چند دستور انجام می‌شود، اما اگر SPF و DKIM و DMARC دامنه‌تان درست نباشد، ایمیل خودتان همچنان در اسپم دیگران می‌افتد.

SpamAssassin دقیقاً چه کار می‌کند

برخلاف تصور رایج، SpamAssassin چیزی را «مسدود» نمی‌کند؛ کار آن امتیازدهی است. هر پیام از چند مسیر بررسی می‌شود: قوانین متنی روی موضوع و بدنه، فیلتر آماری Bayes که از الگوی ایمیل‌های قبلی یاد می‌گیرد، لیست‌های سیاه DNS ‏(DNSBL یا RBL) و نتیجه‌ی احراز هویت فرستنده. حاصل در هدرهایی مثل X-Spam-Status، X-Spam-Score و X-Spam-Bar نوشته می‌شود.

آستانه‌ی پیش‌فرض required_score 5.0 است و هر پیام با امتیاز بالاتر اسپم شمرده می‌شود. این ماجرا فقط درباره‌ی ایمیل ورودی شماست؛ سرنوشت ایمیل خروجی را سرور مقصد تعیین می‌کند، نه SpamAssassin شما.

پیش‌نیازها

• دسترسی root به سرور (روی هاست اشتراکی این کار در سطح سرور انجام شده و از دست شما خارج است).
• یک توزیع پشتیبانی‌شده‌ی دایرکت‌ادمین: خانواده‌ی RHEL نسل ۸، ۹ یا ۱۰ (مثل AlmaLinux و Rocky Linux)، یا نسخه‌های LTS پشتیبانی‌شده‌ی Debian و Ubuntu. در مقابل، CentOS Linux نسخه‌های ۶، ۷ و ۸ به پایان عمر رسیده‌اند و هیچ به‌روزرسانی امنیتی نمی‌گیرند؛ Debian ۱۰ و پایین‌تر و Ubuntu 20.04 و پایین‌تر هم در فهرست منسوخ دایرکت‌ادمین‌اند. روی این‌ها اول باید مهاجرت کنید.
• یک لایسنس فعال دایرکت‌ادمین روی همان IP سرور.
• حافظه‌ی آزاد کافی؛ سرویس spamd مصرف رم محسوسی دارد.

نصب و فعال‌سازی با CustomBuild

دو عادت قدیمی را کنار بگذارید: نصب دستی ده‌ها بسته‌ی perl-* با yum لازم نیست چون CustomBuild وابستگی‌هایش را خودش نصب می‌کند (و yum روی توزیع‌های جدید جای خود را به dnf داده)، و CustomBuild نسخه‌ی 1.2 سال‌هاست منسوخ شده. دایرکت‌ادمین امروز ابزار خط فرمان da را دارد که جای رفتن به پوشه‌ی CustomBuild را می‌گیرد:

• da build update
• da build set eximconf yes
• da build set blockcracking yes
• da build set easy_spam_fighter yes
• da build set spamd spamassassin
• da build spamassassin
• da build set exim yes
• da build exim
• da build exim_conf

به کلید spamd دقت کنید؛ این همان جایی است که راهنماهای قدیمی اشتباه می‌کنند. گزینه‌ی سابق spamassassin=yes در options.conf جای خود را به spamd داده که مقدارش یا spamassassin است یا rspamd، پس دستور da build set spamassassin yes دیگر کار درست را انجام نمی‌دهد. ترتیب هم مهم است: EasySpamFighter به SpamAssassinِ در حال اجرا نیاز دارد، بنابراین اول SpamAssassin را بسازید و da build exim_conf را آخر از همه اجرا کنید. بازسازی Exim پیش از نوشتن کانفیگ هم توصیه‌ی خود دایرکت‌ادمین است تا SRS داخل باینری کامپایل شده باشد.

اگر نسخه‌ی دایرکت‌ادمین شما هنوز da ندارد، همین‌ها را با cd /usr/local/directadmin/custombuild و سپس ./build ... اجرا کنید. مقدار eximconf_release را هم دستی روی نسخه‌های قدیمی قفل نکنید؛ همان پیش‌فرض CustomBuild در /usr/local/directadmin/custombuild/options.conf را نگه دارید.

دیگر لازم نیست فایل exim.spamassassin.conf را با wget دانلود کنید یا خط .include_if_exists را دستی از کامنت خارج کنید؛ کانفیگ Exim امروزی دایرکت‌ادمین یکپارچگی با SpamAssassin را درون خودش دارد و da build exim_conf همه را می‌نویسد. آن دستور قدیمی فایل را روی http بدون رمزنگاری می‌گرفت که امروز پذیرفتنی نیست.

تغییرهای اختصاصی خود را مستقیم در exim.conf ننویسید؛ دایرکت‌ادمین برای این کار فایل‌های /etc/exim.strings.conf.custom و /etc/exim.variables.conf.custom را در نظر گرفته که به‌روزرسانی بعدی پاکشان نمی‌کند. در پایان با systemctl restart exim سرویس را راه‌اندازی مجدد کنید؛ /etc/init.d/exim restart مربوط به دوران init قدیمی است و جای خود را به systemd داده.

همه‌ی این مسیر دسترسی root می‌خواهد و مخصوص سروری است که خودتان مدیرش هستید. اگر سایت شما روی هاست لینوکس ایران است، کنترل‌پنل آن cPanel است و اصلاً به خط فرمان سرور دسترسی ندارید؛ آنجا کار سطح سرور بر عهده‌ی ارائه‌دهنده می‌ماند و سهم شما فقط گزینه‌های کاربری همان پنل و رکوردهای DNS دامنه‌تان است.

آستانه‌ی امتیاز و تنظیمات هر کاربر

بعد از نصب، هر کاربر در پنل خودش بخش E-Mail Manager و سپس SpamAssassin Setup را دارد؛ آنجا فیلتر را روشن می‌کند، آستانه‌ی امتیاز را عوض می‌کند و تعیین می‌کند با پیام اسپم چه شود: تحویل به پوشه‌ی spam، برچسب‌خوردن موضوع، یا حذف.

درباره‌ی این عدد محافظه‌کار باشید و از همان ۵ شروع کنید. پایین آوردن به ۳ اسپم بیشتری می‌گیرد اما مثبت کاذب را بالا می‌برد و ایمیل واقعی مشتری را قربانی می‌کند؛ ۷ یا ۸ سخت‌گیری را کم می‌کند. عدد را یک‌باره جابه‌جا نکنید؛ کم‌کم تغییرش دهید و بین هر تغییر، نتیجه را روی ایمیل‌های واقعی همان صندوق ببینید.

برچسب‌زدن یا رد کردن؟

این دو رفتار کاملاً متفاوت‌اند و انتخاب بینشان تصمیم مدیریتی است، نه فنی:

• برچسب‌زدن (tag): پیام تحویل می‌شود ولی هدر و موضوع نشانه‌گذاری می‌شوند و معمولاً به پوشه‌ی اسپم می‌رود. چیزی گم نمی‌شود، اما صندوق‌ها شلوغ و فضا مصرف می‌شود.
• رد کردن (reject): پیام همان لحظه در جلسه‌ی SMTP با خطای 5xx برگردانده می‌شود؛ منابع کمتری مصرف می‌شود و فرستنده‌ی واقعی خبردار می‌شود، اما یک مثبت کاذب یعنی ایمیل مهم هرگز به شما نمی‌رسد.

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

وایت‌لیست و بلک‌لیست

تنظیمات هر کاربر در /home/USER/.spamassassin/user_prefs ذخیره می‌شود. دستورهای کلاسیک whitelist_from و blacklist_from هستند؛ در SpamAssassin نسخه‌ی ۴ نام‌های تازه‌ی welcomelist_from و blocklist_from ترجیح داده می‌شوند و نام‌های قدیمی هنوز کار می‌کنند.

یک هشدار جدی: whitelist_from فقط به هدر From نگاه می‌کند و جعل آن ساده است. برای سفید کردن مطمئن یک فرستنده از whitelist_auth استفاده کنید که تنها وقتی اثر می‌گذارد که فرستنده با SPF یا DKIM احراز هویت شده باشد.

بررسی اینکه واقعاً کار می‌کند

• وضعیت سرویس: systemctl status spamassassin (بسته به توزیع ممکن است نام یونیت spamd باشد).
• صحت قوانین: spamassassin --lint باید بدون خروجی خطا تمام شود.
• یک ایمیل آزمایشی از بیرون بفرستید و در منبع پیام دنبال هدر X-Spam-Status بگردید؛ نبودنش یعنی مسیر Exim به SpamAssassin نمی‌رسد. برای تست قطعی رشته‌ی استاندارد GTUBE از سایت رسمی SpamAssassin را بفرستید که باید حتماً اسپم شود.
• لاگ زنده: tail -f /var/log/exim/mainlog
• اگر اصلاً لاگی نوشته نمی‌شود، احتمالاً خود سرویس Exim بالا نیامده؛ در آن حالت اول رفع مشکل start نشدن سرویس exim در دایرکت ادمین را دنبال کنید.
• قوانین را به‌روز نگه دارید؛ sa-update باید زمان‌بندی‌شده اجرا شود وگرنه فیلتر شما با قوانین چند سال پیش کار می‌کند.

بخش مهم‌تر: SPF، DKIM و DMARC

SpamAssassin از ایمیل ورودی شما محافظت می‌کند. آنچه تعیین می‌کند ایمیل خروجی شما به Inbox برسد یا نه، سه رکورد DNS است:

• SPF: یک رکورد TXT روی ریشه‌ی دامنه که می‌گوید چه سرورهایی حق ارسال از طرف شما را دارند (روش ساخت آن روی سی‌پنل در فعال‌سازی SPF و DKIM آمده است)، مثل v=spf1 a mx ip4:1.2.3.4 ~all.
• DKIM: امضای رمزنگاری‌شده روی هر پیام. در دایرکت‌ادمین با /usr/local/directadmin/directadmin set dkim 1 فعال می‌شود و بعد از راه‌اندازی مجدد سرویس و اجرای da build exim_conf، کلید عمومی معمولاً به شکل رکورد x._domainkey.example.com در زون دامنه ساخته می‌شود.
• DMARC: یک رکورد TXT روی _dmarc.example.com. با v=DMARC1; p=none; rua=mailto:dmarc@example.com شروع کنید، گزارش‌ها را چند هفته بخوانید و بعد سیاست را به quarantine و در نهایت reject ببرید. از روز اول روی reject رفتن یعنی قطع ایمیل‌های سالمی که هنوز از قلم افتاده‌اند.

رکورد معکوس (PTR) را هم باید ارائه‌دهنده‌ی سرور برای IP شما تنظیم کند. نگه‌داشتن زون روی یک سرویس اختصاصی DNS که افزودن و ویرایش رکوردهای TXT را از ناحیه‌ی کاربری در اختیارتان می‌گذارد، ساختن و عیب‌یابی این سه رکورد را بسیار ساده‌تر می‌کند.

خطاهای رایج

• ساخت با خطا متوقف می‌شود: اول da build update را اجرا کنید و فضای دیسک و حافظه را ببینید؛ این دو از رایج‌ترین دلایل شکست ساخت‌اند.
• همه‌چیز اسپم تشخیص داده می‌شود: آستانه خیلی پایین است یا پایگاه Bayes با آموزش اشتباه خراب شده. ساعت سرور را هم با timedatectl چک کنید؛ اختلاف زمانی به پیام‌های سالم امتیاز می‌دهد.
• تنظیمات بعد از به‌روزرسانی پاک می‌شود: تغییرها را در فایل اصلی نوشته‌اید؛ به فایل‌های .custom منتقلشان کنید.

ایمیل خروجی هنوز به اسپم می‌رود: این مشکل SpamAssassin نیست و نصب دوباره‌اش چیزی را عوض نمی‌کند. اگر ریشه‌ی ماجرا ارسال انبوه از یک اسکریپت آلوده باشد، محدود کردن تعداد ایمیل‌های ارسالی در دایرکت ادمین جلوی سوختن اعتبار آی‌پی سرور را می‌گیرد. در غیر این صورت سراغ SPF، DKIM، DMARC، رکورد PTR و اعتبار IP سرور بروید؛ تقریباً همیشه یکی از همین‌ها ناقص است.