دسته بندی:

محدود کردن ارسال ایمیل در سی پنل و دایرکت ادمین + تنظیم SPF و DKIM

محدود کردن ارسال ایمیل در سی پنل و دایرکت ادمین + تنظیم SPF و DKIM

حدود ۱۱ دقیقه مطالعه

یک اکانت هک‌شده یا یک فرم تماس آسیب‌پذیر کافی است تا در چند ساعت هزاران ایمیل از سرور شما بیرون برود و IP سرور در فهرست‌های سیاه (Blacklist) ثبت شود. از آن لحظه به بعد ایمیل‌های همه‌ی سایت‌های روی آن سرور — حتی سالم‌ترین‌شان — یا در پوشه‌ی Spam می‌افتد یا اصلاً تحویل داده نمی‌شود. جلوگیری از این اتفاق دو بخش دارد: محدود کردن ارسال ایمیل تا هیچ اکانتی نتواند سرور را غرق کند، و امضای درست پیام‌های خروجی با SPF و DKIM تا سرورهای گیرنده به آن‌ها اعتماد کنند. در ادامه هر دو کار را روی سی پنل و دایرکت ادمین انجام می‌دهیم.

سقف ارسال ایمیل دقیقاً چه چیزی را می‌شمارد؟

پیش از دست زدن به هر فایلی، بدانید عددی که وارد می‌کنید روی چه چیزی اعمال می‌شود، چون منطق دو کنترل پنل یکسان نیست:

  • در سی پنل شمارش به‌ازای هر دامنه و در بازه‌ی یک ساعت انجام می‌شود، نه به‌ازای هر صندوق ایمیل.
  • در دایرکت ادمین شمارش به‌ازای هر یوزر و در بازه‌ی ۲۴ ساعت است.

در هر دو حالت آنچه شمرده می‌شود ارسال به مقصدهای بیرون از سرور است؛ نامه‌ای که از یک صندوق روی همان سرور به صندوق دیگری روی همان سرور می‌رود معمولاً در این شمارش نمی‌آید. در مقابل، ایمیل‌هایی که اسکریپت‌های سایت (مثلاً تابع mail() در PHP یا فرم تماس وردپرس) به بیرون می‌فرستند کاملاً حساب می‌شوند. دقیقاً به همین دلیل است که سقف گذاشتن مؤثر است: وقتی یک قالب یا افزونه‌ی آلوده شروع به ارسال انبوه می‌کند، سقف جلوی آن را می‌گیرد و شما فرصت پیدا کردن منبع را دارید.

محدود کردن ارسال ایمیل در سی پنل

۱) سقف پیش‌فرض برای کل سرور

سقفی که به‌صورت پیش‌فرض روی همه‌ی دامنه‌های سرور اعمال می‌شود، پارامتری به نام maxemailsperhour است. در نسخه‌های امروزی سی پنل مقدار معتبر این پارامتر داخل فایل تنظیمات اصلی نگهداری می‌شود:

grep maxemailsperhour /var/cpanel/cpanel.config

در آموزش‌های قدیمی‌تر به فایل جداگانه‌ی /var/cpanel/maxemailsperhour اشاره می‌شود. اگر روی سرور شما وجود داشته باشد همان عدد را نگه می‌دارد، اما روی نصب‌های تازه ممکن است اصلاً ساخته نشده باشد؛ پس پیش از ویرایش، با ls -l /var/cpanel/maxemailsperhour بودنش را چک کنید و اگر نبود دنبال ساختنش نروید.

روش امروزی و مطمئن‌تر این است که به‌جای ویرایش دستی هر دوی این‌ها، مقدار را از WHM تغییر دهید: در کادر جست‌وجوی WHM عبارت Tweak Settings را بزنید و در بخش Mail دنبال گزینه‌ی «Max hourly emails per domain» بگردید. مزیتش این است که WHM خودش فایل‌های پیکربندی مربوط را بازنویسی می‌کند و جای اشتباه تایپی باقی نمی‌ماند.

در همان صفحه یک گزینه‌ی مکمل هم وجود دارد که حداکثر درصد پیام‌های ناموفق یا معوق (deferred) مجاز برای هر دامنه در هر ساعت را تعیین می‌کند. اسکریپت‌های اسپم معمولاً به آدرس‌های بی‌اعتبار می‌فرستند و نرخ خطای بالایی تولید می‌کنند، بنابراین این تنظیم اغلب زودتر از سقف ساعتی جلوی‌شان را می‌گیرد.

۲) سقف اختصاصی برای یک دامنه

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

nano /var/cpanel/maxemails

و برای هر دامنه یک خط به این شکل اضافه کنید (به‌جای domain.com نام دامنه‌ی خودتان را بگذارید). عدد سمت راست، سقف ارسال آن دامنه در هر ساعت است:

domain.com=100

پس از ذخیره‌ی تغییرات (در nano با Ctrl + X سپس y و Enter)، پیکربندی را بازسازی کنید؛ این اسکریپت فایل‌های آستانه‌ای را می‌سازد که exim برای تشخیص پر شدن سقف به آن‌ها نگاه می‌کند:

/scripts/build_maxemails_config

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

۳) سقف در سطح اکانت و پکیج

همین عدد در WHM به‌صورت گرافیکی هم در دسترس است: در Modify an Account فیلدی با عنوان «Maximum Hourly Email by Domain Relayed» وجود دارد که سقف همان اکانت را تعیین می‌کند. سقف ساعتی ایمیل یکی از فیلدهای پکیج‌های هاستینگ در WHM هم هست. اگر چند سرویس با شرایط یکسان می‌فروشید، منطقی‌تر است عدد را در همان پکیج تعریف کنید تا هر اکانت جدید خودبه‌خود با سقف درست ساخته شود؛ ویرایش دستی فایل‌ها را برای موارد استثنا نگه دارید.

۴) وقتی سقف پر می‌شود چه اتفاقی می‌افتد؟

سرور پیام‌های بعدی آن دامنه را با خطای موقت پس می‌زند و فرستنده پیغام «Domain … has exceeded the max emails per hour» می‌گیرد. یعنی نامه فوراً از بین نمی‌رود و در صف می‌ماند تا دوباره تلاش شود، ولی اگر سقف باز نشود و مهلت تلاش مجدد تمام شود در نهایت برگشت می‌خورد. نتیجه‌ی عملی این است که کاربر واقعی هم تا باز شدن پنجره‌ی آن ساعت عملاً نمی‌تواند ایمیل بفرستد. پس عدد را دست‌بالا و بر اساس مصرف واقعی دامنه انتخاب کنید، نه سخت‌گیرانه.

برای دیدن تعداد پیام‌های داخل صف ارسال:

exim -bpc

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

exim -bp | exiqsumm

و برای پیدا کردن اسکریپتی که ایمیل‌ها را می‌فرستد، در لاگ exim دنبال مسیر اجرای اسکریپت بگردید (هر دو دستور فقط خواندنی‌اند و چیزی را تغییر نمی‌دهند):

grep -o 'cwd=[^ ]*' /var/log/exim_mainlog | sort | uniq -c | sort -n | tail

پرتکرارترین مسیرها در خروجی، معمولاً همان پوشه‌ی سایت آلوده است.

در نهایت، اگر لازم شد سرویس ایمیل را ری‌استارت کنید، روی سی پنل بهتر است از اسکریپت خود پنل استفاده کنید تا مانیتورینگ سرویس هم درست به‌روز شود:

/scripts/restartsrv_exim

معادل عمومی آن روی سرورهای امروزی این است (توجه کنید که ری‌استارت، ارسال و دریافت را برای چند ثانیه قطع می‌کند؛ روی سرور شلوغ آن را در ساعت کم‌ترافیک انجام دهید):

systemctl restart exim

فرم‌های قدیمی service exim restart و /etc/init.d/exim restart را هنوز در آموزش‌های قدیمی می‌بینید؛ این‌ها مربوط به CentOS 6 و نسخه‌های پیش از systemd هستند و امروز یا کار نمی‌کنند یا فقط به systemctl منتقل می‌شوند. سی پنل نسخه‌های فعلی روی AlmaLinux، Rocky Linux و Ubuntu نصب می‌شود و مدیریت سرویس‌ها در همه‌ی این‌ها با systemctl است.

محدود کردن ارسال ایمیل در دایرکت ادمین

در دایرکت ادمین این محدودیت با یک فایل ساده به‌ازای هر یوزر تعریف می‌شود. ابتدا با SSH به سرور وصل شوید و به مسیر زیر بروید (دقت کنید مسیر virtual است، نه virual؛ این غلط املایی در بسیاری از آموزش‌های فارسی تکرار شده است):

cd /etc/virtual

سپس فایل مربوط به یوزر مورد نظر را باز کنید. به‌جای username نام کاربری همان یوزر را بگذارید:

nano limit_username

مثلاً اگر نام کاربری example باشد، دستور به این شکل درمی‌آید:

nano limit_example

فایل خالی باز می‌شود. فقط یک عدد در آن بنویسید — مثلاً 100 — و با Ctrl + X، سپس y و Enter ذخیره کنید. توجه داشته باشید که این عدد سقف ارسال در هر ۲۴ ساعت است، نه در هر ساعت؛ بنابراین آن را با عددی که در سی پنل می‌گذارید یکی نگیرید. عدد 0 در این فایل یعنی نامحدود.

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

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

معمولاً نیازی به ری‌استارت سرویس نیست و مقدار جدید از همان ارسال بعدی اعمال می‌شود؛ اگر تغییر را ندیدید، با systemctl restart exim سرویس را ری‌استارت کنید.

SPF و DKIM؛ نیمه‌ی دوم کار

سقف ارسال جلوی حجم سوءاستفاده را می‌گیرد، اما به سرور گیرنده نمی‌گوید که ایمیل شما جعلی نیست. این کار برعهده‌ی دو رکورد DNS است: SPF (مخفف Sender Policy Framework) مشخص می‌کند چه سرورهایی حق دارند از طرف دامنه‌ی شما ایمیل بفرستند، و DKIM با یک امضای رمزنگاری‌شده ثابت می‌کند پیام در مسیر دستکاری نشده است. برای آشنایی بیشتر با مفهوم این دو رکورد، مقاله‌ی Email Authentication چیست؟ را بخوانید.

روش گرافیکی، که امروز روش پیشنهادی است

در نسخه‌های فعلی سی پنل لازم نیست سراغ خط فرمان بروید. ابزار Email Deliverability (هم در WHM و هم در پنل کاربر) وضعیت SPF، DKIM، DMARC و رکورد معکوس (PTR) هر دامنه را نشان می‌دهد و با دکمه‌ی Repair رکوردهای ناقص را اصلاح می‌کند. این دکمه فقط وقتی کار می‌کند که DNS دامنه روی همان سرور باشد؛ در غیر این صورت رکورد پیشنهادی را به شما نشان می‌دهد تا دستی در پنل DNS واقعی ثبتش کنید. برای کار روی یک دامنه، این ابزار سریع‌تر و بسیار کم‌خطرتر از دستورهای خط فرمان است.

اضافه کردن SPF در سی پنل از خط فرمان

برای یک یوزر مشخص (به‌جای username نام کاربری را بگذارید):

/usr/local/cpanel/bin/spf_installer username

و برای همه‌ی یوزرهای سرور به‌یکباره:

for USER in /var/cpanel/users/*; do /usr/local/cpanel/bin/spf_installer "${USER##*/}"; done

اضافه کردن DKIM در سی پنل از خط فرمان

برای یک یوزر:

/usr/local/cpanel/bin/dkim_keys_install username

و برای همه‌ی یوزرها:

for USER in /var/cpanel/users/*; do /usr/local/cpanel/bin/dkim_keys_install "${USER##*/}"; done

پیش از اجرای این دو حلقه روی سرور واقعی، این هشدار را جدی بگیرید: هر دو دستور روی تمام اکانت‌های سرور فایل زون را دست می‌زنند. اگر دامنه‌ای روی سرور شما ایمیلش را از جای دیگری می‌فرستد — Google Workspace، Microsoft 365، یک SMTP بیرونی یا یک سرویس خبرنامه — رکورد SPF اختصاصی‌اش ممکن است با رکورد پیش‌فرض سی پنل جایگزین شود و ایمیل همان مشتری از کار بیفتد. مسیر امن این است:

  • اول یک نسخه‌ی پشتیبان از فایل‌های زون بگیرید: cp -a /var/named /root/named-backup-$(date +%F)
  • یک بار ls /var/cpanel/users/ بگیرید تا بدانید حلقه دقیقاً روی چه فهرستی اجرا می‌شود.
  • دستور را اول روی یک یوزر آزمایشی اجرا کنید و نتیجه‌ی رکورد را چک کنید، بعد سراغ حلقه بروید.
  • حلقه را در ساعت کم‌ترافیک اجرا کنید، مخصوصاً اگر تعداد اکانت‌ها زیاد است.

اگر روی سرور فقط چند دامنه دارید، اصلاً سراغ حلقه نروید و همان ابزار Email Deliverability را دامنه‌به‌دامنه استفاده کنید.

چند نکته‌ی مهم درباره‌ی رکوردها

  • هر دامنه فقط یک رکورد SPF می‌تواند داشته باشد. اگر همزمان از سرویس دیگری هم ایمیل می‌فرستید، باید همه را در یک رکورد ادغام کنید؛ دو رکورد SPF جداگانه یعنی هر دو نامعتبر.
  • ساختار کلی رکورد چیزی شبیه v=spf1 +a +mx ~all است. پایانه‌ی ~all یعنی «مشکوک ولی رد نکن» و -all یعنی «هر فرستنده‌ی دیگری را رد کن». تا وقتی مطمئن نشده‌اید همه‌ی مسیرهای ارسال دامنه در رکورد آمده‌اند، ~all گزینه‌ی امن‌تری است؛ -all زودرس یعنی ایمیل‌های سالمی که از مسیر فراموش‌شده می‌آیند رد می‌شوند.
  • SPF حداکثر ۱۰ بار مجاز به DNS Lookup است؛ اگر چند include پشت سر هم بگذارید از این سقف رد می‌شوید و رکورد با خطا بی‌اثر می‌شود.
  • اگر DNS دامنه روی سرور خودتان نیست (مثلاً به Cloudflare یا نیم‌سرورهای ثبت‌کننده منتقل شده)، این دستورها رکورد را فقط در فایل زون محلی می‌سازند و هیچ اثری در دنیای بیرون ندارد. در این حالت باید رکورد TXT ساخته‌شده را برداشته و دستی در پنل DNS واقعی دامنه ثبت کنید.
  • پس از SPF و DKIM، یک رکورد DMARC ساده مثل v=DMARC1; p=none; rua=mailto:postmaster@domain.com اضافه کنید. با p=none هیچ ایمیلی رد نمی‌شود و فقط گزارش می‌گیرید؛ سخت‌گیرتر کردن سیاست را بگذارید برای بعد از اینکه گزارش‌ها را دیدید.
  • سرویس‌های بزرگ ایمیل مثل Gmail و Yahoo از سال ۲۰۲۴ برای فرستنده‌های انبوه هر سه رکورد را عملاً الزامی کرده‌اند و نبودشان به‌تنهایی می‌تواند ایمیل شما را به Spam بفرستد.

ربط این تنظیمات به بلک‌لیست شدن IP سرور

این دو کار مکمل یکدیگرند. سقف ارسال، «حجم» خروجی را کنترل می‌کند: بدون آن، یک اکانت آلوده در چند ساعت آن‌قدر ایمیل می‌فرستد که IP سرور در فهرست‌هایی مثل Spamhaus ثبت شود. SPF و DKIM «هویت» ایمیل را تضمین می‌کنند: بدون آن‌ها حتی ایمیل‌های کاملاً سالم شما امتیاز اسپم می‌گیرند و کسی نمی‌تواند ایمیل جعلی به نام دامنه‌ی شما را از ایمیل واقعی تشخیص دهد.

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

چک‌لیست نهایی

  • یک سقف ساعتی پیش‌فرض برای کل سرور تعریف کنید (سی پنل: گزینه‌ی «Max hourly emails per domain» در Tweak Settings، که همان پارامتر maxemailsperhour است).
  • برای دامنه‌های استثنا، خط اختصاصی در /var/cpanel/maxemails بگذارید و /scripts/build_maxemails_config را اجرا کنید.
  • در دایرکت ادمین، فایل /etc/virtual/limit را برای پیش‌فرض و /etc/virtual/limit_username را برای یوزرهای خاص بسازید (عدد روزانه است).
  • SPF و DKIM را برای همه‌ی دامنه‌ها فعال کنید — ترجیحاً با Email Deliverability؛ و اگر حلقه‌ی خط فرمان را اجرا می‌کنید، اول از زون‌ها پشتیبان بگیرید.
  • اگر DNS بیرون از سرور است، رکوردها را دستی در پنل DNS واقعی ثبت کنید.
  • یک رکورد DMARC با p=none اضافه کنید.
  • هر چند وقت یک بار exim -bpc را چک کنید و وضعیت IP سرور را در سرویس‌های بررسی بلک‌لیست مثل MXToolbox ببینید.