mailcow על VPS: שרת דואר ש-Gmail מקבל

מה אתם בונים

שרת דואר מלא על שרת שבבעלותכם: SMTP לשליחה ולקבלה, IMAP כדי שהטלפון והמחשב הנייד יישארו מסונכרנים, ממשק webmail, ומסנן spam שמדרג כל הודעה בשני הכיוונים. mailcow-dockerized מאגד את Postfix,‏ Dovecot,‏ Rspamd,‏ webmail של SOGo,‏ MariaDB,‏ Redis ולקוח ACME למחסנית Docker Compose אחת, ולכן התוכנה אינה החלק הקשה. בתוך חצי שעה השרת יהיה פעיל.

החלק הקשה הוא כל מה שמסביב. דואר אלקטרוני הוא השירות היחיד שבו שאר האינטרנט אינו נותן אמון פעיל בשרת חדש, והפער בין "זה עובד" לבין "Gmail בולע בשקט כל הודעה" תלוי בעיקר ב־4 רשומות DNS ובהגדרת מוניטין אחת של כתובת IP, שלא בהכרח נמצאת בשליטתכם המלאה. קראו את דרישות הקדם שלהלן לפני שאתם שוכרים דבר. אם לאחר הקריאה תחליטו שהמאמץ הנדרש לבניית מוניטין אינו מצדיק את עצמו, זו תשובה לגיטימית. הסקירה שלנו על מה באמת כדאי לארח בעצמכם ב־2026 מסווגת את הדואר האלקטרוני תחת "רק אם אתם באמת מתכוונים לכך" בדיוק מהסיבות האלה.

תנאי הקדם הם הפרויקט

אם אחד מהתנאים האלה חסר, תשלחו דואר שלעולם לא יגיע. זהו סדר משוער לפי התדירות שבה כל תנאי גורם לבעיות:

פורט 25 יוצא חייב להיות פתוח. השרת שלכם מוסר דואר ל־Gmail ול־Microsoft דרך TCP פורט 25. חלק גדול מספקי ה־VPS והענן חוסמים כברירת מחדל תעבורה יוצאת בפורט 25 כדי להילחם בספאם. החסימה שקטה: לא מתקבלת שגיאה בעת האתחול, הכול נראה תקין, והדואר נשאר במצב מושהה בתור עד ש־Postfix מוותר ומחזיר אותו לשולח. ‏mailcow מגדיר את משך החיים המרבי של התור לחמישה ימים. בדקו זאת לפני התקנת דבר כלשהו. אם הפורט חסום, הפתרון היחיד הוא לפתוח קריאת תמיכה ולבקש מהספק לפתוח אותו. ספקים מסוימים עושים זאת עבור חשבונות ותיקים, ואחרים לעולם לא יפתחו אותו.

כתובת IP נקייה, עם מוניטין שמאפשר שימוש. כתובות IP ממוחזרות של VPS כבר נמצאות לעיתים קרובות ברשימות חסימה עקב ספאם של דייר קודם. בדקו את הכתובת שלכם בשירות כגון חיפוש Spamhaus או mxtoolbox לפני שאתם מתחייבים. כתובת IP שמופיעה ברשימה תגרום לדחיות שלא תוכלו לפתור באמצעות שינוי קוד.

שליטה ב־DNS ורשומת PTR תקינה. עליכם להוסיף רשומות לאזור של המתחם שלכם, ולהגדיר DNS הפוך (PTR) עבור כתובת ה־IP של השרת, כך שיצביע בחזרה אל שם המתחם של שרת הדואר. רשומת PTR כמעט אף פעם אינה מוגדרת בלוח הבקרה של ה־DNS שלכם. היא מנוהלת אצל הגורם שמחזיק בכתובת ה־IP, ולכן מגדירים אותה בלוח הבקרה של ספק ה־VPS או באמצעות קריאת תמיכה.

6 GiB RAM ו־2 vCPU הם רף נוח להתחלה. דרישת המינימום של mailcow עצמו היא 6 GiB RAM ועוד 1 GiB swap להתקנה פרטית. לאחר שכמה משתמשים מסתמכים על המערכת, מומלץ להשתמש ב־8 GiB. מתחת לכ־2.5 GiB, generate_config.sh מציע להשבית את סורק הווירוסים ClamAV, כדי שה־kernel לא יתחיל לעצור מכולות. דרישת המינימום המתועדת של mailcow לדיסק היא 20 GiB לפני שמאוחסן דואר כלשהו. לכן התחילו עם יותר מכך והשאירו מקום לגדילת תיבות הדואר.

שם DNS, ולא כתובת IP בלבד. בחרו שם מארח כגון mail.example.com. אותו שם משמש כ־MAILCOW_HOSTNAME, כנושא של תעודת ה־TLS, כיעד של רשומת ה־PTR וכ־SMTP banner. הקפידו להשתמש בו באופן עקבי בכל מקום.

שלב 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!

פורט חסום ממתין במשך חמש השניות המלאות ולאחר מכן נכשל:

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

ב־VPS חדש, ללא כללי firewall יוצאים שהגדרתם בעצמכם, timeout כזה מצביע על חסימה של ספק התשתית. זהו מסנן רשת בצד הספק, ולא firewall מקומי, ולכן שום שינוי מקומי לא יפתור את הבעיה. פתחו פנייה בנוסח: "Please enable outbound TCP port 25 for my VPS at <IP>; I am running a legitimate mail server." אל תתקינו mailcow לפני שהפקודה מחזירה "succeeded". שימו לב שפורט 25 נכנס, כלומר שרתים אחרים שמתחברים אליכם, הוא נתיב נפרד ובדרך כלל פתוח. הספקים מגבילים בדרך כלל את הצד היוצא.

שלב 2, הגדרת רשומות ה-DNS כעת

שינויי DNS דורשים זמן הפצה, לכן יש לפרסם את כל הרשומות האפשריות לפני ההתקנה. נניח ששם המתחם שלכם הוא example.com, מארח הדואר הוא mail.example.com, וכתובת ה-IP היא 10.0.0.10. באזור ה-DNS שלכם, צרו את הרשומות הבאות:

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 כדי שתוכלו לעקוב אחר דוחות מבלי לחסום את הדואר שלכם; החמירו את המדיניות ל-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 בגרסה 24.0 ומעלה ואת Docker Compose בגרסה 2.0 ומעלה. תוסף Compose‏ (docker compose) הוא הדרך הפשוטה ביותר, אך mailcow תומך גם בקובץ הבינארי העצמאי docker-compose. השתמשו בסקריפט הנוחות הרשמי של Docker במקום בחבילת docker.io של Ubuntu, שאינה כוללת תוסף Compose כלל:

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

אתם אמורים לראות שורה של Docker Compose version שמדווחת על v2.x או v5.x. Compose v5, שפורסם בשנת 2025, זהה מבחינה תפקודית ל־v2, ושתי הגרסאות עומדות בדרישות של mailcow. אם 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 עצמו, שמגדירים את umask 0022 לפני השכפול. mailcow אינו בודק את הערך הזה, ובמעטפת root חדשה של Ubuntu 24.04 כבר מתקבל 0022. לאחר מכן הסקריפט מבקש את הפרט החשוב היחיד: שם המארח המלא. הזינו mail.example.com; הערך חייב להתאים בדיוק לרשומת ה־A ולרשומת ה־PTR. הסקריפט כותב את mailcow.conf, קובץ הסביבה היחיד שכל רכיבי המחסנית קוראים. פתחו אותו אם עליכם לשנות את פורטי ה־web (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 הוא אמצעי נוסף לצמצום שימוש בזיכרון בשרת עם מעט RAM: חיפוש בטקסט מלא הוא צרכן הזיכרון השני ש־mailcow מציין בתיעוד שלו, והשבתתו מונעת רק חיפוש בגוף ההודעות ב־webmail.

השאירו את HTTP_PORT=80 ואת HTTPS_PORT=443 ללא שינוי, אלא אם שירות אחר בשרת כבר משתמש בהם. לקוח ה־ACME המובנה של mailcow משתמש כברירת מחדל באתגר HTTP-01, הדורש שפורט 80 יהיה נגיש מהאינטרנט כדי לקבל את התעודה. (ב־mailcow 2026-03 ואילך אפשר להשתמש במקום זאת באתגר DNS-01 באמצעות ACME_DNS_CHALLENGE=y. אפשרות זו אינה דורשת את פורט 80, אך כן דורשת גישה ל־API של ספק ה־DNS שלכם.) זו הסיבה שבפריסה הפשוטה אין להפעיל הגדרה נפרדת של nginx ו־Certbot על אותו שרת; mailcow מנפיק ומחדש את תעודות ה־TLS שלו באופן פנימי, ושירות נוסף שתופס את 80/443 יגרום לכך להיכשל. mailcow מתעד גם את החלופה: לקשור את מאזיני ה־web שלו באופן מקומי באמצעות HTTP_BIND=127.0.0.1 HTTP_PORT=8080 HTTPS_BIND=127.0.0.1 HTTPS_PORT=8443, להציב reverse proxy על 80 ו־443, ואם ברצונכם ש־Certbot מקומי ינהל את התעודות, להפנות את mailcow אליהן ולהוסיף hook לחידוש. בשרת דואר יש לכך יותר רכיבים לניהול, ולכן אותו שיקול חל גם על כל שירות אחר שזקוק לממשק web ציבורי: פריסה כמו Halcyon שמציג מחדש ספריית Jellyfin כחנות סרטי וידאו משנות ה־90, המצפה ל־reverse proxy משלה על 443, שייכת לשרת אחר, אלא אם תעבירו את mailcow אל מאחורי אותו proxy. החריג הוא שירות שאינו מבקש פורט web ציבורי כלל: ממסר RustDesk באירוח עצמי מאזין רק לטווח 21115 עד 21119 שלו, ולכן יכול לפעול באותו שרת, בתנאי שנשארת לכם קיבולת מספקת ברשת.

שלב 5, הפעלת ה־stack והתחברות

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

הפקודה pull מורידה בערך שני תריסרי images; המתינו כמה דקות. כאשר docker compose ps מציג שכל ה־containers נמצאים במצב running (או healthy), פתחו בדפדפן את https://mail.example.com/admin. פרטי הכניסה של מנהל המערכת כברירת מחדל הם שם המשתמש admin והסיסמה moohoo. שנו את הסיסמה מיד בממשק הניהול, תחת System → Configuration ולאחר מכן Access → Administrators. אם הדפדפן מציג אזהרה לגבי NET::ERR_CERT_AUTHORITY_INVALID, אישור ה־ACME עדיין לא הונפק. עיינו בהמשך בסעיף על כשל ACME לפני שאתם מניחים שיש תקלה; אישור בחתימה עצמית הוא מצב תקין בדקה או בשתי הדקות הראשונות.

הוספת מתחם, תיבת דואר ופרסום DKIM

בממשק הניהול, פתחו את E-Mail → Configuration. בכרטיסייה Domains לחצו על Add domain והזינו את example.com. לאחר מכן, תחת Mailboxes, לחצו על Add mailbox כדי ליצור את you@example.com עם סיסמה. זו כבר תיבת דואר פעילה שניתן לגשת אליה באמצעות IMAP.

כעת נגדיר את מפתח DKIM. עברו אל System → Configuration ולאחר מכן אל Options → ARC/DKIM keys. ייתכן ש־mailcow כבר יצר מפתח בעת הוספת המתחם. אם לא, צרו שם מפתח, בחרו את המתחם, השאירו את הבורר 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 not aligned: רשומת ה-MX/SPF שלכם חסרה או שכתובת ה-IP השולחת אינה כלולה בה. בדקו שוב את רשומת ה-TXT של ה-SPF.
• DKIM signature does not verify: רשומת ה-TXT של ה-dkim._domainkey חסרה, עדיין בתהליך הפצה (propagation), או שהיא משובשת. זוהי השגיאה הנפוצה ביותר.
• No PTR / PTR mismatch: ה-reverse DNS אינו מתרגם ל-mail.example.com. תקנו זאת דרך ספק התשתית.
• Listed on a blocklist: מוניטין קודם של כתובת ה-IP שלכם. בקשו הסרה מהרשימה השחורה או בקשו כתובת IP נקייה יותר.

אל תשלחו דואר אמיתי ל-Gmail או ל-Outlook עד שתקבלו ציון 10/10. ציון נמוך בשילוב כתובת IP חדשה הם הדרך המהירה ביותר לגרום לכך שהדומיין שלכם יסומן כספאם כבר ביום הראשון.

שלב 8, חיבור לקוח דואר אלקטרוני אמיתי

הגדירו את Thunderbird, Apple Mail או את הטלפון שלכם מול השרת באמצעות ההגדרות הבאות. מארח השרת (server host) עבור כולם הוא mail.example.com:

• IMAP: פורט 993, SSL/TLS (או 143 עם STARTTLS)
• SMTP submission: פורט 465, SSL/TLS (או 587 עם STARTTLS)
• שם משתמש: כתובת הדואר המלאה, you@example.com
• סיסמה: סיסמת תיבת הדואר שהגדרתם

לעולם אל תשלחו דואר מלקוח דרך פורט 25. פורט זה מיועד לתקשורת שרת-לשרת בלבד; mailcow אינה מציעה בו שליחה מאומתת (authenticated submission), ולקוח שינסה להתחבר אליו יידחה. אם לקוח מדווח על Relay access denied, סימן שהוא מנסה לשלוח דואר דרך פורט 25 או ללא אימות; העבירו אותו לפורט 465 או 587 עם פרטי הגישה של תיבת הדואר שלכם.

שלב 9, גיבוי של מה שבאמת חשוב

mailcow כוללת סקריפט גיבוי שמבצע snapshot לכל ה-volumes בעלי מצב (stateful). הריצו אותו אל כונן חיצוני או אל יעד מרוחק שמופה למערכת:

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

all מתעד שישה רכיבים, ואובדן של כל אחד מהם משמעו אובדן נתונים: vmail (תיבות הדואר עצמן), crypt (המפתחות לפענוח ה-vmail, חסרי תועלת בלעדיו), mysql (מסד הנתונים MariaDB המכיל דומיינים, משתמשים, כינויים והגדרות), redis (מצב התור והמטמון), rspamd (נתוני למידה של דואר זבל/תקין), ו-postfix (תור הדואר). הסקריפט רץ בתוך מכולת עזר הכותבת ארכיונים דחוסים, כך שהגיבויים נשארים עקביים גם כשהמערכת פעילה. בצעו אוטומציה באמצעות cron job לילי, והוסיפו את --delete-days 14 כדי לנקות סטים ישנים. cron job שמפסיק לעבוד עלול להיכשל בשקט, לכן שלחו את סטטוס היציאה של הסקריפט למקום שבו תבחינו בו; שרת ntfy בניהול עצמי מקבל פקודת curl בשורה אחת מאותה כניסת cron ושולח התראה על הכישלון לטלפון שלכם באותו הלילה. שחזור מתבצע באמצעות אותו סקריפט עם restore, המציג את ה-snapshots ומאפשר לכם לבחור מה לשחזר. גיבוי שמעולם לא בדקתם את השחזור שלו הוא בגדר תקווה בלבד, לא גיבוי; בצעו הרצה ניסיונית (dry run) על שרת VPS זמני.

שלב 10, עדכון לפי לוח זמנים

mailcow מתעדכנת באמצעות סקריפט פנימי, אשר מושך קוד חדש, מבצע מיגרציות ל-mailcow.conf, טוען מראש (prefetch) אימג'ים, ומפעיל מחדש את המכולות לפי הסדר:

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

בצעו גיבוי תחילה (שלב 9), כיוון שמיגרציית סכימה היא פעולה שקשה לבטל. עדכונים משוחררים בתדירות גבוהה וכוללים תיקוני אבטחה עבור שירותים החשופים לאינטרנט, לכן אל תזניחו שרת דואר למשך חודשים. אם עדכון כלשהו מותיר מכולה במצב לא תקין, הפקודה sudo docker compose logs --tail=50 <service>-mailcow תציג את שם השירות שנכשל בעלייה.

הערה על הקשחת אבטחה

mailcow מריצה שירות netfilter משלה (netfilter-mailcow) החוסם כתובות IP המבצעות ניסיונות התחברות אגרסיביים לפורטים של הדואר ושל ה-webmail, כך שצד הדואר מוגן כברירת מחדל. הגנה זו אינה מכסה את SSH במארח עצמו, שנותר חשוף ונתון לניסיונות brute-force; מומלץ לשלב התקנה זו עם ניטור לוג האימות של SSH באמצעות Fail2ban ושימוש בהתחברות מבוססת מפתח בלבד. יש להגן על ממשק הניהול של mailcow באמצעות סיסמה חזקה, ורצוי להגביל את הגישה אליו כך שלא יהיה חשוף לאינטרנט הציבורי או להשתמש ב-VPN.

מצבי כשל, כולל המחרוזות המדויקות

תורי דואר ואי-מסירה. הריצו sudo docker compose exec postfix-mailcow postqueue -p, או קראו את תור הדואר בממשק הניהול; הרשומות נשארות במצב deferred עד חמישה ימים, לפני ש־Postfix מחזיר אותן לשולח, עם:

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

כמעט תמיד מדובר בחסימה של פורט 25 היוצא מצד ספק התשתית שלכם (שלב 1). כלל יוצא ב־firewall של השרת עצמו יוצר אותה פקיעת זמן, לכן שללו זאת תחילה; אם השרת תקין, אין תיקון תצורה שיפתור את הבעיה, ויש לפתוח פנייה. הבעיה אינה DNS ואינה TLS; הסימן המובהק הוא המילה timed out מול MX מרוחק בפורט 25.

Gmail מסמן הכול כספאם או מחזיר את ההודעות. פתחו את ההודעה ב־Gmail, בחרו "Show original", וקראו את תוצאות האימות. dkim=fail או dkim=none פירושם שרשומת dkim._domainkey TXT חסרה, פגומה או שטרם הופצה; פרסמו מחדש בדיוק את מה שמוצג בדף ARC/DKIM והמתינו ל־TTL. spf=fail פירושו שרשומות SPF/MX אינן כוללות את כתובת ה־IP שלכם. התאמה היא קריטית; בדיקה כושלת אחת מספיקה כדי שההודעה תגיע לספאם.

ספקים גדולים דוחים את החיבור. בהודעות ההחזרה או בלוגים של Postfix מופיעה דחיית PTR מצד Gmail:

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 פירושו ש־DNS הפוך חסר או אינו תואם. הגדירו אצל ספק התשתית (שלב 2) את רשומת ה־PTR של כתובת ה־IP שלכם לערך mail.example.com. רשומות קדימה (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. או כשל באתגר פירושם שפורט 80 אינו נגיש מהאינטרנט, או שרשומת A אינה מפנה לשרת הזה. אם פרסמתם רשומת AAAA, בדקו גם אותה: mailcow מאמת תחילה מול רשומת AAAA ומדלג על בדיקת A כאשר היא קיימת. לכן רשומת AAAA שגויה, או נתיב IPv6 שאינו מצליח להגיע לפורט 80, יגרמו לכשל באימות גם כאשר רשומת A תקינה. ודאו ש־mail.example.com נפתר לשרת, פתחו את פורטים 80 ו־443 דרך כל firewall של השרת, וודאו ששום תהליך אחר אינו מאזין בפורטים האלה. לאחר תיקון הגורם, הפעילו מחדש את הלקוח באמצעות 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 לאחר ההמתנה פירושה שהפורט חסום. אם אין בשרת כללי firewall יוצאים שהגדרתם בעצמכם, הספק הוא שחוסם אותו. זו הסיבה הנפוצה ביותר לכך ששרת באירוח עצמי יכול לקבל דואר אך אינו מצליח לשלוח אותו. הפתרון היחיד לחסימה מצד הספק הוא שהספק יפתח את הפורט. שום שינוי בהגדרות המקומיות לא יפתור זאת.

מדוע הדואר שלי עדיין מגיע לתיקיית הספאם של Gmail?

כמעט תמיד מדובר בשרשרת אימות פגומה. השתמשו באפשרות "Show original" ב־Gmail וחפשו את spf=pass, dkim=pass ו־dmarc=pass. ערך dkim=fail מצביע על רשומת dkim._domainkey מסוג TXT שחסרה או שגויה. גם אי־התאמה ברשומת PTR או כתובת IP חדשה ללא היסטוריית שליחה פוגעות ביכולת המסירה. תחילה הביאו את mail-tester.com לתוצאה 10/10. לאחר מכן חממו את כתובת ה־IP בהדרגה: התחילו בכמה הודעות ביום והגדילו את הכמות, במקום לשלוח נפח גדול כבר ביום הראשון.

מה בדיוק עליי לגבות?

הריצו backup_and_restore.sh backup all ושמרו את כל קבוצת הגיבויים מחוץ לשרת. היא כוללת את vmail, כלומר את תיבות הדואר; את crypt, כלומר את המפתחות שמפענחים אותן; את מסד הנתונים MariaDB, הכולל דומיינים, משתמשים, כינויים והגדרות; את Redis; את הנתונים שנלמדו על ידי Rspamd; ואת התור של Postfix. אמצעי האחסון crypt הוא הרכיב שאנשים נוטים לשכוח. בלעדיו, הגיבוי של vmail הוא טקסט מוצפן שאי אפשר לקרוא. בדקו שחזור על שרת בדיקה לפחות פעם אחת.

האם אפשר להפעיל mailcow על VPS בנפח 2 GB?

לא באופן יציב ונוח. generate_config.sh מציע להשבית את ClamAV כאשר הנפח נמוך מכ־2.5 GiB. גם כאשר ClamAV מושבת, Rspamd, Dovecot, MariaDB ושאר רכיבי המחסנית מתחרים על הזיכרון. לכן תגיעו לשימוש ב־swap ולהרגי OOM תחת כל עומס ממשי. ראו ב־6 GiB בתוספת 1 GiB של swap את רף הבסיס להתקנה יציבה עבור משתמש יחיד. עברו ל־8 GiB ברגע שיותר משני אנשים מסתמכים על המערכת.