راه اندازی میل سرور Stalwart روی VPS
بررسی جایگزینی Postfix و Dovecot با Stalwart در یک باینری Rust. این راهنما به شما میگوید چه زمانی باید از این ابزار استفاده کنید و چه محدودیتهایی در نسخه v0.16.19 وجود دارد.
آنچه Stalwart در یک باینری واحد ادغام میکند
Stalwart یک میلسرور است که آن را روی یک VPS به صورت یک باینری Rust واحد اجرا میکنید. این برنامه به درخواستهای SMTP، IMAP، POP3، JMAP، CalDAV، CardDAV و WebDAV از طریق همان پردازش پاسخ میدهد و دارای فیلتر اسپم، ذخیرهساز پیام و کلاینت ACME اختصاصی خود است. یک پشته (stack) مرسوم، همین کار را با استفاده از Postfix، Dovecot، Rspamd، یک دیتابیس برای حسابها و یک ابزار مجزا برای گواهیها انجام میدهد. Stalwart تمام این موارد را با یک واحد سرویس (service unit) و یک فایل پیکربندی در /etc/stalwart/config.json جایگزین میکند.
تمام ارقام، نام تنظیمات و دستورات زیر از مستندات رسمی، صفحات انتشار و اسکریپت نصب Stalwart استخراج شدهاند که در تاریخ 28 August 2026 و بر اساس نسخه v0.16.19 (منتشرشده در 24 August 2026) بازبینی شدهاند. اینها دستوراتی هستند که باید روی سرور خود اجرا کنید. پس از هر دستور، بررسی مربوطه برای اطمینان از صحت عملکرد آن ذکر شده است.
نرمافزار Stalwart دارای دو مجوز GNU Affero General Public License v3.0 (AGPL-3.0) و Stalwart Enterprise License v2 است. برخی از قابلیتها فقط در نسخه سازمانی (Enterprise) موجود هستند. لیست اندپوینتهای HTTP مستندشده، این موارد را با /scim/v2/* مشخص کرده است. پیش از برنامهریزی برای پیادهسازی بر اساس قابلیتی که شخصاً آن را تست نکردهاید، شرایط مجوز را مطالعه کنید.
یک باینری واحد، کاهش واقعی در قطعات متحرک سیستم است. اما این به معنای کاهش در دو عاملی که تعیینکننده رسیدن یا نرسیدن ایمیلهای شما هستند، نیست.
پورت 25 و اعتبار DNS به نرمافزاری که اجرا میکنید اهمیتی نمیدهند
پورت خروجی TCP 25 اولین دروازه است. بسیاری از ارائهدهندگان VPS این پورت را بهصورت پیشفرض روی حسابهای کاربری جدید مسدود میکنند و مسدود بودن پورت 25 به این معناست که سرور شما فقط میتواند با خودش صحبت کند و نه هیچکس دیگر. پیش از نصب هر چیزی، آن را تست کنید.
sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 alt1.aspmx.l.google.com 25یک نتیجه سالم، Connection to alt1.aspmx.l.google.com ... 25 port [tcp/smtp] succeeded! را در حدود یک ثانیه چاپ میکند. یک پورت مسدود شده برای پنج ثانیه کامل معلق میماند و سپس nc: connect to alt1.aspmx.l.google.com port 25 (tcp) failed: Connection timed out را چاپ میکند، زیرا بستهها در بالادست (upstream) حذف میشوند و هیچ پاسخی مبنی بر reset به شما بازگردانده نمیشود. اگر این وضعیت را مشاهده کردید، یک تیکت برای ارائهدهنده خود باز کنید. هیچ سرور ایمیلی نمیتواند بستههای حذفشده را دور بزند.
دروازه دوم، دیدگاه شبکههای دریافتکننده نسبت به آدرس IP و دامنه شماست. این شامل reverse DNS روی IP، تنظیمات SPF، DKIM، DMARC و تاریخچه ارسال آدرس بلاکی است که در آن قرار گرفتهاید. صفحه تنظیمات DNS در Stalwart بهصراحت بیان میکند که این کارها کجا انجام میشوند: رکوردهای reverse DNS «معمولاً توسط ارائهدهنده میزبانی پیکربندی میشوند، نه توسط خود Stalwart». همین موضوع در مورد سایر موارد این دسته نیز صادق است. این تنظیمات در زون DNS شما و پنل کنترل ارائهدهندهتان قرار دارند، نه در سرور ایمیل.
بنابراین، این صفحه دوباره آن رکوردها را آموزش نمیدهد. ما صفحهای داریم که این کار را انجام میدهد: راهاندازی SPF، DKIM و DMARC برای هر چیزی که ایمیل ارسال میکند. اگر هنوز تصمیم نگرفتهاید که آیا اصلاً میخواهید سرور ایمیل خودتان را اجرا کنید یا خیر، با بررسی صادقانه ما درباره اینکه آیا میزبانی شخصی ایمیل هنوز ارزشش را دارد یا نه شروع کنید. انتخاب Stalwart هیچ تغییری در این محاسبات ایجاد نمیکند.
نیازمندیهای یک VPS کوچک برای اجرای سرور ایمیل Stalwart
صفحه نیازمندیهای سیستم Stalwart که در تاریخ 28 August 2026 مطالعه شد، این اعداد را ارائه میدهد. میزان مصرف حافظه در حالت بیکار حدود 100 MB است. یک استقرار کوچک برای 5 تا 10 کاربر با 1 GB رم به خوبی کار میکند. یک پیکربندی کمترافیک با حدود 5 کاربر روی یک هسته CPU اجرا میشود و این صفحه اضافه میکند که «با افزایش همزمانی و فعالیت، برای حفظ تأخیر کم و توان عملیاتی بالا، به هستههای CPU بیشتری نیاز خواهد بود». سقف پیشفرض برای اتصالات همزمان در تمامی سرویسها 8,192 است که قابل پیکربندی میباشد.
آن صفحه حداقل اندازه دیسک را مشخص نمیکند، بنابراین اندازه دیسک را بر اساس حجم ایمیلی که انتظار دارید نگهداری کنید، به اضافه فضای اضافی برای فشردهسازی مخزن داده، تعیین کنید.
سه مسیر خروجی باید فعال باشند، در غیر این صورت سرور به شکلی دچار اختلال به نظر میرسد که هیچ ارتباطی به ایمیل ندارد. سرور بسته رابط وب را از https://github.com/stalwartlabs/webui/releases/latest/ دریافت میکند. برای دریافت گواهیها به https://acme-v02.api.letsencrypt.org/directory متصل میشود. همچنین برای جستجوی رکوردهای MX و احراز هویت، به DNS روی پورتهای 53 پروتکلهای UDP و TCP نیاز دارد. یک فایروال خروجی محدودکننده که مسیر اول را مسدود کند، باعث میشود سرور ایمیل اجرا شود اما رابط مدیریتی در دسترس نباشد.
نصب یک نسخه مشخص (Pinned) به جای نسخه "latest"
نصبکننده رسمی یک اسکریپت shell است. پیش از اجرای آن، محتوای آن را مطالعه کنید.
curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
less install.sh
sudo sh install.shمطالعه آن اسکریپت در تاریخ 28 August 2026 نشان میدهد که دقیقاً چه کاری انجام میدهد. این اسکریپت یک حساب کاربری سرویس به نام stalwart و دایرکتوریهای مورد نیاز آن را ایجاد میکند. سپس فایلها را از https://github.com/stalwartlabs/stalwart/releases/latest/download دانلود میکند. فایل باینری در مسیر /usr/local/bin/stalwart با مجوز 0755 قرار میگیرد. فایلهای پیکربندی به /etc/stalwart/config.json، دادهها به /var/lib/stalwart و لاگها به /var/log/stalwart منتقل میشوند؛ هر سه دایرکتوری با مجوز 0750 و مالکیت stalwart تنظیم میشوند. یک فایل محیطی (environment file) در /etc/stalwart/stalwart.env با مجوز 0640 و مالکیت root:stalwart نوشته میشود. این اسکریپت یک پیشوند نصب اختیاری و یک فلگ --fdb برای ساخت FoundationDB میپذیرد، اما هیچ آرگومان نسخهای دریافت نمیکند.
نکته آخر اهمیت زیادی دارد. این اسکریپت همیشه جدیدترین نسخه (latest) را دریافت میکند، بنابراین دو سروری که با فاصله یک هفته از هم ساخته شدهاند، نسخه یکسانی از کد را اجرا نمیکنند. بلافاصله پس از نصب، فایل باینری را خودتان به نسخه خاصی محدود (Pin) کنید؛ این همان مسیر ارتقایی است که در یادداشتهای انتشار v0.16.19 ذکر شده است: "اگر در حال ارتقا از v0.16.x هستید، فایل باینری را جایگزین کنید (یا docker pull را اجرا کنید)."
STALWART_TAG=v0.16.19
curl -fsSLO "https://github.com/stalwartlabs/stalwart/releases/download/${STALWART_TAG}/stalwart-x86_64-unknown-linux-gnu.tar.gz"
tar zxf stalwart-x86_64-unknown-linux-gnu.tar.gz
sudo systemctl stop stalwart
sudo install -m 0755 -o root -g root stalwart /usr/local/bin/stalwart
sudo systemctl start stalwart
systemctl is-active stalwartsystemctl is-active stalwart باید خروجی active را چاپ کند. در صورت مشاهده هر خروجی دیگری، journalctl -u stalwart -n 50 را مطالعه کنید. هر بسته انتشار همراه با یک باندل .sigstore.json ارائه میشود، بنابراین امضای فایل دانلودی پیش از نصب قابل تایید است.
واحد (unit) سرویسی که اسکریپت ایجاد میکند، با کاربر User=stalwart اجرا شده و قابلیت AmbientCapabilities=CAP_NET_BIND_SERVICE را تنظیم میکند. این قابلیت دلیل آن است که یک حساب کاربری بدون امتیاز (unprivileged) میتواند پورتهای 25، 443، 465 و 993 را bind کند. اگر بعداً واحد سرویس خودتان را بنویسید و آن خط را حذف کنید، سرویس هنگام شروع با خطا مواجه میشود، زیرا یک کاربر معمولی نمیتواند پورتهای زیر 1024 را bind کند.
محل نمایش رمز عبور اولیه مدیر
Stalwart در حالت bootstrap شروع به کار میکند و یک رمز عبور 16 کاراکتری موقت را تنها یکبار در لاگ سرویس مینویسد.
sudo journalctl -u stalwart -n 200 | grep -A8 'bootstrap mode'ویزارد راهاندازی روی پروتکل HTTP ساده و پورت 8080 گوش میدهد، بنابراین این پورت را در معرض اینترنت قرار ندهید. در عوض، آن را از طریق SSH از لپتاپ خود تونل کنید:
ssh -N -L 8080:127.0.0.1:8080 you@your-vpsسپس http://127.0.0.1:8080/admin را باز کرده و با نام کاربری admin و رمز عبوری که در لاگ مشاهده کردید، وارد شوید. ویزارد از شما نام میزبان سرور، دامنه پیشفرض ایمیل، تنظیمات TLS، فضای ذخیرهسازی، دایرکتوری حسابها، لاگگیری و مدیریت DNS را میپرسد. پس از پایان کار، سرویس را ریاستارت کنید و از آن پس از https://<your-host>/admin استفاده نمایید.
اگر رمز عبور از لاگ پاک شده است، یک رمز ثابت تنظیم کنید. فایل /etc/stalwart/stalwart.env شامل ورودیهای کامنتشدهای دقیقاً برای همین منظور است، از جمله STALWART_RECOVERY_ADMIN=admin:changeme، STALWART_RECOVERY_MODE=true و STALWART_RECOVERY_MODE_PORT (که پیشفرض آن 8080 است). آنها را از حالت کامنت خارج کرده، سرویس را ریاستارت کنید، وارد شوید و سپس دوباره آنها را کامنت کنید. صفحه hardening در مستندات Stalwart توصیه میکند که این اعتبارنامه را فقط برای موارد اضطراری نگه دارید و هرگز با حساب کاربری مدیر به IMAP، JMAP یا WebDAV وارد نشوید.
همان صفحه لیست شنوندههایی (listeners) که باید فعال بمانند را مشخص کرده است: پورت 25 برای SMTP ورودی، پورت 465 برای submission با TLS ضمنی، پورت 993 برای IMAPS و پورت 443 برای تمامی ترافیکهای HTTP. این مستندات پورتهای 587، 143، 4190، 110، 995 و 8080 را غیرضروری میداند و توصیه میکند پس از اتمام راهاندازی، پورت 8080 را غیرفعال کنید.
اجرای آن در Docker با استفاده از تگ ثابت (Pinned tag)
ایمیج مستندشده stalwartlabs/stalwart است. تگ v0.16.19 در تاریخ 28 August 2026 در Docker Hub در کنار نسخه -alpine موجود بود. به همان دلیلی که برای فایل باینری در بالا ذکر شد، نسخه patch را ثابت (pin) کنید و از تگ شناور v0.16 استفاده نکنید.
services:
stalwart:
image: stalwartlabs/stalwart:v0.16.19
container_name: stalwart
restart: unless-stopped
ports:
- "25:25"
- "465:465"
- "993:993"
- "443:443"
- "127.0.0.1:8080:8080"
volumes:
- stalwart-etc:/etc/stalwart
- stalwart-data:/var/lib/stalwart
volumes:
stalwart-etc:
stalwart-data:آن فایل، دستور مستندشده docker run است که به صورت Compose نوشته شده و listenerهای غیرضروری از آن حذف شده و پورت راهاندازی به localhost محدود شده است. آن را بالا بیاورید و همان خط bootstrap را بخوانید:
docker compose up -d
docker compose logs stalwart 2>&1 | grep -A8 'bootstrap mode'صفحه Docker همچنین -e STALWART_RECOVERY_ADMIN=admin:mySecretPass را به عنوان روشی برای تنظیم اعتبارنامه ثابت در زمان شروع کار معرفی میکند، که اگر ترجیح میدهید به جای خواندن لاگها از آن استفاده کنید، معادل کلید environment: در Compose است.
لیست کامل پورتهای مستندشده و دلیل کوتاهتر بودن این فایل
صفحه Docker مربوط به Stalwart پورتهای 443، 8080، 25، 587، 465، 143، 993، 110، 995 و 4190 را منتشر میکند. صفحه hardening آن، پورتهای 587، 143، 110، 995 و 4190 را غیرضروری میداند و توصیه میکند پس از راهاندازی، پورت 8080 غیرفعال شود. فقط مواردی را که کلاینتهای شما واقعاً به آن نیاز دارند، اضافه کنید. اگر گوشی موبایلی اصرار بر استفاده از STARTTLS submission دارد، پورت 587 را منتشر کنید. اگر کاربران شما قوانین Sieve را از طریق کلاینت دسکتاپ مینویسند، پورت 4190 را منتشر کنید.
اگر با Compose آشنا نیستید، راهنمای Docker Compose ما برای VPS ساختار فایل و مدل named-volume مورد استفاده در اینجا را پوشش میدهد. یک هشدار که بهویژه برای سرورهای ایمیل مشکلساز است: Docker پورتها را با نوشتن قوانین فایروال اختصاصی خود منتشر میکند و این قوانین پیش از قوانین ufw بررسی میشوند؛ بنابراین ufw deny 8080 پورتی را که توسط Compose منتشر شده است، نمیبندد. محدود کردن به 127.0.0.1 در نگاشت پورت (port mapping) همان چیزی است که در واقع پورت را میبندد؛ به همین دلیل است که فایل بالا این کار را انجام میدهد و SSH tunnel همچنان اعمال میشود.
استفاده از TLS بدون Certbot و هزینههای آن
نرمافزار Stalwart پروتکل ACME (محیط مدیریت خودکار گواهی) را بهصورت داخلی پیادهسازی کرده است، بنابراین نیازی به Certbot یا hook برای تمدید گواهی وجود ندارد. مستندات این نرمافزار چهار روش اعتبارسنجی را فهرست کردهاند. روش HTTP-01 به درخواستهای چالش (challenge) روی پورت 80 پاسخ میدهد. روش TLS-ALPN-01 یک گواهی اختصاصی را روی پورت 443 و با استفاده از پروتکل ALPN مخصوص ACME ارائه میکند. روش DNS-01 رکوردهای TXT موقت منتشر میکند و یکی از دو روشی است که امکان صدور گواهی wildcard را دارد. روش DNS-PERSIST-01 بهجای نوشتن رکورد جدید در هر بار تمدید، از رکوردهای TXT با مجوز طولانیمدت استفاده میکند.
هزینهٔ این قابلیت آن است که Stalwart میخواهد کنترل پورت را در اختیار داشته باشد. روش TLS-ALPN-01 با تکمیل فرآیند TLS handshake توسط خودِ نرمافزار کار میکند، بنابراین اگر پشت یک reverse proxy باشید که TLS termination را برای شما انجام میدهد، این روش موفق نخواهد بود. اگر Nginx یا Caddy در حال حاضر پورت 443 را روی آن سرور اشغال کردهاند، یا Stalwart را به روش DNS-01 منتقل کنید و یا یک آدرس IP اختصاصی به آن اختصاص دهید.
DANE و MTA-STS، و تنظیمات پیشفرضی که باید بدانید
هر دو مورد بر اساس استراتژی TLS در شیء MtaTlsStrategy، در بخش Settings، MTA، Outbound، و TLS Strategies در رابط کاربری وب پیکربندی میشوند. فیلد dane بهطور پیشفرض روی optional تنظیم شده است که در صورت انتشار رکوردهای TLSA توسط گیرنده، اعتبارسنجی DANE را انجام میدهد و در غیر این صورت به STARTTLS معمولی بازمیگردد. اگر آن را روی require تنظیم کنید، ارسال پیام تنها در صورتی انجام میشود که رکورد TLSA قابلتأیید باشد. فیلد mtaSts نیز به همین ترتیب عمل میکند و مقدار پیشفرض آن optional است. تایماوتهای مرتبط عبارتند از tlsTimeout (پیشفرض 3 دقیقه) و mtaStsTimeout (پیشفرض 5 دقیقه).
در سمت ورودی، Stalwart میتواند خطمشی MTA-STS شما را در https://mta-sts.<domain>/.well-known/mta-sts.txt منتشر کند که نیازمند باز بودن پورت 443 است. سینگلتون MtaSts شامل mode (پیشفرض testing)، maxAge (پیشفرض 7 روز) و mxHosts است که در صورت خالی بودن، به نامهای میزبان موجود در گواهی TLS شما بازمیگردد. شما باید دو رکورد DNS ارائه دهید: یک رکورد CNAME برای mta-sts که به میزبان ایمیل اشاره میکند، و یک رکورد TXT برای _mta-sts که شناسه خطمشی را حمل میکند.
dig +short TXT _mta-sts.example.org
curl -s https://mta-sts.example.org/.well-known/mta-sts.txtجستجوی TXT باید یک رشته v=STSv1; id=... برگرداند و دستور curl باید بدنه خطمشی را نمایش دهد. اگر curl هیچ خروجیای برنگرداند، پورت 443 بسته است یا گواهی برای mta-sts.example.org هرگز صادر نشده است.
تا زمانی که هر دو بررسی با موفقیت انجام نشوند، mode را روی testing باقی بگذارید. یک خطمشی در حالت enforce با گواهی معیوب، مانع از تحویل ایمیل توسط سایر سرورها به شما میشود و در این صورت، بهجای لاگها، از طریق کاربران خود متوجه مشکل خواهید شد. DANE نیز یک دام مشابه دارد: این قابلیت نیازمند یک زون با امضای DNSSEC است و رکورد TLSA که گواهی leaf را پین میکند، باید هر بار که ACME گواهی را تمدید میکند، مجدداً منتشر شود. به جای آن، CA صادرکننده را پین کنید یا زحمت تمدید دستی را بپذیرید.
رمزنگاری در حالت سکون (Encryption at rest) با رمزنگاری سرتاسری (End-to-end) متفاوت است
این قابلیتی است که بیش از همه دچار سوءبرداشت میشود، بنابراین دقیقاً همان چیزی را که مستندات بیان کردهاند، اینجا میآوریم. پیامهای متنی هر کاربر، پیش از آنکه روی دیسک نوشته شوند، بهطور خودکار با استفاده از گواهی OpenPGP یا S/MIME آنها رمزنگاری میشوند. encryptAtRest بهصورت پیشفرض فعال است و برای پیامهایی که از طریق SMTP یا LMTP میرسند اعمال میشود، مشروط بر اینکه گیرنده یک کلید رمزنگاری ثبت کرده باشد. encryptOnAppend بهصورت پیشفرض روی false تنظیم شده است، «که باعث میشود پیامهای الحاقشده (appended) دستنخورده باقی بمانند تا کلاینتها کنترل کامل بر محتوایی که ذخیره میکنند داشته باشند». OpenPGP بهجای روش قدیمی PGP/Inline از PGP/MIME با استاندارد AES-256 یا AES-128 استفاده میکند. Stalwart کلیدها را تولید نمیکند: کاربران یک کلید عمومی ASCII-armored را صادر کرده و آن را بهعنوان یک شیء PublicKey در بخش Account, Public Keys ثبت میکنند.
بنابراین، این قابلیت از یک ایمیج دیسک سرقتشده، یک نسخه پشتیبان سرقتشده و خواندن فضای ذخیرهسازی توسط اپراتور پس از تحویل پیام محافظت میکند. بدون کلید خصوصی، بایتهای ذخیرهشده غیرقابلخواندن هستند و مدیر سیستم نیز نمیتواند آنها را رمزگشایی کند.
این قابلیت از پیام در حین انتقال محافظت نمیکند. پیام با هر پروتکل TLS که دو سرور بر سر آن توافق کرده باشند از اینترنت عبور میکند، بهصورت متن ساده (plain text) میرسد و Stalwart در همان لحظه آن را رمزنگاری میکند. فرستنده، ارائهدهنده خدمات فرستنده و هر واسطهای که TLS را حذف کرده باشد، قبلاً متن ساده را مشاهده کردهاند.
ذکر سه محدودیت دیگر بهصورت شفاف ضروری است. پوشههای Sent و Drafts توسط کلاینت شما نوشته میشوند که یک عملیات الحاق (append) است و چون encryptOnAppend بهصورت پیشفرض false است، این پیامها بهصورت متن ساده باقی میمانند مگر اینکه تنظیمات را تغییر دهید. مستنداتی که در تاریخ 28 August 2026 مطالعه کردم، تنها به محتوای پیام اشاره دارد و نمیگوید که دادههای پاکت (envelope)، هدرها یا ورودیهای ایندکس رمزنگاری میشوند، بنابراین فرض نکنید که چنین است. همچنین ذکر نشده است که پیامهایی که پیش از آپلود کلید ذخیره شدهاند دوباره رمزنگاری میشوند، بنابراین فرض کنید که نمیشوند و این موضوع را بررسی کنید. اینکه آیا جستجوی تماممتن (full-text search) همچنان روی بدنههای رمزنگاریشده کار میکند نیز مشخص نشده است. پیش از آنکه این قابلیت را به کسی وعده دهید، آن را روی یک اکانت آزمایشی تست کنید.
و اگر کاربری کلید خصوصی خود را گم کند، ایمیلهایش از دست رفته است. طبق طراحی، هیچ مسیر بازیابی (recovery path) وجود ندارد.
WKD یک وظیفه وبسرور است، نه یک وظیفه میلسرور
WKD (Web Key Directory) نیمه دیگر داستان OpenPGP است و مشکل متفاوتی را حل میکند. این پروتکل کلید عمومی شما را در یک URL ثابت HTTPS تحت دامنه شما منتشر میکند تا کلاینت ایمیل فرستنده بتواند آن را پیدا کرده و پیام را پیش از خروج از دستگاهش رمزنگاری کند. این همان رمزنگاری سرتاسری (end-to-end) است. رمزنگاری در حالت سکون (at-rest) در Stalwart مربوط به نسخهای است که روی دیسک شما قرار دارد. راهاندازی یکی، دیگری را برای شما فراهم نمیکند.
Stalwart سرویس WKD ارائه نمیدهد. نقاط پایانی (endpoints) HTTP مستند شده آن، که در تاریخ 28 August 2026 مطالعه شد، مسیرهای شناختهشدهای را برای jmap، caldav، carddav، oauth-authorization-server، openid-configuration، acme-challenge، mta-sts.txt، mail-v1.xml و autoconfig فهرست میکنند. هیچ مسیر openpgpkey وجود ندارد. آن را از طریق یک وبسرور استاتیک معمولی سرو کنید.
این مشخصات دو طرحبندی را تعریف میکند. روش پیشرفته از https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe استفاده میکند. روش مستقیم از https://example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe استفاده میکند. آن رشته 32 کاراکتری، SHA-1 بخش محلی (local part) با حروف کوچک است که با z-base-32 کدگذاری شده است؛ به همین دلیل است که هرگز نباید این نامفایلها را بهصورت دستی بسازید. GnuPG آنها را برای شما میسازد.
gpg --export --armor you@example.org > you.asc
gpg-wks-client --print-wkd-url you@example.org
gpg-wks-client --install-key you.asc you@example.org--print-wkd-url URLای را که کلاینت واکشی میکند، با استفاده از فرم زیردامنه چاپ میکند. --install-key کلید را در یک درخت دایرکتوری محلی مینویسد که طرحبندی WKD را بازتاب میدهد؛ این کار بهصورت پیشفرض در دایرکتوری سطح بالایی به نام openpgpkey انجام میشود و با -C dir قابل تغییر است. آن درخت را در ریشه وب (web root) خود کپی کنید، فایل مورد نیاز policy را در کنار دایرکتوری hu قرار دهید (یک فایل خالی معتبر است) و URL خود را با curl واکشی کنید تا تأیید شود که بایتهای کلید را برمیگرداند و نه خطای 404.
ذخیرهسازی روی یک VPS واحد
نرمافزار Stalwart فضای ذخیرهسازی را به چهار نقش تقسیم میکند: یک data store برای رکوردهای ساختاریافته مانند وضعیت صندوق پستی، یک blob store برای بایتهای خام پیامها و پیوستها، یک search store برای نمایهسازی متن کامل، و یک in-memory store برای محدودکنندههای نرخ (rate limiters)، توکنهای احراز هویت و دادههای نشست (session). هر کدام از این بخشها میتوانند به یک backend متفاوت اشاره کنند. لیست موارد پشتیبانیشده شامل RocksDB، FoundationDB، PostgreSQL، MySQL، SQLite، فضای ذخیرهسازی شیء (object storage) سازگار با S3، Azure Blob Storage، Redis، ElasticSearch و Meilisearch است.
روی یک VPS واحد، پاسخ کوتاه است. مستندات، RocksDB را «بهدلیل سرعت و قابلیت اطمینان، backend توصیهشده برای نصبهای تکگره (single-node) Stalwart» مینامند. Redis فقط بهعنوان in-memory store پشتیبانی میشود و نمیتواند نقش data store یا blob store را ایفا کند؛ بنابراین برای شروع کار، نیازی به کانتینر مجزای Redis نیست. اگر حجم صندوقهای پستی از فضای دیسک فراتر رفت، میتوانید blob store را به S3 منتقل کنید.
پشتیبانگیریها از backend پیروی میکنند. برای پایگاهدادههای خارجی، از رویهٔ اختصاصی همان پایگاهداده استفاده کنید. برای موارد تعبیهشده (embedded)، طبق FAQ باید دایرکتوری /var/lib/stalwart را کپی کنید. این کار را در حالی انجام دهید که سرویس متوقف است، یا از طریق snapshot فایلسیستم یا volume اقدام کنید. کپی در سطح فایل از یک key-value store در حال اجرا ممکن است آن را در میانهٔ عملیات نوشتن ثبت کند و تا زمانی که برای بازیابی تلاش نکنید، متوجه خرابی آن نخواهید شد.
فیلتر اسپمی که جایگزین Rspamd میشود
فیلترینگ در داخل همان پردازش اجرا میشود، بنابراین هیچ daemon دومی برای فعال نگهداشتن وجود ندارد. طبقهبندیکننده (classifier) در SpamClassifier singleton تحت بخش Settings، Spam Filter، Classifier پیکربندی میشود. این ابزار از الگوریتم FTRL-Proximal به همراه feature hashing استفاده میکند. گزینه FtrlFh تنظیم پیشفرض توصیهشده برای اکثر استقرارها است. گزینه FtrlCcfh از cuckoo feature hashing استفاده میکند تا تداخلهای هش (hash collisions) را کاهش دهد و برای استقرارهای در مقیاس بزرگ طراحی شده است. این سیستم بهطور مداوم آموزش میبیند: هنگامی که کاربران پیامی را به عنوان اسپم یا ham علامتگذاری میکنند، آن برچسب مستقیماً در تصمیمگیریهای آینده لحاظ میشود.
در اطراف طبقهبندیکننده، قابلیتهایی نظیر DNS blocklists، greylisting، تشخیص فیشینگ، تلههای اسپم (spam traps) و Pyzor قرار دارند؛ همچنین اگر قوانینی دارید که نمیخواهید از آنها صرفنظر کنید، امکان فراخوانی SpamAssassin از طریق milter نیز فراهم است.
چه زمانی mailcow همچنان انتخاب مناسبی است
Stalwart فاقد webmail است. این بزرگترین خلأ موجود است و هیچ جایگزینی برای آن وجود ندارد. مستندات mailcow که در تاریخ 28 August 2026 مطالعه شد، شانزده مؤلفه از جمله SOGo را فهرست میکند که به کاربران شما یک صندوق ورودی تحت مرورگر و رابطهای CalDAV و CardDAV را بهصورت پیشفرض ارائه میدهد. در پست نقشه راه Stalwart مورخ 20 June 2025 ذکر شده است که یک webmail داخلی «در برنامههای ما قرار دارد، اما در حال حاضر اولویت فوری ما نیست» و قرار است پس از نسخه 1.0 با استفاده از Rust و Dioxus ساخته شود، که «به احتمال زیاد در سال 2026» خواهد بود. تا تاریخ 28 August 2026، وبلاگ پروژه هیچ پستی مبنی بر معرفی آن منتشر نکرده است. بنابراین با Stalwart، شما یا باید Roundcube را شخصاً مستقر کنید یا به تکتک کاربران بگویید که یک کلاینت ایمیل پیکربندی کنند.
Stalwart دارای یک رابط مدیریت تحت وب است، بنابراین این آن خلئی نیست که کاربران انتظار دارند. خلأ دوم، بلوغ نسخه است. در بخش FAQ ذکر شده که Stalwart در نسخه 0.x قرار دارد و ممکن است ساختار داده و پیکربندی پیش از نسخه 1.0 تغییر کند که این امر میتواند نیازمند مهاجرت باشد. پست ژوئن 2026 خود پروژه با عنوان «صفر گزارش باگ باز: مسیر رسیدن به Stalwart 1.0» به شما میگوید که وضعیت در چه حال است: نزدیک، اما هنوز نرسیده.
خلأ سوم چیزی است که هیچکس در فهرست ویژگیها قرار نمیدهد. Postfix، Dovecot و Rspamd یک دهه پاسخهای مکتوب پشت سر خود دارند. در ساعت دو بامداد، وقتی ایمیلها در صف ماندهاند و کاربران منتظرند، جستجویی که یک رشته خطای مشابه را برمیگرداند، ارزشمندتر از یک معماری زیبا است. اگر در چنین شرایطی هستید، راهنمای نصب mailcow ما کل پشته را از ابتدا تا انتها پوشش میدهد و شب کوتاهتری خواهید داشت.
زمانی Stalwart را انتخاب کنید که یک فایل اجرایی واحد، یک فایل پیکربندی واحد و JMAP میخواهید و با استفاده از فناوریهای نوظهور راحت هستید. زمانی mailcow را انتخاب کنید که همین امروز به webmail نیاز دارید و به دنبال حجم بزرگی از پاسخهای موجود برای مشکلات احتمالی هستید.
انتقال ایمیلهای موجود
مسیر استاندارد برای این کار، استفاده از پروتکل IMAP به IMAP با ابزار imapsync است که فارغ از نوع سیستمعامل یا نرمافزار مبدأ و مقصد عمل میکند. ابتدا یک اجرای آزمایشی (dry run) انجام دهید.
imapsync --dry \
--host1 old.example.org --user1 you@example.org --passfile1 /root/.old.pw \
--host2 mail.example.org --user2 you@example.org --passfile2 /root/.new.pwفلگ --dry باعث میشود imapsync «هیچ عملیات واقعی انجام ندهد و فقط آنچه قرار است انجام شود را گزارش کند»؛ بنابراین پیش از حذف این فلگ، خروجی را بهدقت مطالعه کنید. هر فایل رمز عبور، پسورد را در خط اول خود نگه میدارد، پس هر دو فایل chmod 600 را ایجاد کرده و پس از پایان کار آنها را حذف کنید.
نرمافزار Stalwart ابزارهای جدیدتری ارائه میدهد که اکثر راهنماهای شخصثالث هنوز با آنها بهروز نشدهاند. وبلاگ این پروژه ابزار Vandelay (یک واردکننده و صادرکننده JMAP در تاریخ 29 May 2026) و یک پروکسی مهاجرت برای ارتقا بدون قطعی (در تاریخ 10 June 2026) را مستند کرده است. پیش از برنامهریزی برای انتقالهای بزرگ، هر دو مطلب را مطالعه کنید، زیرا این مستندات از تقریباً هر منبع دیگری که در جای دیگر مییابید، جدیدتر هستند.
حالتهای شکست و رشتههایی که مشاهده خواهید کرد
رابط کاربری مدیریت بارگذاری نمیشود. بخش FAQ مستقیماً به این مورد اشاره دارد: بسته رابط وب در اولین اجرا از GitHub دانلود میشود، بنابراین سروری که دسترسی خروجی HTTPS به github.com ندارد، سرویسی در حال اجرا اما با صفحهای خالی به شما میدهد. این موضوع را با curl -sI https://github.com/stalwartlabs/webui/releases/latest/ از روی سرور بررسی کنید. سایر دلایل رایجی که در آنجا ذکر شده، عدم تطابق طرح HTTP یا HTTPS و همچنین reverse proxy است که IP کلاینت را فوروارد نمیکند.
رمز عبور bootstrap در لاگ وجود ندارد. این رمز فقط یکبار، در زمان راهاندازی و در حالت bootstrap چاپ میشود. اگر سرویس از آن زمان restart شده است، بازه زمانی مشاهده لاگ را با sudo journalctl -u stalwart --since today | grep -A8 'bootstrap mode' افزایش دهید. اگر رمز واقعاً از بین رفته است، STALWART_RECOVERY_ADMIN را در /etc/stalwart/stalwart.env تنظیم کرده و سرویس را restart کنید.
ارسال (Relay) از طریق یک پروکسی محلی رد میشود. یادداشتهای انتشار نسخه v0.16.19 به رفع مشکلی اشاره دارد که در آن مسیرهای relay با خطای host resolves loopback address رد میشدند. اگر دقیقاً با همین رشته مواجه شدید، در حال اجرای یک build قدیمی هستید. نسخه را بهروزرسانی کنید و به دنبال راهحلهای موقت نباشید.
سرویس پس از نوشتن unit اختصاصی شما اجرا نمیشود. بدون AmbientCapabilities=CAP_NET_BIND_SERVICE، کاربر stalwart نمیتواند پورتهای 25، 443، 465 یا 993 را bind کند و راهاندازی در اولین listener با شکست مواجه میشود. خط capability را از unit که توسط installer تولید شده است، کپی کنید.
گواهیها صادر نمیشوند. چالش HTTP-01 نیازمند در دسترس بودن و آزاد بودن پورت 80 است. چالش TLS-ALPN-01 نیازمند این است که خود Stalwart به handshake پروتکل TLS روی پورت 443 پاسخ دهد. اگر سرویس دیگری روی سرور هر یک از این پورتها را اشغال کرده باشد، ACME بدون نمایش خطا به شکست ادامه میدهد، در حالی که سایر بخشها سالم به نظر میرسند.
FAQ
آیا Stalwart جایگزین Postfix، Dovecot و Rspamd روی یک VPS میشود؟
بله. یک باینری Rust به درخواستهای SMTP، IMAP، POP3، JMAP، CalDAV، CardDAV و WebDAV پاسخ میدهد و شامل فیلتر اسپم، ذخیرهساز پیام و یک کلاینت ACME است. به جای چهار دیمون و اتصالات بین آنها، تنها یک systemd unit و یک فایل پیکربندی در /etc/stalwart/config.json وجود دارد. چیزی که جایگزین نمیشود، DNS zone شما یا سیاست پورت 25 ارائهدهندهٔ سرور شماست؛ جایی که موفقیت یا شکست ایمیلهای self-hosted در آن رقم میخورد.
یک سرور ایمیل Stalwart به چه مقدار RAM نیاز دارد؟
صفحهٔ نیازمندیهای سیستم Stalwart که در تاریخ 28 August 2026 مطالعه شد، حدود 100 MB در حالت idle را پیشنهاد میدهد و ذکر میکند که 1 GB رم برای یک استقرار کوچک با 5 تا 10 کاربر مناسب است. یک راهاندازی با ترافیک پایین برای حدود 5 کاربر روی یک هستهٔ CPU اجرا میشود. محدودیت پیشفرض برای اتصالات همزمان در تمام سرویسها 8,192 است که قابل پیکربندی میباشد، بنابراین سقف مصرف منابع بیشتر با تعداد اتصالات و حجم ایمیل افزایش مییابد تا صرفاً با تعداد کاربران. حداقل فضای دیسک اعلام نشده است، بنابراین دیسک را بر اساس حجم ایمیلهایی که نگهداری میکنید، انتخاب کنید.
آیا مهاجرت به Stalwart تحویلپذیری (deliverability) ایمیلهای من را بهبود میبخشد؟
خیر. تحویلپذیری ایمیل به این بستگی دارد که آیا پورت خروجی 25 TCP روی VPS شما باز است یا خیر، و همچنین به reverse DNS روی IP شما و تنظیمات SPF، DKIM و DMARC روی دامنهٔ شما وابسته است. Stalwart از DANE، MTA-STS و گزارشدهی SMTP TLS پشتیبانی میکند و میتواند سیاست MTA-STS شما را منتشر کند، اما این موارد امنیت انتقال را مدیریت میکنند، نه اینکه آیا شبکهٔ مقصد به آدرس شما اعتماد دارد یا خیر. پیش از نصب هر چیزی، پورت 25 را با nc -vz -w 5 alt1.aspmx.l.google.com 25 تست کنید.
آیا Stalwart شامل وبمیل (webmail) است؟
تا تاریخ 28 August 2026 خیر. این نرمافزار یک رابط مدیریت تحت وب ارائه میدهد که موضوع متفاوتی است. پست نقشهٔ راه پروژه در تاریخ 20 June 2025 میگوید که یک کلاینت وبمیل پس از نسخه 1.0 برنامهریزی شده است که با Rust و Dioxus ساخته میشود، «به احتمال زیاد در مقطعی از سال 2026»، و وبلاگ پروژه هنوز هیچ اطلاعیهای در این مورد منتشر نکرده است. اگر کاربران شما اکنون به یک اینباکس تحت مرورگر نیاز دارند، Roundcube را در کنار آن مستقر کنید یا از پشتهای استفاده کنید که شامل SOGo باشد.
رمزنگاری در حالت سکون (encryption at rest) در Stalwart در برابر چه چیزی محافظت میکند؟
این قابلیت پیامهای هر کاربر را با کلید عمومی OpenPGP یا S/MIME خودشان پیش از نوشتن روی دیسک رمزنگاری میکند، بنابراین در صورت سرقت دیسک، سرقت نسخهٔ پشتیبان یا دسترسی مدیر سیستم به ذخیرهساز، محتوا قابل بازیابی نیست. این رمزنگاری سرتاسری (end-to-end) نیست: پیام به صورت متن ساده (plain text) میرسد و هنگام تحویل رمزنگاری میشود، بنابراین تمام مسیرهای پیش از آن، پیام را مشاهده کردهاند. مقدار پیشفرض encryptOnAppend برابر با false است، بنابراین پوشههای Sent و Drafts که توسط کلاینت شما نوشته میشوند، به صورت شفاف (clear) باقی میمانند مگر اینکه آن را تغییر دهید. مستندات تنها محتوای پیام را پوشش میدهند و دربارهٔ متادیتا، ورودیهای ایندکس یا رمزنگاری مجدد ایمیلهای ذخیرهشده پیش از آپلود کلید، چیزی نمیگویند؛ بنابراین به جای فرض کردن، خودتان این موارد را بررسی کنید.