راهنمای راه‌اندازی Mailcow روی VPS برای ارسال ایمیل

آنچه می‌سازید

یک سرور ایمیل کامل روی سروری که مالک آن هستید: SMTP برای ارسال و دریافت، IMAP برای همگام‌سازی گوشی و لپ‌تاپ، یک کلاینت وب‌میل و یک فیلتر اسپم که تمام پیام‌ها را در هر دو جهت امتیازدهی می‌کند. mailcow-dockerized مجموعه‌ای از Postfix، Dovecot، Rspamd، وب‌میل SOGo، MariaDB، Redis و یک کلاینت ACME را در یک stack از Docker Compose بسته‌بندی می‌کند، بنابراین بخش نرم‌افزاری کار دشواری نیست. شما می‌توانید آن را در نیم ساعت راه‌اندازی کنید.

بخش دشوار، تمام مسائل پیرامون آن است. ایمیل تنها سرویسی است که در آن بقیه اینترنت به‌طور فعال به یک سرور تازه تاسیس بی‌اعتماد هستند و فاصله بین «کار کردن» و «اینکه Gmail بی‌سروصدا تمام پیام‌ها را حذف کند» به چهار رکورد DNS و یک تنظیم اعتبار IP بستگی دارد که ممکن است کنترل کاملی روی آن نداشته باشید. پیش از اجاره هرگونه سرور، پیش‌نیازهای زیر را مطالعه کنید. اگر پس از خواندن آن‌ها تصمیم گرفتید که دردسرهای کسب اعتبار ارزشش را ندارد، این یک تصمیم منطقی است؛ بررسی ما از آنچه در سال 2026 واقعاً ارزش self-hosting دارد، دقیقاً به همین دلایل، ایمیل را در دسته «فقط اگر واقعاً قصدش را دارید» قرار می‌دهد.

پیش‌نیازها خودِ پروژه هستند

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

پورت خروجی 25 باید باز باشد. سرور شما از طریق پورت TCP 25 به Gmail و Microsoft متصل می‌شود. بخش بزرگی از ارائه‌دهندگان VPS و سرویس‌های ابری، پورت خروجی 25 را به‌صورت پیش‌فرض برای مقابله با اسپم مسدود می‌کنند. این مسدودسازی بی‌سروصدا انجام می‌شود؛ هیچ خطایی هنگام بوت رخ نمی‌دهد، همه‌چیز سالم به نظر می‌رسد و ایمیل‌ها برای همیشه در صف باقی می‌مانند. پیش از نصب هر چیزی، این مورد را تست کنید. اگر پورت مسدود است، تنها راه‌حل، ارسال تیکت پشتیبانی به ارائه‌دهنده برای باز کردن آن است؛ برخی این کار را برای حساب‌های قدیمی انجام می‌دهند و برخی هرگز آن را انجام نخواهند داد.

یک IP تمیز با اعتبار مناسب. IPهای بازیافتیِ VPSها اغلب به‌دلیل فعالیت‌های کاربر قبلی در لیست‌های سیاه (blocklist) قرار دارند. پیش از شروع، وضعیت IP خود را در سرویس‌هایی مانند Spamhaus یا mxtoolbox بررسی کنید. قرار داشتن IP در لیست سیاه به معنای ریجکت شدن ایمیل‌هاست که با هیچ کدنویسی‌ای قابل‌حل نیست.

کنترل DNS و یک رکورد PTR صحیح. شما باید رکوردهایی را به zone دامنهٔ خود اضافه کنید و برای IP سرور نیز به یک رکورد معکوس (PTR) نیاز دارید که به hostname ایمیل شما اشاره کند. رکورد PTR تقریباً هرگز در پنل DNS شما تنظیم نمی‌شود؛ این رکورد نزد مالک IP است، بنابراین باید در پنل کنترل ارائه‌دهندهٔ VPS یا از طریق تیکت تنظیم شود.

حداقل 6 گیگابایت رم و 2 هسته vCPU برای عملکرد مطلوب. حداقلِ مورد نیاز برای mailcow جهت یک نصب شخصی، 6 گیگابایت رم به اضافه 1 گیگابایت swap است و در صورتی که چند کاربر از آن استفاده کنند، 8 گیگابایت توصیه می‌شود. در مقادیر کمتر از حدود 2.5 گیگابایت، generate_config.sh پیشنهاد می‌دهد که اسکنر ویروس ClamAV را غیرفعال کنید تا kernel شروع به کشتن containerها نکند. برای شروع، 20 گیگابایت فضای SSD اختصاص دهید.

یک نام DNS، نه فقط یک IP خام. یک hostname مانند mail.example.com انتخاب کنید. همین نام واحد، تبدیل به MAILCOW_HOSTNAME شما، موضوع گواهی TLS، مقصد PTR و بنر SMTP شما می‌شود. این نام را در همه‌جا ثابت نگه دارید.

گام 1، اطمینان از باز بودن پورت خروجی 25

این کار را در ابتدا انجام دهید. اگر این مرحله با شکست مواجه شود، سایر اقدامات بیهوده خواهد بود. از داخل VPS تازه، سعی کنید یک مکالمه SMTP با یک سرور ایمیل واقعی برقرار کنید:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25

نتیجه موفقیت‌آمیز، بلافاصله ظاهر می‌شود:

Connection to gmail-smtp-in.l.google.com (142.250.x.x) 25 port [tcp/smtp] succeeded!

پورت مسدود شده به مدت 5 ثانیه کامل معلق می‌ماند و سپس با خطا مواجه می‌شود:

nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

این وقفه (timeout) نشان‌دهنده مسدود بودن پورت است. این یک فیلتر شبکه در سمت ارائه‌دهنده خدمات است، نه فایروال محلی شما، بنابراین هیچ تغییری در تنظیمات محلی آن را رفع نمی‌کند. یک تیکت پشتیبانی ارسال کنید: "لطفاً پورت خروجی TCP 25 را برای VPS من با IP <IP> باز کنید؛ من در حال راه‌اندازی یک سرور ایمیل قانونی هستم." تا زمانی که این درخواست به نتیجه "موفقیت‌آمیز" (succeeded) نرسیده است، mailcow را نصب نکنید. توجه داشته باشید که پورت ورودی 25 (که سایر سرورها به شما متصل می‌شوند) مسیر جداگانه‌ای دارد و معمولاً باز است؛ این سمت خروجی است که ارائه‌دهندگان خدمات آن را محدود می‌کنند.

گام 2، تنظیم رکوردهای DNS در حال حاضر

اعمال تغییرات DNS زمان‌بر است، بنابراین پیش از نصب، تمام رکوردهای ممکن را منتشر کنید. فرض کنید دامنه شما example.com، میزبان ایمیل شما mail.example.com و آدرس IP شما 10.0.0.10 است. در ناحیه (zone) خود، موارد زیر را ایجاد کنید:

mail.example.com.        A      10.0.0.10
mail.example.com.        AAAA   2001:db8::10          ; only if you have IPv6
example.com.             MX  10 mail.example.com.
example.com.             TXT    "v=spf1 mx -all"
_dmarc.example.com.      TXT    "v=DMARC1; p=none; rua=mailto:postmaster@example.com"

رکورد SPF بیان می‌کند که «فقط MX من مجاز به ارسال ایمیل برای این دامنه است و بقیه باید رد شوند». سیاست DMARC را روی p=none قرار دهید تا بتوانید گزارش‌ها را بدون ریجکت شدن ایمیل‌های خودتان مانیتور کنید؛ پس از اطمینان از هم‌راستایی (alignment)، آن را به p=quarantine و سپس p=reject تغییر دهید. دو رکورد به‌صورت عمدی هنوز در اینجا وجود ندارند: DKIM که mailcow در گام 6 برای شما تولید می‌کند، و PTR که باید همین حالا در پنل ارائه‌دهنده خود تنظیم کنید.

رکورد PTR (یا همان reverse DNS) را برای 10.0.0.10 روی mail.example.com تنظیم کنید که مقدار دقیق MAILCOW_HOSTNAME است. این تنها رکوردی است که اکثر افراد فراموش می‌کنند و ارائه‌دهندگان بزرگ ایمیل بر اساس آن، پیام‌ها را رد می‌کنند. اگر پنل شما فیلد rDNS ندارد، یک تیکت پشتیبانی ارسال کنید.

گام 3، نصب Docker

نرم‌افزار mailcow به Docker Engine به همراه افزونه Compose v2 نیاز دارد. به‌جای استفاده از پکیج docker.io در اوبونتو که فاقد افزونه Compose است، از اسکریپت رسمی و راحت Docker استفاده کنید:

curl -fsSL https://get.docker.com | sudo sh
sudo docker compose version

شما باید یک خط شامل Docker Compose version v2.x را مشاهده کنید. اگر docker compose version خروجی docker: 'compose' is not a docker command را نمایش داد، به این معناست که Docker Engine نصب شده اما افزونه Compose نصب نیست. این افزونه را از مخزن Docker نصب کنید، اسکریپت بالا را دوباره اجرا کنید، یا از راهنمای مقدماتی Docker Compose ما استفاده کنید که هر دو مورد را از مخزن apt خود Docker تنظیم می‌کند.

گام 4، کلون کردن mailcow و تولید فایل پیکربندی

cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
umask
sudo ./generate_config.sh

بررسی کنید که umask مقدار 0022 را چاپ کند؛ mailcow با ماسک فایل غیرعادی اجرا نمی‌شود و یک شل root در Ubuntu 24.04 به‌صورت پیش‌فرض 0022 را ارائه می‌دهد. سپس اسکریپت تنها مورد مهم را می‌پرسد: نام دامنه کامل (FQDN). مقدار mail.example.com را وارد کنید؛ این مقدار باید دقیقاً با رکورد A و PTR شما مطابقت داشته باشد. اسکریپت فایل mailcow.conf را می‌سازد که تنها فایل محیطی (environment file) مورد استفاده کل پشته است. اگر نیاز به تغییر پورت‌های وب (HTTP_PORT، HTTPS_PORT) یا غیرفعال کردن ClamAV در سرورهای کوچک دارید، این فایل را باز کنید:

MAILCOW_HOSTNAME=mail.example.com
HTTP_PORT=80
HTTPS_PORT=443
SKIP_CLAMD=n          # set to y to drop the virus scanner on a <2.5 GiB box

SKIP_FTS=y اهرم دیگری برای سرورهای با رم کم است: جستجوی متن کامل (full-text search) دومین مصرف‌کننده حافظه است که در مستندات mailcow ذکر شده و غیرفعال کردن آن تنها باعث می‌شود نتوانید متن بدنه ایمیل‌ها را در وب‌میل جستجو کنید.

مقادیر HTTP_PORT=80 و HTTPS_PORT=443 را تغییر ندهید مگر اینکه سرویس دیگری روی میزبان از آن‌ها استفاده کند؛ کلاینت ACME داخلی mailcow برای دریافت گواهی نیاز دارد که پورت 80 از اینترنت در دسترس باشد. به همین دلیل است که نباید یک تنظیم جداگانه nginx-plus-Certbot را روی همان سرور اجرا کنید؛ mailcow گواهی TLS خود را به‌صورت داخلی صادر و تمدید می‌کند و سرویس دومی که پورت‌های 80/443 را اشغال کند، باعث اختلال در این فرآیند می‌شود. همین قاعده برای هر سرویس دیگری که نیاز به رابط وب عمومی دارد صدق می‌کند؛ بنابراین پروژه‌ای مانند Halcyon که کتابخانه Jellyfin را به شکل یک فروشگاه ویدیوی دهه 90 بازطراحی می‌کند و انتظار دارد reverse proxy اختصاصی خود را روی پورت 443 داشته باشد، باید روی میزبان دیگری اجرا شود. استثنا مربوط به سرویسی است که هرگز درخواست پورت وب عمومی نمی‌کند: یک relay خودمیزبان RustDesk فقط روی محدوده پورت‌های 21115 تا 21119 خود گوش می‌دهد، بنابراین اگر پهنای باند کافی دارید، می‌تواند در کنار mailcow روی همان سرور قرار بگیرد.

گام 5، راه‌اندازی استک و ورود به سیستم

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

عملیات pull حدود دو دوجین image را دریافت می‌کند؛ چند دقیقه منتظر بمانید. زمانی که docker compose ps وضعیت تمام کانتینرها را running (یا healthy) نشان داد، https://mail.example.com را در مرورگر باز کنید. نام کاربری پیش‌فرض برای ورود به پنل مدیریت admin و رمز عبور آن moohoo است. بلافاصله این رمز عبور را در رابط کاربری مدیریت از مسیر Access → Administrators تغییر دهید. اگر مرورگر هشدار NET::ERR_CERT_AUTHORITY_INVALID را نمایش داد، به این معنی است که گواهی ACME هنوز صادر نشده است؛ پیش از آنکه تصور کنید سیستم خراب است، بخش خطاهای ACME در ادامه را مطالعه کنید. وجود یک گواهی self-signed موقت در یکی دو دقیقه اول، امری عادی است.

گام 6، افزودن دامنه، صندوق پستی و انتشار DKIM

در رابط کاربری مدیریت، صفحه Mail Setup (مسیر Configuration → Mail Setup) را باز کنید. در زبانه Domains روی Add domain کلیک کرده و example.com را وارد کنید. سپس در بخش Mailboxes، گزینه Add mailbox را انتخاب کنید تا you@example.com به همراه یک رمز عبور ایجاد شود. این یک صندوق پستی فعال است که هم‌اکنون از طریق IMAP در دسترس است.

اکنون نوبت کلید DKIM است. به مسیر Configuration → ARC/DKIM keys بروید؛ ممکن است mailcow هنگام افزودن دامنه، کلید را به‌صورت خودکار ایجاد کرده باشد. اگر چنین نیست، در همان‌جا یک کلید بسازید؛ دامنه را انتخاب کنید، selector را روی dkim نگه دارید، طول 2048-bit را برگزینید و روی Add کلیک کنید. مقدار طولانی TXT نمایش داده شده را کپی کرده و آن را به شکل زیر منتشر کنید:

dkim._domainkey.example.com.  TXT  "v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqh...long-key...QAB"

صفحه Domains در mailcow دارای یک دکمه DNS است که تمام رکوردهای مورد انتظار را فهرست کرده و با علامت تیک سبز یا ضربدر قرمز، وضعیت انتشار واقعی آن‌ها را نشان می‌دهد. از این صفحه به عنوان چک‌لیست استفاده کنید و پیش از تست قابلیت ارسال ایمیل، وضعیت تمام ردیف‌ها را به سبز تغییر دهید. قرمز بودن ردیف DKIM پس از انتشار، معمولاً به این معناست که کلید به درستی در بخش‌های TXT تقسیم نشده است؛ یک کلید 2048-bit طولانی‌تر از حد مجاز 255 کاراکتر برای یک رشته TXT واحد است، بنابراین آن را به عنوان یک مقدار منطقی واحد وارد کنید و اجازه دهید میزبان DNS شما، آن را به قطعات مناسب تقسیم کند.

گام 7، تست قابلیت تحویل و کسب امتیاز 10/10

به سایت mail-tester.com بروید، آدرس تصادفی نمایش داده شده را کپی کنید و از صندوق پستی جدید خود پیامی به آن ارسال کنید. برای این کار، به SOGo webmail در https://mail.example.com/SOGo وارد شوید و از آنجا ایمیل بفرستید. سپس روی دکمه "Then check your score" کلیک کنید.

هدف شما کسب امتیاز 10/10 است. کسر امتیازهای رایج و دلایل آن‌ها عبارتند از:

• عدم تطابق SPF: رکورد MX/SPF شما وجود ندارد یا IP فرستنده در آن لحاظ نشده است. رکورد TXT مربوط به SPF را دوباره بررسی کنید.
• عدم تأیید امضای DKIM: رکورد TXT مربوط به dkim._domainkey وجود ندارد، هنوز در حال انتشار در شبکه است یا دچار نقص شده است. این رایج‌ترین دلیل کسر امتیاز است.
• نبود PTR یا عدم تطابق آن: رکورد reverse DNS به mail.example.com اشاره نمی‌کند. این مورد را از طریق پنل ارائه‌دهنده سرور اصلاح کنید.
• قرارگیری در لیست سیاه (Blocklist): به دلیل سابقه IP شما. درخواست خروج از لیست سیاه (delisting) بدهید یا از ارائه‌دهنده بخواهید IP تمیزتری به شما اختصاص دهد.

تا زمانی که امتیاز شما 10/10 نشده است، ایمیل واقعی به Gmail یا Outlook ارسال نکنید. امتیاز پایین به همراه یک IP جدید، باعث می‌شود دامنه شما از همان روز اول در لیست سیاه قرار بگیرد.

گام 8، اتصال یک کلاینت ایمیل واقعی

نرم‌افزار Thunderbird، Apple Mail یا گوشی خود را با تنظیمات زیر به سرور متصل کنید. میزبان سرور برای همه آن‌ها mail.example.com است:

• IMAP: پورت 993، SSL/TLS (یا 143 با STARTTLS)
• SMTP submission: پورت 465، SSL/TLS (یا 587 با STARTTLS)
• نام کاربری: آدرس کامل ایمیل، you@example.com
• رمز عبور: رمز عبوری که برای صندوق پستی تعیین کرده‌اید

هرگز ایمیل کلاینت را از طریق پورت 25 ارسال نکنید؛ این پورت فقط برای ارتباط سرور به سرور است. mailcow در این پورت امکان ارسال احراز‌هویت‌شده را فراهم نمی‌کند و اتصال کلاینت به آن رد خواهد شد. اگر کلاینت خطای Relay access denied را گزارش می‌دهد، به این معنی است که سعی دارد از طریق پورت 25 یا بدون احراز‌هویت ایمیل ارسال کند؛ تنظیمات آن را به پورت 465 یا 587 تغییر دهید و از اعتبارنامه‌های صندوق پستی خود استفاده کنید.

گام 9، پشتیبان‌گیری از داده‌های حیاتی

نرم‌افزار mailcow یک اسکریپت پشتیبان‌گیری ارائه می‌دهد که از تمام volumeهای دارای وضعیت (stateful) اسنپ‌شات تهیه می‌کند. آن را روی یک دیسک خارجی یا یک مسیر remote mount شده اجرا کنید:

sudo MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups \
  ./helper-scripts/backup_and_restore.sh backup all

all شش مورد را ذخیره می‌کند و از دست دادن هر یک از آن‌ها به معنای از دست رفتن داده‌هاست: vmail (صندوق‌های پستی واقعی)، crypt (کلیدهایی که vmail را رمزگشایی می‌کنند و بدون آن بی‌فایده هستند)، mysql (پایگاه‌داده MariaDB که دامنه‌ها، کاربران، نام‌های مستعار و تنظیمات را نگه می‌دارد)، redis (وضعیت صف و کش)، rspamd (آموزش‌های مربوط به spam/ham) و postfix (صف ایمیل). این اسکریپت درون یک کانتینر کمکی اجرا می‌شود و آرشیوهای فشرده ایجاد می‌کند، بنابراین پشتیبان‌ها حتی در حالی که stack فعال است، منسجم باقی می‌مانند. آن را با یک cron job شبانه خودکار کنید و از --delete-days 14 برای حذف مجموعه‌های قدیمی استفاده کنید. یک cron job که از کار می‌افتد، بدون اطلاع قبلی متوقف می‌شود؛ بنابراین وضعیت خروجی اسکریپت را به جایی بفرستید که واقعاً متوجه آن شوید؛ یک سرور ntfy خودمیزبان با یک دستور curl تک‌خطی در همان cron job، خرابی را در همان شب روی گوشی شما نمایش می‌دهد. بازیابی با همان اسکریپت و با استفاده از restore انجام می‌شود که اسنپ‌شات‌ها را لیست کرده و به شما اجازه می‌دهد مورد دلخواه برای بازگردانی را انتخاب کنید. پشتیبانی که هرگز بازیابی آن را تست نکرده‌اید، یک امید است، نه یک پشتیبان؛ حتماً یک بار تست بازیابی را روی یک VPS موقت انجام دهید.

گام 10، به‌روزرسانی طبق زمان‌بندی

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

cd /opt/mailcow-dockerized
sudo ./update.sh --check   # reports whether an update exists, changes nothing
sudo ./update.sh           # applies it

ابتدا نسخه پشتیبان تهیه کنید (گام 9)، زیرا بازگرداندن مهاجرت طرح‌واره (schema migration) دشوار است. به‌روزرسانی‌ها به‌طور مکرر منتشر می‌شوند و شامل اصلاحات امنیتی برای دیمون‌هایی هستند که در معرض اینترنت قرار دارند؛ بنابراین اجازه ندهید سرور ایمیل برای ماه‌ها بدون به‌روزرسانی باقی بماند. اگر به‌روزرسانی باعث شد کانتینری در وضعیت ناسالم (unhealthy) قرار گیرد، sudo docker compose logs --tail=50 <service>-mailcow نام دیمونی که در راه‌اندازی مجدد شکست خورده است را مشخص می‌کند.

نکته‌ای در مورد مقاوم‌سازی

نرم‌افزار mailcow سرویس netfilter اختصاصی خود (netfilter-mailcow) را اجرا می‌کند که IPهایی را که به پورت‌های ایمیل و وب‌میل حمله می‌کنند مسدود می‌سازد، بنابراین بخش ایمیل به‌صورت پیش‌فرض محافظت‌شده است. این موضوع شامل SSH روی خود میزبان نمی‌شود؛ SSH همچنان در معرض دید است و همچنان هدف حملات brute-force قرار می‌گیرد. این ساختار را با نظارت Fail2ban بر لاگ احراز هویت SSH و ورود فقط با کلید (key-only) ترکیب کنید. رابط کاربری مدیریت mailcow را با یک رمز عبور قوی محافظت کنید و در حالت ایده‌آل، آن را از دسترس اینترنت عمومی خارج کرده یا پشت یک VPN قرار دهید.

حالت‌های شکست، همراه با رشته‌های دقیق

ایمیل‌ها در صف می‌مانند و هرگز ارسال نمی‌شوند. دستور sudo docker compose exec postfix-mailcow postqueue -p را اجرا کنید یا صف ایمیل را در رابط کاربری مدیریت بخوانید؛ ورودی‌ها با وضعیت deferred باقی می‌مانند:

status=deferred (connect to gmail-smtp-in.l.google.com[142.250.x.x]:25: Connection timed out)

این یعنی پورت خروجی 25 توسط سرویس‌دهنده شما مسدود شده است (گام 1). هیچ تنظیماتی این مشکل را حل نمی‌کند، یک تیکت پشتیبانی باز کنید. مشکل از DNS یا TLS نیست؛ نشانه اصلی، کلمه timed out در برابر یک MX راه دور روی پورت 25 است.

جیمیل همه چیز را اسپم می‌کند یا باز می‌گرداند. پیام را در جیمیل باز کنید، گزینه "Show original" را بزنید و نتایج احراز هویت را بخوانید. dkim=fail یا dkim=none به این معنی است که رکورد dkim._domainkey TXT شما وجود ندارد، ناقص است یا هنوز منتشر نشده است؛ دقیقاً همان چیزی که صفحه ARC/DKIM نشان می‌دهد را دوباره منتشر کنید و منتظر TTL بمانید. spf=fail یعنی رکوردهای SPF/MX آی‌پی شما را پوشش نمی‌دهند. هم‌راستایی (Alignment) همه چیز است؛ تنها یک بررسی ناموفق کافی است تا ایمیل شما اسپم شناخته شود.

رد شدن توسط سرویس‌دهنده‌های بزرگ هنگام اتصال. پیام‌های بازگشتی یا لاگ‌های Postfix حاوی خطای PTR جیمیل هستند:

550-5.7.25 [10.0.0.10] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match
550 5.7.25 the sending IP. As a policy, Gmail does not accept messages from IPs
550 5.7.25 with missing PTR records.

کد 550 5.7.25 به معنای نبودن یا عدم تطابق reverse DNS است. رکورد PTR برای آی‌پی خود را در پنل سرویس‌دهنده روی mail.example.com تنظیم کنید (گام 2). رکورد Forward (A) و رکورد معکوس (PTR) باید با هم توافق داشته باشند و هر دو باید نام همان میزبانی را داشته باشند که mailcow با آن خود را به سایر سرورها معرفی می‌کند.

مرورگر هشدار گواهی نشان می‌دهد که هرگز برطرف نمی‌شود. کانتینر acme-mailcow در دریافت گواهی معتبر شکست خورده است. لاگ آن را بررسی کنید:

sudo docker compose logs acme-mailcow | tail -n 40

خطی مانند Cannot validate any hostnames, skipping Let's Encrypt for 1 hour. یا شکست در challenge به این معنی است که پورت 80 از اینترنت در دسترس نیست، یا رکورد A به این سرور اشاره نمی‌کند. اطمینان حاصل کنید که mail.example.com به این سرور resolve می‌شود، پورت‌های 80 و 443 را در فایروال میزبان باز کنید و مطمئن شوید هیچ سرویس دیگری از این پورت‌ها استفاده نمی‌کند. پس از رفع علت، به جای انتظار برای پایان دوره back-off یک‌ساعته، کلاینت را با sudo docker compose restart acme-mailcow مجدداً راه‌اندازی کنید.

FAQ

آیا میزبانی شخصی ایمیل واقعاً ارزشش را دارد؟

اگر به دنبال مالکیت داده‌ها، نام‌های مستعار نامحدود و کنترل کامل هستید، بله؛ mailcow یک پشته حرفه‌ای را با هزینه یک VPS در اختیار شما می‌گذارد. اما تحویل‌پذیری ایمیل یک وظیفه دائمی است: اعتبار IP، هم‌راستایی DNS و نظارت بر لیست‌های سیاه هرگز به‌طور کامل پایان نمی‌یابند. برای یک آدرس ایمیل حیاتی در کسب‌وکار که قرار گرفتن یک‌روزه آن در پوشه اسپم دیگران برای شما هزینه دارد، استفاده از یک ارائه‌دهنده مدیریت‌شده انتخاب منطقی‌تری است. زمانی سراغ میزبانی شخصی بروید که کنترل را به راحتی ترجیح می‌دهید و واقعاً قصد دارید از آن نگهداری کنید. اگر هدف اصلی شما صرفاً خارج کردن داده‌ها از سرورهای دیگران است و نه لزوماً ایمیل، با سرویسی شروع کنید که کسی در آن دخیل نیست: یک کتابخانه عکس هیچ مشکلی در زمینه تحویل‌پذیری ندارد و مقایسه ما بین PhotoPrism و Immich حداقل حافظه RAM و دستورات پشتیبان‌گیری برای چنین پیاده‌سازی‌هایی را روی همان نوع VPS پوشش می‌دهد.

چگونه بفهمم پورت خروجی 25 مسدود است؟

دستور nc -vz -w 5 gmail-smtp-in.l.google.com 25 را از روی سرور اجرا کنید. عبارت "succeeded!" به معنای باز بودن آن است؛ یک timed out پس از مکث، نشان می‌دهد که ارائه‌دهنده شما آن را مسدود کرده است. این رایج‌ترین دلیل برای وضعیتی است که سرور شخصی شما می‌تواند ایمیل دریافت کند اما قادر به ارسال نیست، و تنها راه حل آن باز کردن پورت توسط ارائه‌دهنده است؛ هیچ تنظیمات محلی نمی‌تواند این محدودیت را تغییر دهد.

چرا ایمیل‌های من همچنان در پوشه اسپم Gmail قرار می‌گیرند؟

تقریباً همیشه به دلیل زنجیره احراز هویت ناقص است. در Gmail گزینه "Show original" را بزنید و به دنبال spf=pass، dkim=pass و dmarc=pass بگردید. یک dkim=fail نشان‌دهنده رکورد TXT ناقص یا اشتباه dkim._domainkey است؛ عدم تطابق PTR یا یک IP جدید بدون سابقه ارسال نیز به اعتبار شما لطمه می‌زند. ابتدا امتیاز 10/10 را از mail-tester.com بگیرید، سپس IP خود را به‌آرامی گرم کنید؛ روزانه چند پیام بفرستید و به‌تدریج حجم آن را افزایش دهید، به‌جای اینکه از همان روز اول حجم زیادی ایمیل ارسال کنید.

دقیقاً از چه چیزی باید پشتیبان بگیرم؟

دستور backup_and_restore.sh backup all را اجرا کنید و کل مجموعه را خارج از سرور نگه دارید. این دستور vmail (صندوق‌های پستی)، crypt (کلیدهایی که آن‌ها را رمزگشایی می‌کنند)، دیتابیس MariaDB (دامنه‌ها، کاربران، نام‌های مستعار، تنظیمات)، Redis، داده‌های یادگیری‌شده Rspamd و صف Postfix را ضبط می‌کند. حجم crypt همان چیزی است که افراد نادیده می‌گیرند؛ بدون آن، پشتیبان vmail فقط متن رمزنگاری‌شده غیرقابل خواندن است. حداقل یک‌بار بازیابی را روی یک سیستم آزمایشی تست کنید.

آیا می‌توانم mailcow را روی یک VPS با 2 گیگابایت رم اجرا کنم؟

به‌راحتی خیر. generate_config.sh پیشنهاد می‌دهد که ClamAV را در مقادیر کمتر از حدود 2.5 گیگابایت غیرفعال کنید، و حتی در آن صورت هم Rspamd، ClamAV، Dovecot و MariaDB برای حافظه با هم رقابت می‌کنند؛ بنابراین تحت هر بار کاری واقعی، با مشکل swap و OOM kill مواجه خواهید شد. برای یک نصب پایدار تک‌کاربره، 6 گیگابایت رم به همراه 1 گیگابایت swap را حداقل در نظر بگیرید و به‌محض اینکه بیش از چند نفر به آن وابسته شدند، به 8 گیگابایت ارتقا دهید.