Cài đặt Stalwart Mail Server trên VPS: Hướng dẫn chi tiết

Những thành phần mà Stalwart gộp vào một binary duy nhất

Stalwart là một mail server bạn chạy trên một VPS dưới dạng một binary Rust duy nhất. Nó xử lý SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV và WebDAV từ cùng một tiến trình, đồng thời tích hợp sẵn bộ lọc spam, kho lưu trữ tin nhắn và client ACME riêng. Một stack truyền thống thực hiện công việc tương tự với Postfix, Dovecot, Rspamd, một database cho tài khoản và một công cụ quản lý chứng chỉ riêng biệt. Stalwart thay thế tất cả bằng một service unit và một file cấu hình tại /etc/stalwart/config.json.

Mọi số liệu, tên thiết lập và lệnh bên dưới đều được trích dẫn từ tài liệu, các trang release và script cài đặt của Stalwart, được đọc lần đầu vào ngày 28 tháng 8 năm 2026 dựa trên bản release v0.16.19 (phát hành ngày 24 tháng 8 năm 2026) và kiểm tra lại vào ngày 12 tháng 10 năm 2026, khi bản release mới nhất là v0.16.26 (phát hành ngày 11 tháng 10 năm 2026). Đây là các lệnh để bạn chạy trên server của mình. Mỗi lệnh đều đi kèm với bước kiểm tra để xác nhận xem nó đã hoạt động hay chưa.

Stalwart được cấp phép kép theo GNU Affero General Public License v3.0 (AGPL-3.0) và Stalwart Enterprise License v2. Một số tính năng chỉ dành cho bản enterprise. Danh sách HTTP endpoint trong tài liệu đánh dấu /scim/v2/* cho các tính năng đó. Hãy đọc kỹ các điều khoản cấp phép trước khi bạn lên kế hoạch triển khai dựa trên một tính năng mà bạn chưa tự mình chạy thử.

Một binary duy nhất thực sự cắt giảm được các thành phần chuyển động. Nó không cắt giảm hai yếu tố quyết định việc email của bạn có đến nơi hay không.

Cổng 25 và uy tín DNS không phụ thuộc vào phần mềm bạn chạy

Cổng TCP 25 chiều đi là cửa ải đầu tiên. Nhiều nhà cung cấp VPS chặn cổng này mặc định trên các tài khoản mới, và cổng 25 bị chặn đồng nghĩa với việc máy chủ của bạn không thể gửi mail trực tiếp đến máy chủ mail của bất kỳ ai khác. Hãy kiểm tra nó trước khi cài đặt bất cứ thứ gì.

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 alt1.aspmx.l.google.com 25

Một kết quả thành công sẽ in ra Connection to alt1.aspmx.l.google.com ... 25 port [tcp/smtp] succeeded! trong khoảng một giây. Việc bị chặn sẽ hiển thị theo một trong hai cách. Nếu các gói tin bị drop ở phía upstream, không có phản hồi reset nào gửi lại cho bạn, vì vậy nc sẽ treo trong trọn vẹn năm giây rồi in ra nc: connect to alt1.aspmx.l.google.com port 25 (tcp) failed: Connection timed out. Nếu firewall từ chối chúng, nó sẽ gửi lại một lỗi ICMP (reject của netfilter sẽ gửi port unreachable trừ khi được cấu hình để gửi thông báo khác, ví dụ như administratively prohibited), nên lỗi sẽ xuất hiện ngay lập tức, thường là Connection refused hoặc No route to host. Dù là trường hợp nào, hãy mở ticket yêu cầu nhà cung cấp hỗ trợ.

Nếu nhà cung cấp không mở cổng, cách duy nhất để vượt qua là dùng relay. Stalwart có thể chuyển toàn bộ mail gửi đi đến một smarthost thông qua một Relay route, với cổng mặc định là 25 nhưng chấp nhận bất kỳ giá trị nào từ 1 đến 65535, cùng với switch implicitTls và các trường authUsername và authSecret để xác thực relay trên cổng 465 hoặc 587. Khi đó, mail của bạn sẽ rời đi dưới uy tín của relay, không phải của chính bạn.

Cửa ải thứ hai là cách các mạng nhận mail đánh giá địa chỉ IP và domain của bạn. Điều này bao gồm reverse DNS trên IP, SPF, DKIM, DMARC và lịch sử gửi mail của dải địa chỉ IP mà bạn đang sử dụng. Trang thiết lập DNS của Stalwart, theo như chúng tôi đọc vào ngày 28 tháng 8 năm 2026, đã nêu rõ nơi thực hiện công việc đó: các bản ghi reverse DNS "thường được cấu hình bởi nhà cung cấp hosting, không phải bởi chính Stalwart". Điều tương tự cũng đúng với các mục còn lại trong danh mục này. Nó nằm trong zone DNS của bạn và trong bảng điều khiển của nhà cung cấp, không nằm trong máy chủ mail.

Vì vậy, trang này không hướng dẫn lại các bản ghi đó. Chúng tôi có một bài viết chuyên biệt: Thiết lập SPF, DKIM và DMARC một lần cho mọi dịch vụ gửi mail. Nếu bạn vẫn chưa quyết định có nên tự host email hay không, hãy bắt đầu với cái nhìn trung thực của chúng tôi về việc liệu tự host email có còn đáng giá hay không. Việc chọn Stalwart không làm thay đổi bất kỳ tính toán nào trong số đó.

Yêu cầu hệ thống đối với một VPS nhỏ để chạy Stalwart mail server

Trang yêu cầu hệ thống của Stalwart, được đọc vào ngày 12 tháng 10 năm 2026, cung cấp các con số sau. Mức sử dụng RAM khi ở trạng thái nghỉ là khoảng 100 MB. Một triển khai nhỏ cho từ 5 đến 10 người dùng có thể chạy ổn định trên 1 GB RAM. Một thiết lập lưu lượng thấp với khoảng 5 người dùng chỉ cần một nhân CPU, và trang này bổ sung rằng "khi mức độ đồng thời và hoạt động tăng lên, cần thêm nhân CPU để duy trì độ trễ thấp và thông lượng cao". Giới hạn mặc định là 8,192 kết nối đồng thời trên tất cả các dịch vụ, và con số này có thể cấu hình được.

Trang đó không nêu kích thước đĩa tối thiểu, vì vậy hãy chọn dung lượng đĩa dựa trên lượng email bạn dự kiến lưu trữ, cộng thêm khoảng trống để hệ thống nén dữ liệu.

Ba luồng kết nối outbound phải hoạt động, nếu không máy chủ sẽ bị lỗi theo những cách không liên quan đến email. Nó cần tải gói giao diện web từ https://github.com/stalwartlabs/webui/releases/latest/. Nó cần kết nối đến https://acme-v02.api.letsencrypt.org/directory để lấy chứng chỉ. Nó cần DNS trên cổng UDP và TCP 53 để truy vấn bản ghi MX và xác thực. Một firewall chặn egress mà chặn kết nối đầu tiên sẽ khiến bạn có một máy chủ mail đang chạy nhưng không có giao diện quản trị.

Cài đặt một bản release cố định, không dùng "latest"

Trình cài đặt chính thức là một shell script. Hãy đọc nó trước khi bạn chạy.

curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
less install.sh
sudo sh install.sh

Đọc script đó vào ngày 12 tháng 10 năm 2026 cho thấy chính xác những gì nó thực hiện. Nó tạo một tài khoản dịch vụ stalwart và các thư mục cần thiết. Sau đó, nó tải xuống từ https://github.com/stalwartlabs/stalwart/releases/latest/download. File binary được đặt tại /usr/local/bin/stalwart với mode 0755. Cấu hình được lưu tại /etc/stalwart/config.json, dữ liệu tại /var/lib/stalwart, log tại /var/log/stalwart, cả ba thư mục đều có mode 0750 và thuộc sở hữu của stalwart. Một file môi trường được ghi vào /etc/stalwart/stalwart.env với mode 0640 và thuộc sở hữu của root:stalwart. Script nhận một tiền tố cài đặt tùy chọn và một flag --fdb cho bản build FoundationDB. Nó không nhận đối số phiên bản.

Điểm cuối cùng đó rất quan trọng. Script luôn tải bản release mới nhất, vì vậy hai máy chủ được xây dựng cách nhau một tuần sẽ không chạy cùng một mã nguồn. Hãy tự cố định (pin) file binary ngay sau đó, đây cũng là lộ trình nâng cấp mà ghi chú phát hành v0.16.26 đưa ra: "Nếu bạn đang nâng cấp từ v0.16.x, hãy thay thế file binary (hoặc chạy docker pull)." Bảy bản patch release đã được phát hành từ ngày 24 tháng 8 đến ngày 11 tháng 10 năm 2026, trong đó có một số bản chứa các bản vá bảo mật, vì vậy hãy cố định bản mới nhất và chủ động thay đổi bản cố định khi cần.

STALWART_TAG=v0.16.26
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 stalwart

systemctl is-active stalwart sẽ in ra active. Nếu là bất kỳ kết quả nào khác, hãy đọc journalctl -u stalwart -n 50. Mỗi tài nguyên release đều đi kèm với một gói .sigstore.json tương ứng, vì vậy chữ ký của file tải về có thể xác minh được trước khi bạn cài đặt.

Unit mà script tạo ra chạy dưới quyền User=stalwart và thiết lập AmbientCapabilities=CAP_NET_BIND_SERVICE. Capability này là lý do tại sao một tài khoản không có đặc quyền (unprivileged) có thể bind các cổng 25, 443, 465 và 993. Nếu sau này bạn tự viết unit của riêng mình và bỏ qua dòng đó, dịch vụ sẽ fail khi khởi động, vì người dùng thông thường không thể bind cổng dưới 1024.

Nơi in mật khẩu quản trị viên đầu tiên

Stalwart khởi động ở chế độ bootstrap và ghi một mật khẩu tạm thời gồm 16 ký tự vào log của dịch vụ đúng một lần.

sudo journalctl -u stalwart -n 200 | grep -A8 'bootstrap mode'

Trình hướng dẫn thiết lập (setup wizard) lắng nghe trên HTTP thường tại cổng 8080, vì vậy đừng mở cổng này ra ngoài. Thay vào đó, hãy tạo tunnel từ laptop của bạn qua SSH:

ssh -N -L 8080:127.0.0.1:8080 you@your-vps

Sau đó mở http://127.0.0.1:8080/admin và đăng nhập với tư cách admin bằng mật khẩu từ log. Trình hướng dẫn sẽ yêu cầu hostname của máy chủ, domain mail mặc định, TLS, bộ nhớ, thư mục tài khoản, logging và cách xử lý DNS. Khởi động lại dịch vụ khi hoàn tất, sau đó sử dụng https://<your-host>/admin kể từ thời điểm đó.

Nếu mật khẩu đã bị trôi khỏi log, hãy đặt một mật khẩu cố định thay thế. /etc/stalwart/stalwart.env cung cấp sẵn các mục đã được comment cho việc này, bao gồm STALWART_RECOVERY_ADMIN=admin:changeme, STALWART_RECOVERY_MODE=true và STALWART_RECOVERY_MODE_PORT (mặc định là 8080). Hãy bỏ comment, khởi động lại, đăng nhập, sau đó comment lại. Trang hướng dẫn bảo mật của Stalwart khuyến cáo chỉ nên giữ thông tin xác thực đó cho các trường hợp khẩn cấp, và không bao giờ đăng nhập vào IMAP, JMAP hoặc WebDAV bằng tài khoản quản trị viên.

Cùng trang đó liệt kê các listener cần giữ lại: cổng 25 cho SMTP inbound, 465 cho submission với implicit TLS, 993 cho IMAPS, và 443 cho mọi lưu lượng HTTP. Tài liệu này coi các cổng 587, 143, 4190, 110, 995 và 8080 là không thiết yếu, và yêu cầu tắt cổng 8080 sau khi thiết lập xong.

Chạy dưới Docker với một tag cố định

Image được tài liệu hóa là stalwartlabs/stalwart. Tag v0.16.26 đã có mặt trên Docker Hub vào ngày 12 tháng 10 năm 2026, cùng với một biến thể -alpine. Trang Docker của Stalwart gợi ý sử dụng tag minor v0.16 cho môi trường production. Hãy ghim phiên bản patch thay vì dùng tag minor, với lý do tương tự như đối với file binary ở trên.

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16.26
    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:

File đó là lệnh docker run đã được tài liệu hóa, viết dưới dạng Compose, với các listener không cần thiết đã bị lược bỏ và cổng setup được bind vào localhost. Hãy khởi chạy nó và đọc dòng bootstrap tương tự:

docker compose up -d
docker compose logs stalwart 2>&1 | grep -A8 'bootstrap mode'

Trang Docker cũng tài liệu hóa -e STALWART_RECOVERY_ADMIN=admin:mySecretPass như một cách để thiết lập credential cố định khi khởi động, đây chính là key environment: trong Compose nếu bạn thích cách này hơn là đọc log.

Nếu bạn mới làm quen với Compose, hướng dẫn Docker Compose cho VPS của chúng tôi sẽ bao gồm cấu trúc file và mô hình named-volume được sử dụng ở đây. Một cảnh báo đặc biệt quan trọng đối với các mail server: Docker publish các cổng bằng cách tự ghi đè các rule firewall của chính nó, và các rule đó được ưu tiên kiểm tra trước ufw, vì vậy ufw deny 8080 không thể đóng một cổng mà Compose đã publish. Việc bind vào 127.0.0.1 trong phần port mapping mới là cách thực sự đóng cổng đó, đó là lý do tại sao file trên làm như vậy và SSH tunnel vẫn có hiệu lực.

TLS không cần certbot và cái giá phải trả

Stalwart triển khai ACME (automatic certificate management environment) trực tiếp, vì vậy không cần certbot và không cần hook gia hạn. Tài liệu liệt kê bốn phương thức xác thực. HTTP-01 trả lời yêu cầu thử thách trên cổng 80. TLS-ALPN-01 trình bày một chứng chỉ chuyên dụng trên cổng 443 sử dụng giao thức ALPN đặc thù của ACME. DNS-01 xuất bản các bản ghi TXT tạm thời và là một trong hai phương thức có thể cấp chứng chỉ wildcard. DNS-PERSIST-01 sử dụng các bản ghi TXT ủy quyền tồn tại lâu dài thay vì ghi mới mỗi khi gia hạn.

Cái giá phải trả là Stalwart muốn kiểm soát TLS handshake. TLS-ALPN-01 hoạt động bằng cách tự hoàn tất handshake, vì vậy nó không thể thành công nếu nằm sau một reverse proxy thực hiện TLS termination cho bạn. Nếu nginx hoặc Caddy đã chiếm cổng 443 trên máy chủ đó, bạn có ba cách giải quyết. Hướng dẫn nginx của chính Stalwart chạy nginx dưới dạng TCP passthrough, với listen 443; proxy_pass 127.0.0.1:10443; proxy_protocol on;, để kết nối TLS đến được Stalwart mà không bị can thiệp. Cách này chuyển mọi kết nối trên cổng 443 cho Stalwart, nên nó phù hợp với máy chủ không chạy dịch vụ nào khác trên cổng đó. Nếu không, hãy chuyển Stalwart sang dùng DNS-01 hoặc HTTP-01, hoặc cấp cho nó một địa chỉ IP riêng.

DANE và MTA-STS, cùng các thiết lập mặc định bạn cần biết

Cả hai đều được cấu hình theo chiến lược TLS trên đối tượng MtaTlsStrategy, tại mục Settings, MTA, Outbound, TLS Strategies trong giao diện web. Trường dane mặc định là optional, cơ chế này thử xác thực DANE khi người nhận công bố bản ghi TLSA và quay lui về STARTTLS thông thường nếu không có. Thiết lập thành require để việc gửi mail chỉ tiếp tục khi có bản ghi TLSA xác thực được. Trường mtaSts hoạt động tương tự, mặc định là optional. Các timeout liên quan là tlsTimeout (mặc định 3 phút) và mtaStsTimeout (mặc định 5 phút).

Ở chiều inbound, Stalwart có thể công bố chính sách MTA-STS của riêng bạn tại https://mta-sts.<domain>/.well-known/mta-sts.txt, yêu cầu mở cổng 443. Singleton MtaSts có các trường mode (mặc định testing), maxAge (mặc định 7 ngày) và mxHosts, trường này sẽ lấy các hostname trong chứng chỉ TLS của bạn nếu để trống. Bạn cần cung cấp hai bản ghi DNS: một bản ghi mta-sts CNAME trỏ tới mail host, và một bản ghi _mta-sts TXT chứa định danh chính sách.

dig +short TXT _mta-sts.example.org
curl -s https://mta-sts.example.org/.well-known/mta-sts.txt

Truy vấn TXT phải trả về chuỗi v=STSv1; id=... và lệnh curl phải trả về nội dung chính sách. Nếu curl không trả về gì, cổng 443 đang đóng hoặc chứng chỉ cho mta-sts.example.org chưa từng được cấp.

Để mode ở chế độ testing cho đến khi cả hai kiểm tra trên đều thành công. Một chính sách ở chế độ enforce với chứng chỉ bị lỗi sẽ ngăn các máy chủ khác gửi mail cho bạn, và bạn sẽ nhận phản hồi từ người dùng thay vì từ log. DANE có một cái bẫy tương tự: nó yêu cầu một zone đã ký DNSSEC, và bản ghi TLSA ghim (pin) chứng chỉ leaf phải được công bố lại mỗi khi ACME gia hạn. Hãy ghim CA cấp phát thay vì ghim leaf, hoặc chấp nhận việc phải cập nhật thủ công mỗi khi gia hạn.

Mã hóa dữ liệu lưu trữ (encryption at rest) không phải là mã hóa đầu cuối (end-to-end)

Đây là tính năng thường bị hiểu sai nhất, vì vậy dưới đây là chính xác những gì tài liệu mô tả. Tin nhắn văn bản thuần của mỗi người dùng sẽ tự động được mã hóa bằng chứng chỉ OpenPGP hoặc S/MIME của họ trước khi được ghi vào đĩa. encryptAtRest được bật mặc định và áp dụng cho các tin nhắn đến qua SMTP hoặc LMTP, với điều kiện người nhận đã đăng ký khóa mã hóa. encryptOnAppend mặc định là false, "điều này giữ nguyên các tin nhắn được thêm vào để client duy trì toàn quyền kiểm soát nội dung mà họ lưu trữ". OpenPGP sử dụng PGP/MIME thay vì chuẩn PGP/Inline cũ hơn, với AES-256 hoặc AES-128. Stalwart không tự tạo khóa: người dùng xuất public key định dạng ASCII-armored và đăng ký nó dưới dạng một đối tượng PublicKey trong mục Account, Public Keys.

Vì vậy, nó bảo vệ dữ liệu khi ổ đĩa bị đánh cắp, bản sao lưu bị đánh cắp và ngăn quản trị viên đọc dữ liệu lưu trữ sau khi tin nhắn đã được gửi đến. Nếu không có private key, các byte dữ liệu được lưu trữ sẽ không thể đọc được và quản trị viên cũng không thể giải mã chúng.

Nó không bảo vệ tin nhắn trong quá trình truyền tải. Tin nhắn đi qua internet theo bất kỳ giao thức TLS nào mà hai máy chủ đã thỏa thuận, đến nơi dưới dạng văn bản thuần, và Stalwart sẽ mã hóa nó tại thời điểm đó. Người gửi, nhà cung cấp của người gửi và bất kỳ chặng trung gian nào đã loại bỏ TLS đều đã thấy nội dung văn bản thuần.

Cần làm rõ thêm ba hạn chế nữa. Các thư mục Sent và Drafts được ghi bởi client của bạn, đây là thao tác thêm (append), và encryptOnAppend mặc định là false, vì vậy các tin nhắn này vẫn ở dạng không mã hóa trừ khi bạn thay đổi cài đặt. Tài liệu tôi đọc lại vào ngày 12 tháng 10 năm 2026 chỉ mô tả nội dung tin nhắn và không nói rằng dữ liệu phong bì (envelope data), header hoặc các mục chỉ mục (index entries) được mã hóa, vì vậy đừng mặc định là chúng được bảo vệ. Tài liệu cũng không nói rằng các tin nhắn đã lưu trữ trước khi bạn tải khóa lên sẽ được mã hóa lại, vì vậy hãy mặc định là không và kiểm tra lại. Việc tìm kiếm toàn văn (full-text search) có còn hoạt động trên các nội dung đã mã hóa hay không cũng không được đề cập. Hãy kiểm tra điều đó trên một tài khoản dùng thử trước khi cam kết với bất kỳ ai.

Và nếu người dùng làm mất private key, thư của họ sẽ mất vĩnh viễn. Theo thiết kế, không có quy trình khôi phục nào.

WKD là tác vụ của web server, không phải mail server

WKD (Web Key Directory) là một nửa còn lại của OpenPGP và nó giải quyết một vấn đề khác. Nó xuất bản public key của bạn tại một URL HTTPS cố định dưới tên miền của bạn để mail client của người gửi có thể tìm thấy và mã hóa tin nhắn trước khi nó rời khỏi máy của họ. Đó là mã hóa đầu cuối (end-to-end encryption). Mã hóa at-rest của Stalwart liên quan đến bản sao lưu trữ trên ổ đĩa của bạn. Thiết lập cái này không đồng nghĩa với việc bạn có cái kia.

Stalwart không phục vụ WKD. Các HTTP endpoint được ghi lại của nó, đọc vào ngày 12 tháng 10 năm 2026, liệt kê các đường dẫn well-known cho jmap, caldav, carddav, oauth-authorization-server, openid-configuration, acme-challenge, mta-sts.txt, mail-v1.xml và autoconfig. Không có đường dẫn openpgpkey. Hãy phục vụ nó từ một web server tĩnh thông thường.

Đặc tả kỹ thuật định nghĩa hai bố cục. Phương pháp nâng cao sử dụng https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe. Phương pháp trực tiếp sử dụng https://example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe. Chuỗi 32 ký tự đó là SHA-1 của phần local-part (viết thường) được mã hóa theo z-base-32, đó là lý do tại sao bạn không bao giờ nên tự tạo các tên file này bằng tay. GnuPG sẽ tạo chúng cho bạn.

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 in ra URL mà client sẽ truy xuất, sử dụng định dạng sub-domain. --install-key ghi key vào một cây thư mục cục bộ phản chiếu bố cục WKD, nằm dưới một thư mục cấp cao nhất có tên mặc định là openpgpkey và có thể thay đổi bằng -C dir. Hãy copy cây thư mục đó vào web root của bạn, thêm file policy bắt buộc bên cạnh thư mục hu (một file trống là hợp lệ), và dùng curl để truy xuất URL của chính bạn nhằm xác nhận nó trả về các byte key chứ không phải lỗi 404.

Lưu trữ trên một VPS đơn lẻ

Stalwart chia lưu trữ thành bốn vai trò: kho dữ liệu cho các bản ghi có cấu trúc như trạng thái hộp thư, kho blob cho dữ liệu thô của tin nhắn và tệp đính kèm, kho tìm kiếm cho lập chỉ mục toàn văn, và kho lưu trữ trong bộ nhớ (in-memory) cho bộ giới hạn tốc độ, token xác thực và dữ liệu phiên. Mỗi vai trò có thể trỏ đến một backend khác nhau. Danh sách hỗ trợ bao gồm RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, lưu trữ đối tượng tương thích S3, Azure Blob Storage, Redis, ElasticSearch và Meilisearch.

Trên một VPS, câu trả lời rất ngắn gọn. Tài liệu gọi RocksDB là "backend được khuyến nghị cho các cài đặt Stalwart một node vì tốc độ và độ tin cậy của nó". Redis chỉ được hỗ trợ như một kho lưu trữ trong bộ nhớ và không thể làm kho dữ liệu hoặc kho blob, vì vậy không cần container Redis riêng để bắt đầu. Hãy chuyển kho blob sang S3 sau này nếu dung lượng hộp thư vượt quá ổ đĩa.

Việc sao lưu tuân theo backend. Đối với các cơ sở dữ liệu bên ngoài, hãy sử dụng quy trình riêng của cơ sở dữ liệu đó. Đối với các cơ sở dữ liệu nhúng, FAQ hướng dẫn sao chép thư mục /var/lib/stalwart. Hãy thực hiện việc này khi service đã dừng, hoặc từ một bản snapshot của hệ thống tệp hoặc volume. Việc sao chép cấp độ tệp của một key-value store đang chạy có thể bắt gặp đúng lúc nó đang ghi, và bạn sẽ không phát hiện ra lỗi cho đến khi thử khôi phục.

Bộ lọc spam thay thế Rspamd

Việc lọc diễn ra ngay trong cùng một tiến trình, vì vậy không cần duy trì thêm một daemon thứ hai. Bộ phân loại được cấu hình tại SpamClassifier singleton trong mục Settings, Spam Filter, Classifier. Nó sử dụng thuật toán FTRL-Proximal với kỹ thuật băm đặc trưng (feature hashing). FtrlFh là tùy chọn mặc định được khuyến nghị cho hầu hết các triển khai. FtrlCcfh chuyển sang sử dụng cuckoo feature hashing để giảm thiểu xung đột hash và hướng tới các triển khai quy mô lớn. Hệ thống tự huấn luyện liên tục: khi người dùng đánh dấu một thư là spam hoặc ham, nhãn đó sẽ được đưa trực tiếp vào các quyết định trong tương lai.

Bao quanh bộ phân loại là các danh sách chặn DNS (DNS blocklists), greylisting, phát hiện phishing, spam traps và Pyzor, cùng với tùy chọn gọi SpamAssassin thông qua milter nếu bạn có các quy tắc không muốn từ bỏ.

Khi nào mailcow vẫn là lựa chọn phù hợp

Stalwart không có webmail. Đây là thiếu sót lớn nhất và không có giải pháp thay thế tương đương. Tài liệu của mailcow, được đọc vào ngày 12 tháng 10 năm 2026, liệt kê mười sáu thành phần bao gồm SOGo, cung cấp cho người dùng hộp thư trên trình duyệt cùng giao diện CalDAV và CardDAV ngay khi cài đặt. Bài viết về lộ trình của Stalwart ngày 20 tháng 6 năm 2025 cho biết webmail tích hợp "nằm trong kế hoạch, nhưng hiện không phải là ưu tiên hàng đầu", sẽ được xây dựng bằng Rust với Dioxus sau phiên bản 1.0, "nhiều khả năng là vào khoảng năm 2026". Tính đến ngày 12 tháng 10 năm 2026, blog của dự án chưa có bài đăng nào thông báo về tính năng này. Vì vậy, với Stalwart, bạn phải tự triển khai Roundcube hoặc yêu cầu mọi người dùng tự cấu hình mail client.

Stalwart có giao diện quản trị web, nên đây không phải là thiếu sót như nhiều người vẫn nghĩ. Khoảng cách thứ hai là độ chín muồi của phiên bản. FAQ cho biết Stalwart đang ở mức 0.x và cấu trúc dữ liệu cũng như cấu hình có thể thay đổi trước khi đạt v1.0, điều này có thể yêu cầu thực hiện migration. Bài viết tháng 6 năm 2026 của chính dự án có tiêu đề "Không còn báo cáo lỗi: Con đường đến với Stalwart 1.0", cho thấy vị thế hiện tại: đã gần hoàn thiện nhưng chưa đạt mốc đó. Tính đến ngày 12 tháng 10 năm 2026, bản release mới nhất vẫn là v0.16.26.

Khoảng cách thứ ba là điều không ai liệt kê trong danh sách tính năng. Postfix, Dovecot và Rspamd có cả thập kỷ kinh nghiệm và các câu trả lời đã được ghi lại. Vào lúc hai giờ sáng, khi mail bị xếp hàng chờ và người dùng đang đợi, một kết quả tìm kiếm trả về đúng chuỗi lỗi có giá trị hơn nhiều so với một kiến trúc thanh lịch. Nếu bạn đang ở trong tình huống đó, hướng dẫn cài đặt mailcow của chúng tôi sẽ đi qua toàn bộ stack từ đầu đến cuối và giúp bạn có một đêm ngắn hơn.

Hãy chọn Stalwart khi bạn muốn một binary duy nhất, một file cấu hình duy nhất và JMAP, đồng thời bạn thoải mái với việc là người dùng sớm. Hãy chọn mailcow khi bạn cần webmail ngay hôm nay và một kho dữ liệu câu trả lời khổng lồ đã có sẵn.

Di chuyển email hiện có vào hệ thống

Cách phổ biến nhất là dùng IMAP sang IMAP với imapsync, công cụ này không quan trọng phía đầu nguồn hay đích đang chạy phần mềm gì. Hãy thực hiện chạy thử (dry run) trước.

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 khiến imapsync "không thực hiện thay đổi thực tế; nó chỉ in ra những gì sẽ được thực hiện", vì vậy hãy đọc kết quả đó trước khi bỏ flag này. Mỗi file mật khẩu chứa mật khẩu ở dòng đầu tiên, vì vậy hãy chmod 600 cả hai và xóa chúng sau khi hoàn tất.

Stalwart cũng phát hành các công cụ mới hơn mà hầu hết các hướng dẫn của bên thứ ba chưa cập nhật kịp. Blog của họ có tài liệu về Vandelay, một công cụ nhập và xuất JMAP (29 tháng 5 năm 2026), và một proxy di chuyển để nâng cấp không gây gián đoạn (10 tháng 6 năm 2026). Hãy đọc cả hai trước khi bạn lên kế hoạch di chuyển dữ liệu lớn, vì chúng mới hơn hầu hết mọi tài liệu bạn tìm thấy ở nơi khác.

Các chế độ lỗi và thông báo bạn sẽ gặp

Giao diện quản trị không tải được. FAQ đã nêu rõ vấn đề này: gói giao diện web được tải về từ GitHub trong lần chạy đầu tiên, vì vậy máy chủ không có kết nối HTTPS outbound đến github.com sẽ khiến dịch vụ chạy bình thường nhưng tất cả các route giao diện web đều trả về 404. Hãy kiểm tra bằng curl -sI https://github.com/stalwartlabs/webui/releases/latest/ từ máy chủ. Các nguyên nhân phổ biến khác được liệt kê là sai lệch scheme HTTP hoặc HTTPS và reverse proxy không chuyển tiếp client IP.

Không có mật khẩu bootstrap trong log. Nó chỉ được in một lần duy nhất khi khởi động ở chế độ bootstrap. Nếu dịch vụ đã khởi động lại kể từ đó, hãy mở rộng phạm vi xem log bằng sudo journalctl -u stalwart --since today | grep -A8 'bootstrap mode'. Nếu mật khẩu thực sự đã mất, hãy đặt STALWART_RECOVERY_ADMIN trong /etc/stalwart/stalwart.env và khởi động lại.

Relay qua local proxy bị từ chối. Ghi chú phát hành v0.16.19 đã ghi nhận bản sửa lỗi cho các relay route bị từ chối với host resolves loopback address. Nếu bạn gặp đúng chuỗi thông báo đó, bạn đang chạy một bản build cũ. Hãy cập nhật lên bản mới, đừng tìm cách giải quyết tạm thời.

Dịch vụ không khởi động sau khi bạn tự viết unit file. Nếu thiếu AmbientCapabilities=CAP_NET_BIND_SERVICE, người dùng stalwart không thể bind vào cổng 25, 443, 465 hoặc 993, và quá trình khởi động sẽ thất bại tại listener đầu tiên. Hãy sao chép dòng capability từ unit file mà trình cài đặt đã tạo.

Chứng chỉ không được cấp. HTTP-01 yêu cầu cổng 80 phải truy cập được và đang trống. TLS-ALPN-01 yêu cầu chính Stalwart phải phản hồi TLS handshake trên cổng 443. Nếu một tiến trình khác trên máy đang chiếm một trong hai cổng này, ACME sẽ tiếp tục thất bại âm thầm trong khi mọi thứ khác vẫn trông có vẻ bình thường.

FAQ

Stalwart có thay thế được Postfix, Dovecot và Rspamd trên một VPS không?

Có. Một file binary duy nhất viết bằng Rust đảm nhận SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV và WebDAV, đồng thời tích hợp sẵn bộ lọc spam, kho lưu trữ tin nhắn và client ACME. Bạn chỉ cần quản lý một unit systemd và một file cấu hình tại /etc/stalwart/config.json thay vì phải vận hành bốn daemon riêng biệt cùng các thành phần kết nối trung gian. Stalwart không thay thế được zone DNS của bạn hoặc chính sách cổng 25 từ nhà cung cấp VPS, đây mới là yếu tố quyết định việc tự host email thành công hay thất bại.

Stalwart mail server cần bao nhiêu RAM?

Trang yêu cầu hệ thống của Stalwart, được đọc vào ngày 12 tháng 10 năm 2026, cho biết mức tiêu thụ khoảng 100 MB khi ở trạng thái nghỉ và khuyến nghị 1 GB RAM cho quy mô nhỏ từ 5 đến 10 người dùng. Một thiết lập lưu lượng thấp với khoảng 5 người dùng có thể chạy trên một nhân CPU. Giới hạn mặc định là 8,192 kết nối đồng thời cho tất cả các dịch vụ và có thể cấu hình được, vì vậy mức tiêu thụ tài nguyên sẽ tăng theo số lượng kết nối và lưu lượng mail thay vì chỉ dựa trên số lượng người dùng. Không có yêu cầu dung lượng đĩa tối thiểu, hãy chọn dung lượng đĩa dựa trên lượng mail bạn lưu trữ.

Chuyển sang Stalwart có cải thiện khả năng gửi email không?

Không. Khả năng gửi email phụ thuộc vào việc cổng TCP 25 chiều outbound có được mở trên VPS của bạn hay không, cấu hình reverse DNS trên IP của bạn, và các bản ghi SPF, DKIM, DMARC trên domain của bạn. Stalwart có hỗ trợ DANE, MTA-STS và SMTP TLS reporting, đồng thời có thể tự publish chính sách MTA-STS cho bạn, nhưng các tính năng này quản lý bảo mật truyền tải chứ không quyết định việc mạng nhận có tin tưởng địa chỉ của bạn hay không. Hãy kiểm tra cổng 25 bằng nc -vz -w 5 alt1.aspmx.l.google.com 25 trước khi cài đặt bất cứ thứ gì.

Stalwart có bao gồm webmail không?

Tính đến ngày 12 tháng 10 năm 2026 thì chưa. Nó cung cấp một giao diện quản trị web, đây là một tính năng khác. Bài viết về lộ trình phát triển của dự án ngày 20 tháng 6 năm 2025 cho biết một webmail client đang được lên kế hoạch sau phiên bản 1.0, được xây dựng bằng Rust với Dioxus, "nhiều khả năng là vào khoảng năm 2026", và blog của dự án hiện chưa có thông báo nào về việc này. Nếu người dùng của bạn cần hộp thư trên trình duyệt ngay bây giờ, hãy triển khai Roundcube song song hoặc sử dụng một stack có tích hợp sẵn SOGo.

Tính năng mã hóa dữ liệu lưu trữ (encryption at rest) của Stalwart bảo vệ được những gì?

Nó mã hóa tin nhắn của mỗi người dùng bằng public key OpenPGP hoặc S/MIME của chính họ trước khi ghi xuống đĩa, vì vậy nếu đĩa bị đánh cắp, bản backup bị lộ hoặc quản trị viên truy cập vào kho lưu trữ cũng không thể đọc được nội dung. Đây không phải là mã hóa đầu cuối (end-to-end encryption): tin nhắn đến dưới dạng văn bản thuần (plain text) và chỉ được mã hóa khi lưu trữ, vì vậy mọi chặng trung gian trước đó đều có thể đọc được nội dung. encryptOnAppend mặc định là false, vì vậy các thư mục Sent và Drafts do client của bạn tạo ra sẽ ở dạng văn bản thuần trừ khi bạn thay đổi cấu hình này. Tài liệu chỉ đề cập đến nội dung tin nhắn và không nói gì về metadata, các mục index hoặc việc mã hóa lại các mail đã lưu trữ trước khi key được tải lên, vì vậy hãy tự kiểm chứng thay vì mặc định là có.