VPS پر mailcow: Gmail سے قبول ہونے والی email hosting

آپ کیا بنا رہے ہیں

آپ اپنے زیرِ انتظام سرور پر مکمل mail server بنا رہے ہیں: SMTP کے ذریعے mail بھیجنے اور وصول کرنے کے لیے، IMAP کے ذریعے phone اور laptop کو synchronized رکھنے کے لیے، webmail client، اور spam filter جو دونوں سمتوں میں ہر message کی درجہ بندی کرے۔ mailcow-dockerized، Postfix، Dovecot، Rspamd، SOGo webmail، MariaDB، Redis اور ACME client کو ایک Docker Compose stack میں یکجا کرتا ہے، اس لیے software خود مشکل حصہ نہیں ہے۔ یہ 30 منٹ میں چلنے لگے گا۔

مشکل حصہ اس کے گرد موجود ہر چیز ہے۔ Email واحد ایسی service ہے جس میں باقی internet نئے server پر فعال طور پر عدم اعتماد کرتا ہے۔ "یہ کام کرتا ہے" اور "Gmail خاموشی سے ہر message ضائع کر دیتا ہے" کے درمیان فرق 4 DNS records اور IP reputation کی ایک setting پر منحصر ہوتا ہے، جس پر آپ کا مکمل اختیار ممکن نہیں۔ کچھ بھی rent کرنے سے پہلے ذیل کی prerequisites پڑھیں۔ اگر انہیں پڑھنے کے بعد آپ فیصلہ کریں کہ reputation بنانے کی محنت اس قابل نہیں، تو یہ ایک جائز جواب ہے۔ 2026 میں واقعی self-hosting کے قابل چیزوں کا ہمارا جائزہ انہی وجوہات کی بنا پر email کو "صرف اس صورت میں جب آپ واقعی سنجیدہ ہوں" کے زمرے میں رکھتا ہے۔

ضروریات ہی پورا منصوبہ ہیں

ان میں سے کوئی ایک چیز بھی رہ جائے تو آپ ایسی mail بھیجیں گے جو کبھی وصول نہیں ہوگی۔ ذیل میں ترتیب تقریباً اس بنیاد پر ہے کہ کون سی چیز اکثر لوگوں کے منصوبے کو ناکام بناتی ہے:

بیرونی port 25 کھلا ہونا ضروری ہے۔ آپ کا server Gmail اور Microsoft کو TCP port 25 کے ذریعے mail فراہم کرتا ہے۔ Spam کے خلاف اقدامات کے طور پر بہت سے VPS اور cloud providers outbound 25 کو default طور پر block کر دیتے ہیں۔ یہ block خاموشی سے ہوتا ہے: boot کے وقت کوئی error ظاہر نہیں ہوتا، سب کچھ درست دکھائی دیتا ہے، اور mail ہمیشہ کے لیے queue میں پڑی رہتی ہے۔ کچھ بھی install کرنے سے پہلے اس کی جانچ کریں۔ اگر یہ block ہو تو واحد حل support ticket کے ذریعے اپنے provider سے اسے کھلوانے کی درخواست کرنا ہے۔ کچھ providers پرانے accounts کے لیے یہ port کھول دیتے ہیں، جبکہ کچھ کبھی نہیں کھولتے۔

قابل استعمال reputation والا صاف IP۔ Recycled VPS IPs اکثر پچھلے tenant کی spam سرگرمی کے باعث پہلے ہی blocklists میں شامل ہوتے ہیں۔ فیصلہ کرنے سے پہلے Spamhaus lookup یا mxtoolbox جیسی service سے اپنا IP چیک کریں۔ Listed IP کی وجہ سے ہونے والی rejections کو code کے ذریعے دور نہیں کیا جا سکتا۔

DNS پر اختیار اور درست PTR record۔ آپ کو اپنے domain کی zone میں records شامل کرنے ہوں گے، اور server کے IP کے لیے reverse DNS (PTR) درکار ہوگا جو واپس آپ کے mail hostname کی طرف اشارہ کرے۔ PTR تقریباً کبھی بھی آپ کے DNS panel میں set نہیں ہوتا۔ یہ اس فریق کے اختیار میں ہوتا ہے جو IP کا مالک ہے، اس لیے اسے اپنے VPS provider کے control panel یا support ticket کے ذریعے set کریں۔

6 GiB RAM اور 2 vCPU آرام دہ کم از کم سطح ہے۔ Private install کے لیے mailcow کی اپنی minimum requirement 6 GiB RAM کے ساتھ 1 GiB swap ہے۔ جب چند users اس پر انحصار کرنے لگیں تو 8 GiB RAM تجویز کی جاتی ہے۔ تقریباً 2.5 GiB سے کم RAM پر generate_config.sh ClamAV virus scanner کو disable کرنے کی پیشکش کرتا ہے، تاکہ kernel containers کو terminate کرنا شروع نہ کرے۔ ابتدا میں اسے 20 GB SSD space دیں۔

DNS name استعمال کریں، صرف IP نہیں۔ mail.example.com جیسا hostname منتخب کریں۔ یہی نام آپ کا MAILCOW_HOSTNAME، آپ کے TLS certificate کا subject، آپ کا PTR target، اور آپ کا SMTP banner بن جاتا ہے۔ ہر جگہ یہی نام مستقل طور پر استعمال کریں۔

مرحلہ 1، تصدیق کریں کہ outbound port 25 کھلا ہے

یہ کام سب سے پہلے کریں۔ اگر یہ ناکام ہو جائے تو باقی تمام کوششیں بے فائدہ ہیں۔ نئے VPS سے کسی حقیقی mail server کے ساتھ 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!

blocked port پورے پانچ سیکنڈ تک hang رہتا ہے، پھر ناکام ہو جاتا ہے:

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

یہ timeout ہی block کی علامت ہے۔ یہ provider-side network filter ہے، آپ کے firewall کا مسئلہ نہیں۔ اس لیے کوئی مقامی تبدیلی اسے درست نہیں کر سکتی۔ یہ ticket کھولیں: "Please enable outbound TCP port 25 for my VPS at <IP>; I am running a legitimate mail server." جب تک اس کا نتیجہ "succeeded" نہ آئے، mailcow انسٹال نہ کریں۔ یاد رکھیں کہ inbound 25، یعنی دوسرے servers کا آپ تک پہنچنا، الگ path ہے اور عموماً کھلا ہوتا ہے۔ Providers عموماً outbound side کو محدود کرتے ہیں۔

مرحلہ 2، ابھی DNS records ترتیب دیں

DNS کی تبدیلیاں پھیلنے میں وقت لیتی ہیں، اس لیے installation سے پہلے وہ تمام records publish کر دیں جو ممکن ہوں۔ فرض کریں کہ آپ کا domain example.com، mail host mail.example.com، اور IP 10.0.0.10 ہے۔ اپنے zone میں یہ records بنائیں:

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 record کا مطلب ہے: "اس domain کے لیے صرف میرا MX mail بھیج سکتا ہے، باقی سب کو مسترد کریں"۔ DMARC کو p=none پر شروع کریں تاکہ آپ اپنی mail کو مسترد کیے بغیر reports دیکھ سکیں؛ alignment ثابت ہو جانے کے بعد اسے p=quarantine، پھر p=reject تک سخت کریں۔ جان بوجھ کر دو records ابھی باقی رکھے گئے ہیں: DKIM، جسے mailcow آپ کے لیے مرحلہ 6 میں generate کرے گا، اور PTR، جسے آپ ابھی اپنے provider کے panel میں set کریں گے۔

10.0.0.10 کے لیے PTR (reverse DNS) کو mail.example.com پر set کریں، جو MAILCOW_HOSTNAME کی exact value ہے۔ زیادہ تر لوگ یہی واحد record بھولتے ہیں، اور بڑے providers اسی بنیاد پر mail reject کرتے ہیں۔ اگر آپ کے panel میں rDNS field موجود نہ ہو تو ticket raise کریں۔

مرحلہ 3، Docker انسٹال کریں

mailcow کو Compose v2 plugin کے ساتھ Docker Engine درکار ہے۔ Ubuntu کے docker.io package کے بجائے Docker کا official convenience script استعمال کریں، کیونکہ اس package میں Compose plugin شامل نہیں ہوتا:

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

آپ کو Docker Compose version v2.x لائن نظر آنی چاہیے۔ اگر docker compose version کا output docker: 'compose' is not a docker command ہو تو Docker Engine انسٹال ہے، لیکن Compose plugin موجود نہیں۔ Plugin کو Docker کے repository سے انسٹال کریں، اوپر دیا گیا script دوبارہ چلائیں، یا ہماری Docker Compose basics گائیڈ دیکھیں، جو Docker کے اپنے apt repository سے دونوں اجزا ترتیب دیتی ہے۔

مرحلہ 4، mailcow کو کلون کریں اور configuration تیار کریں

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

یقینی بنائیں کہ umask پہلے 0022 دکھاتا ہے۔ غیر معمولی file mask کی صورت میں mailcow build کرنے سے انکار کر دیتا ہے، جبکہ تازہ Ubuntu 24.04 root shell میں پہلے ہی 0022 موجود ہوتا ہے۔ اس کے بعد script وہ واحد اہم چیز پوچھتی ہے: مکمل طور پر qualified hostname۔ mail.example.com درج کریں۔ اس کی value آپ کے A record اور PTR سے عین match ہونی چاہیے۔ یہ mailcow.conf لکھتی ہے، جو پوری stack کے زیرِ استعمال واحد environment file ہے۔ اگر web ports (HTTP_PORT، HTTPS_PORT) تبدیل کرنے ہوں یا کم وسائل والے server پر ClamAV کو disable کرنا ہو تو اسے کھولیں:

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

کم RAM والے server پر SKIP_FTS=y بھی اہم setting ہے۔ mailcow کی دستاویزات کے مطابق full-text search memory استعمال کرنے والی دوسری بڑی خصوصیت ہے، اور اسے skip کرنے سے صرف webmail میں body-text search دستیاب نہیں رہتی۔

HTTP_PORT=80 اور HTTPS_PORT=443 کو تبدیل نہ کریں، الاّ یہ کہ host پر کوئی دوسری سروس پہلے ہی ان ports کو استعمال کر رہی ہو۔ certificate حاصل کرنے کے لیے mailcow کے built-in ACME client کو internet سے port 80 تک رسائی درکار ہوتی ہے۔ اسی لیے اسی server پر الگ nginx-plus-Certbot setup نہ چلائیں۔ mailcow اندرونی طور پر اپنے TLS certificates جاری اور renew کرتا ہے، اور port 80/443 پر موجود دوسری سروس اس عمل میں رکاوٹ ڈالتی ہے۔ یہی اصول ہر اس سروس پر لاگو ہوتا ہے جسے public web front end درکار ہو۔ اس لیے Halcyon کے ذریعے Jellyfin library کو 90s کی video store شکل دینا جیسے setup کو، جو port 443 پر اپنے reverse proxy کی توقع رکھتا ہے، دوسرے host پر چلائیں۔ البتہ وہ سروس اس سے مستثنیٰ ہے جو public web port کا مطالبہ ہی نہیں کرتی۔ self-hosted RustDesk relay صرف اپنی 21115 سے 21119 تک کی range پر listen کرتا ہے، اس لیے اضافی bandwidth دستیاب ہو تو اسے اسی server پر چلایا جا سکتا ہے۔

مرحلہ 5، stack شروع کریں اور لاگ اِن کریں

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

اس pull کے دوران تقریباً دو درجن images download ہوں گی؛ اسے چند منٹ دیں۔ جب docker compose ps میں ہر container running (یا healthy) دکھائی دے، تو browser میں https://mail.example.com کھولیں۔ default admin login میں username admin اور password moohoo ہے۔ Access → Administrators کے تحت admin UI میں یہ password فوراً تبدیل کریں۔ اگر browser NET::ERR_CERT_AUTHORITY_INVALID کی warning دے تو ACME certificate ابھی جاری نہیں ہوا۔ اسے broken سمجھنے سے پہلے نیچے دی گئی ACME failure دیکھیں؛ پہلے 1 یا 2 منٹ کے لیے self-signed placeholder معمول کی بات ہے۔

مرحلہ 6، domain، mailbox شامل کریں اور DKIM شائع کریں

admin UI میں Mail Setup صفحہ کھولیں (Configuration → Mail Setup)، پھر Domains ٹیب میں Add domain پر کلک کریں اور example.com درج کریں۔ اس کے بعد Mailboxes کے تحت Add mailbox منتخب کرکے you@example.com بنائیں اور password مقرر کریں۔ یہ mailbox پہلے ہی IMAP کے ذریعے قابل رسائی ہوگا۔

اب DKIM key بنائیں۔ Configuration → ARC/DKIM keys پر جائیں۔ domain شامل کرتے وقت mailcow ممکن ہے پہلے ہی key بنا چکا ہو۔ اگر ایسا نہ ہو تو وہیں key generate کریں، domain منتخب کریں، selector dkim برقرار رکھیں، 2048-bit منتخب کریں اور Add پر کلک کریں۔ دکھائی جانے والی طویل TXT value کو copy کرکے اسے یوں publish کریں:

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

mailcow کے Domains صفحے پر DNS بٹن موجود ہے۔ یہ متوقع ہر record کی فہرست دکھاتا ہے اور ہر record کے سامنے actual published حالت کے مطابق green tick یا red cross دکھاتا ہے۔ اسے checklist کے طور پر استعمال کریں۔ deliverability کی testing سے پہلے ہر row کو green کریں۔ publish کرنے کے بعد DKIM row کا red رہنا عموماً اس بات کی علامت ہے کہ key کو TXT chunks میں غلط طریقے سے تقسیم کیا گیا ہے۔ 2048-bit key ایک TXT string کے لیے 255-character limit سے طویل ہوتی ہے، اس لیے اسے ایک logical value کے طور پر paste کریں اور اپنے DNS host کو اسے chunks میں تقسیم کرنے دیں۔

مرحلہ 7، deliverability کی جانچ کریں اور 10/10 حاصل کریں

mail-tester.com پر جائیں، وہاں دکھایا گیا عارضی address copy کریں، اور اپنے نئے mailbox سے اس پر message بھیجیں۔ https://mail.example.com/SOGo پر SOGo webmail میں login کریں اور وہیں سے message بھیجیں۔ پھر "Then check your score" پر click کریں۔

10/10 کا ہدف رکھیں۔ عام کٹوتیاں اور ان کی وجوہات یہ ہیں:

• SPF not aligned، آپ کا MX/SPF record موجود نہیں ہے یا sending IP اس میں شامل نہیں ہے۔ SPF TXT دوبارہ check کریں۔
• DKIM signature does not verify، dkim._domainkey TXT موجود نہیں، ابھی propagate نہیں ہوا، یا خراب ہو گیا ہے۔ یہ سب سے عام غلطی ہے۔
• No PTR / PTR mismatch، reverse DNS سے mail.example.com resolve نہیں ہوتا۔ اسے provider کے پاس درست کریں۔
• Listed on a blocklist، آپ کے IP کی سابقہ reputation اس کی وجہ ہے۔ delisting کی درخواست کریں یا زیادہ صاف reputation والا IP مانگیں۔

جب تک نتیجہ 10/10 نہ ہو، Gmail یا Outlook کو حقیقی mail نہ بھیجیں۔ کم score اور نیا IP مل کر پہلے ہی دن آپ کے domain کو flag کروا سکتے ہیں۔

مرحلہ 8، حقیقی mail client مربوط کریں

ان settings کے ذریعے Thunderbird، Apple Mail یا اپنے phone کو server سے مربوط کریں۔ سب کے لیے server host mail.example.com ہے:

• IMAP: port 993، SSL/TLS (یا STARTTLS کے ساتھ 143)
• SMTP submission: port 465، SSL/TLS (یا STARTTLS کے ساتھ 587)
• Username: مکمل address، you@example.com
• Password: وہ mailbox password جو آپ نے set کیا ہے

client mail کو کبھی بھی port 25 کے ذریعے نہ بھیجیں۔ یہ port صرف server-to-server mail کے لیے ہے۔ mailcow وہاں authenticated submission فراہم نہیں کرتا، اس لیے اس port پر configured client کی request مسترد کر دی جاتی ہے۔ اگر client Relay access denied کی اطلاع دے تو وہ port 25 پر یا authentication کے بغیر mail بھیجنے کی کوشش کر رہا ہے۔ اسے اپنی mailbox credentials کے ساتھ 465 یا 587 پر تبدیل کریں۔

مرحلہ 9، صرف واقعی اہم ڈیٹا کا بیک اپ لیں

mailcow ایک backup script فراہم کرتا ہے جو ہر stateful volume کا snapshot لیتا ہے۔ اسے کسی external disk یا mounted remote پر چلائیں:

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

all چھ چیزوں کا backup لیتا ہے، اور ان میں سے کسی ایک کے ضائع ہونے سے data ضائع ہو جاتا ہے: vmail (اصل mailboxes)، crypt (وہ keys جو vmail کو decrypt کرتی ہیں؛ ان کے بغیر یہ بے کار ہیں)، mysql (وہ MariaDB database جس میں domains، users، aliases اور settings محفوظ ہوتی ہیں)، redis (queue اور cache کی state)، rspamd (سیکھا ہوا spam/ham data)، اور postfix (mail queue)۔ یہ script ایک helper container کے اندر چلتی ہے اور compressed archives لکھتی ہے، اس لیے stack کے فعال ہونے کے دوران بھی backups consistent رہتے ہیں۔ اسے nightly cron job کے ذریعے خودکار بنائیں، اور پرانے sets حذف کرنے کے لیے --delete-days 14 شامل کریں۔ جو cron job کام کرنا بند کر دے وہ خاموشی سے fail ہو سکتی ہے، اس لیے script کا exit status ایسی جگہ بھیجیں جہاں آپ واقعی اسے دیکھ سکیں؛ self-hosted ntfy server اسی cron entry سے ایک سطر کی curl request لیتا ہے اور failure کے وقت اسی رات آپ کے phone پر اطلاع بھیج دیتا ہے۔ Restore کے لیے اسی script کو restore کے ساتھ چلائیں؛ یہ snapshots کی فہرست دکھاتی ہے اور آپ کو مطلوبہ data واپس لانے کا انتخاب دیتی ہے۔ ایسا backup جسے آپ نے کبھی test-restore نہیں کیا، backup نہیں بلکہ صرف امید ہے؛ کسی scratch VPS پر ایک dry run ضرور کریں۔

مرحلہ 10، مقررہ شیڈول کے مطابق اپ ڈیٹ کریں

mailcow اپنے اسکرپٹ کے ذریعے اپ ڈیٹ ہوتا ہے۔ یہ اسکرپٹ نیا کوڈ حاصل کرتا ہے، mailcow.conf کو migrate کرتا ہے، images پہلے سے حاصل کرتا ہے، اور containers کو ترتیب کے مطابق restart کرتا ہے:

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

پہلے backup لیں (مرحلہ 9)، کیونکہ schema migration کو واپس پلٹانا مشکل ہوتا ہے۔ اپ ڈیٹس باقاعدگی سے جاری ہوتی ہیں اور internet-facing daemons کے لیے security fixes شامل کرتی ہیں، اس لیے mail server کو کئی ماہ تک اپ ڈیٹ کے بغیر نہ چھوڑیں۔ اگر کسی اپ ڈیٹ کے بعد کوئی container غیر صحت مند رہ جائے تو sudo docker compose logs --tail=50 <service>-mailcow اس daemon کا نام بتاتا ہے جو دوبارہ شروع نہیں ہو سکا۔

سخت حفاظتی اقدامات کے بارے میں نوٹ

mailcow اپنی netfilter سروس (netfilter-mailcow) چلاتا ہے، جو mail اور webmail ports پر مسلسل درخواستیں بھیجنے والے IPs کو ban کر دیتی ہے۔ اس لیے mail side پہلے سے محفوظ رہتی ہے۔ تاہم، یہ host پر موجود SSH کا احاطہ نہیں کرتی۔ SSH اب بھی exposed رہتا ہے اور اس پر brute-force حملے ہوتے رہتے ہیں۔ اس build کے ساتھ Fail2ban کو SSH auth log monitor کرنے اور صرف key-based login کا استعمال کریں۔ mailcow admin UI کے لیے مضبوط password رکھیں اور بہتر یہ ہے کہ اسے public internet سے دور رکھیں یا VPN کے پیچھے رکھیں۔

خرابی کی صورتیں، اور عین strings

Mail queues میں پیغامات جمع ہوتے ہیں اور کبھی deliver نہیں ہوتے۔ sudo docker compose exec postfix-mailcow postqueue -p چلائیں، یا admin UI کی mail queue دیکھیں؛ entries deferred حالت میں اس پیغام کے ساتھ رہتی ہیں:

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

اس کا مطلب ہے کہ آپ کے provider نے outbound port 25 block کر رکھا ہے (Step 1)۔ کوئی configuration اسے درست نہیں کر سکتی؛ support ticket کھولیں۔ مسئلہ DNS یا TLS کا نہیں ہے؛ اس کی واضح علامت remote MX کے خلاف port 25 پر timed out کا ظاہر ہونا ہے۔

Gmail ہر پیغام کو spam قرار دیتا ہے یا واپس کر دیتا ہے۔ Gmail میں message کھولیں، "Show original" منتخب کریں، اور authentication results پڑھیں۔ dkim=fail یا dkim=none کا مطلب ہے کہ آپ کا dkim._domainkey TXT record غائب، خراب، یا ابھی propagate نہیں ہوا۔ ARC/DKIM page پر دکھائی گئی قدر کو بعینہٖ دوبارہ publish کریں اور TTL مکمل ہونے کا انتظار کریں۔ spf=fail کا مطلب ہے کہ SPF/MX records آپ کے IP کو cover نہیں کرتے۔ Alignment بنیادی اہمیت رکھتی ہے؛ صرف ایک check fail ہونا بھی message کو spam میں پہنچانے کے لیے کافی ہے۔

Connect کے وقت بڑے providers reject کرتے ہیں۔ Bounces یا Postfix logs میں Gmail کی PTR rejection شامل ہوتی ہے:

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 code کا مطلب ہے کہ reverse DNS غائب ہے یا match نہیں کرتا۔ Provider کے portal میں اپنے IP کے لیے PTR کو mail.example.com پر set کریں (Step 2)۔ Forward (A) اور reverse (PTR) records کا باہمی مطابقت رکھنا ضروری ہے، اور دونوں میں وہی host نام ہونا چاہیے جس کے نام سے mailcow دوسرے servers کو greet کرتا ہے۔

Browser ایسی certificate warning دکھاتا ہے جو ختم نہیں ہوتی۔ acme-mailcow container حقیقی certificate حاصل کرنے میں ناکام رہا۔ اس کا log دیکھیں:

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

Cannot validate any hostnames, skipping Let's Encrypt for 1 hour. جیسی line یا challenge failure کا مطلب ہے کہ port 80 internet سے reachable نہیں ہے، یا A record اس server کی طرف point نہیں کرتا۔ تصدیق کریں کہ mail.example.com اس box پر resolve ہوتا ہے، کسی بھی host firewall کے ذریعے 80 اور 443 کھلے ہیں، اور کوئی دوسری service ان ports پر bind نہیں ہے۔ وجہ درست کرنے کے بعد client کو sudo docker compose restart acme-mailcow کے ذریعے restart کریں؛ ایک گھنٹے کے back-off کے ختم ہونے کا انتظار نہ کریں۔

FAQ

کیا self-hosting email واقعی قابلِ قدر ہے؟

اگر آپ data ownership، لامحدود aliases اور مکمل control چاہتے ہیں تو ہاں، mailcow ایک VPS کی قیمت میں professional stack فراہم کرتا ہے۔ لیکن deliverability کی نگرانی مسلسل کام ہے: IP reputation، DNS alignment اور blocklist monitoring کبھی مکمل طور پر ختم نہیں ہوتے۔ اگر یہ کسی mission-critical business address کے لیے ہے، جہاں کسی شخص کے spam folder میں ایک دن پہنچنے سے آپ کو نقصان ہوتا ہے، تو managed provider عملی انتخاب ہے۔ Self-hosting اس وقت کریں جب آپ convenience کے بجائے control کو ترجیح دیتے ہوں اور اس کی باقاعدہ دیکھ بھال کر سکتے ہوں۔ اگر آپ کی اصل ضرورت email کے بجائے اپنا data کسی اور کے servers سے ہٹانا ہے تو ایسی service سے شروع کریں جس پر کسی اور کا اختیار نہ ہو: photo library کو deliverability کا مسئلہ بالکل نہیں ہوتا، اور ہمارا PhotoPrism اور Immich موازنہ اسی نوعیت کے VPS پر اس build کے لیے RAM requirements اور backup commands کا احاطہ کرتا ہے۔

مجھے کیسے معلوم ہو کہ outbound port 25 blocked ہے؟

سرور سے nc -vz -w 5 gmail-smtp-in.l.google.com 25 چلائیں۔ "succeeded!" کا مطلب ہے کہ port کھلا ہے؛ pause کے بعد timed out کا مطلب ہے کہ provider نے اسے block کیا ہوا ہے۔ یہ سب سے عام وجہ ہے کہ self-hosted server mail وصول کر سکتا ہے لیکن کبھی بھی بھیج نہیں سکتا، اور واحد حل provider کا port کھولنا ہے؛ مقامی settings میں کوئی تبدیلی اسے درست نہیں کرتی۔

میری mail اب بھی Gmail کے spam folder میں کیوں پہنچتی ہے؟

تقریباً ہمیشہ وجہ authentication chain کا خراب ہونا ہوتی ہے۔ Gmail میں "Show original" استعمال کریں اور spf=pass، dkim=pass اور dmarc=pass تلاش کریں۔ dkim=fail موجود نہ ہونے یا غلط بنائے گئے dkim._domainkey TXT record کی نشاندہی کرتا ہے؛ PTR mismatch یا نئی IP جس کی sending history نہ ہو، بھی نقصان دہ ہے۔ پہلے mail-tester.com پر 10/10 حاصل کریں، پھر IP کو آہستہ آہستہ warm up کریں: روزانہ چند messages سے شروع کرکے تعداد بڑھائیں، پہلے دن ہی بہت زیادہ volume نہ بھیجیں۔

مجھے backup میں عین کیا کچھ شامل کرنا چاہیے؟

backup_and_restore.sh backup all چلائیں اور پورا set سرور سے باہر محفوظ رکھیں۔ اس میں vmail، یعنی mailboxes، crypt، یعنی انہیں decrypt کرنے والی keys، MariaDB database، یعنی domains، users، aliases اور settings، Redis، Rspamd کا learned data، اور Postfix queue شامل ہوتے ہیں۔ crypt volume وہ چیز ہے جسے لوگ اکثر نظرانداز کر دیتے ہیں؛ اس کے بغیر vmail backup ناقابلِ مطالعہ ciphertext ہوتا ہے۔ کم از کم ایک بار scratch box پر restore کی جانچ کریں۔

کیا میں mailcow کو 2 GB VPS پر چلا سکتا ہوں؟

آرام سے نہیں۔ generate_config.sh تقریباً 2.5 GiB سے کم memory پر ClamAV کو disable کرنے کی پیشکش کرتا ہے، لیکن اس کے باوجود Rspamd، ClamAV، Dovecot اور MariaDB memory کے لیے مقابلہ کرتے ہیں، اس لیے حقیقی load میں swap استعمال ہوگا اور OOM kills واقع ہوں گے۔ مستحکم single-user install کے لیے 6 GiB کے ساتھ 1 GiB swap کو کم از کم حد سمجھیں، اور جیسے ہی دو سے زیادہ افراد اس پر انحصار کریں، 8 GiB پر منتقل ہو جائیں۔