Tự vận hành máy chủ email như năm 1984
(maxadamski.com)- Tự vận hành máy chủ email giúp thực hiện tự động hóa với chi phí thấp và quản lý mailing list
- Vấn đề độ tin cậy khi gửi thư tồn tại trong thực tế, nên có thể xảy ra lỗi gửi/nhận với các dịch vụ lớn
- Chỉ với cấu hình Postfix và OpenDKIM là có thể dựng hệ thống SMTP cơ bản và gửi thư có xác thực
- Thiết lập chứng chỉ SSL, DKIM, SPF, DMARC có thể cải thiện độ tin cậy của email và bảo mật truyền tải
- Nếu cấu hình thêm bản ghi PTR (reverse DNS) thì có thể kỳ vọng tăng tỷ lệ đến hộp thư của các dịch vụ email lớn
Tổng quan
Tự vận hành máy chủ email hữu ích cho các tác vụ tự động như mailing list, newsletter, API xác thực email.
Tuy nhiên, thách thức thực tế lớn nhất là độ tin cậy khi chuyển phát email: luôn tồn tại rủi ro thư không đến nơi hoặc không thể nhận được.
Người vận hành áp dụng cách này cho các dự án cá nhân với điều kiện chấp nhận các rủi ro đó.
Ưu điểm của việc tự vận hành là gần như không phát sinh thêm chi phí, vì chỉ cần cài phần mềm lên website hiện có, đồng thời dung lượng lưu trữ và điện năng tiêu thụ cũng rất nhỏ.
Tác giả từng nghĩ việc vận hành máy chủ email sẽ rất khó, nhưng trên thực tế mức độ phức tạp không khác quá nhiều so với cấu hình các dịch vụ email kiểu SaaS.
Để thuận tiện và đơn giản khi cấu hình, phần webmail và môi trường nhiều người dùng được lược bỏ trước, nên không cần thiết lập tài khoản người dùng, cơ sở dữ liệu hay giao diện web.
Cách thiết lập này phù hợp để vận hành với một tài khoản duy nhất; khi cần có thể gửi/nhận thư qua SSH cùng mailx, sendmail, mutt.
Về sau, tùy nhu cầu có thể mở rộng thêm và bổ sung webmail.
Postfix
Về cơ bản, chỉ cần mở cổng 25 rồi cài và cấu hình Postfix cùng OpenDKIM là có thể tạo một máy chủ SMTP cơ bản.
Để gửi thư ổn định tới hầu hết các dịch vụ email (như Gmail), cần có OpenDKIM để xác thực email.
Tác giả giữ nguyên mặc định cho master.cf, còn ví dụ cấu hình chính trong main.cf chỉ thể hiện những thiết lập cốt lõi như mã hóa TLS, tích hợp DKIM.
Không cấu hình POP3/IMAP mà đơn giản hóa bằng cách, khi cần, đăng nhập trực tiếp vào máy chủ qua SSH để gửi/nhận thư bằng các lệnh như mailx.
TLS (mã hóa truyền tải)
Chứng chỉ SSL cần thiết để mã hóa dữ liệu truyền với máy chủ SMTP.
Không cần cấp chứng chỉ cho từng domain; chỉ cần có chứng chỉ cho một host duy nhất nơi máy chủ mail đặt tại đó (dùng cho bản ghi MX) là đủ.
Ví dụ, nếu bản ghi MX là mx.example.com thì chỉ cần lấy chứng chỉ miễn phí từ Let’s Encrypt cho chính domain đó và áp dụng là được.
TLS chỉ mã hóa đoạn truyền nhận giữa các máy chủ, tách biệt với việc xác thực tên miền gửi thực tế.
Vì vậy, trong header From của địa chỉ email có thể tự do đặt giá trị mong muốn.
DKIM, SPF, DMARC
DKIM được dùng để chứng minh email thực sự đến từ domain của chính bạn, qua đó tăng độ tin cậy của thư.
Với OpenDKIM, có thể tạo cặp khóa cho từng domain và đăng ký khóa công khai dưới dạng bản ghi DNS TXT.
Khóa không tự động hết hạn, nhưng vẫn nên xoay vòng định kỳ.
Cũng cần thêm các bản ghi TXT SPF, DMARC vào DNS để chỉ định host nào được phép gửi mail và đặt chính sách DMARC (ví dụ: từ chối khi xác thực thất bại).
Trong các tệp cấu hình mẫu (opendkim.conf, KeyTable, SigningTable, TrustedHosts), có thể thấy rõ cách thiết lập từng mục.
Trong DNS, chỉ cần thêm các bản ghi liên quan đến MX, SPF, DKIM và DMARC.
Reverse DNS (PTR)
Bản ghi PTR (reverse DNS) giúp tăng độ tin cậy của máy chủ email, từ đó giảm khả năng thư bị chặn bởi các dịch vụ lớn như Gmail.
Cần liên hệ với ISP để yêu cầu cấu hình bản ghi PTR cho máy chủ mail.
Trong môi trường triển khai thực tế, dù chưa có bản ghi PTR, thư vẫn được nhận bình thường ở Gmail, GMX, Outlook..., và bài kiểm tra trên mail-tester.com đạt 10/10 điểm.
Dù bị trừ điểm vì chưa cấu hình PTR, hệ thống lại được cộng điểm nhờ "trusted relay".
IP gửi cũng có độ tin cậy tốt vì không nằm trong blacklist nào.
Kiểm thử gửi tới Gmail
Dùng lệnh sendmail để gửi email thử nghiệm (thông điệp HTML) tới Gmail.
Thư đến Gmail ngay lập tức và có thể xác nhận đã dùng mã hóa TLS.
Nếu xem thư gốc bằng "Show original", có thể thấy SPF, DKIM và DMARC đều vượt qua xác thực.
Có thể dùng mailx để kiểm tra nội dung thư nhận được ở local (trên máy chủ).
Nếu có vấn đề cấu hình, cần kiểm tra lại DNS, chứng chỉ, quyền truy cập khóa DKIM..., đặc biệt các tệp cấu hình của OpenDKIM rất nhạy với lỗi gõ sai.
Bước tiếp theo
Trong bài viết tiếp theo, tác giả dự định giới thiệu cách tạo ứng dụng email bằng Python.
Nếu có câu hỏi hay ý kiến, có thể liên hệ qua max@idx.cy.
1 bình luận
Ý kiến Hacker News
Tôi đã tự host email hơn 20 năm và cảm thấy khá tự hào về điều đó, dự định vẫn sẽ tiếp tục. Trớ trêu là chính phủ hay các cơ quan liên quan lại không thể tự vận hành hệ thống email, chỉ có cơ quan an ninh quốc gia là còn tự host. Có lẽ do may mắn, tôi hầu như không gặp vấn đề khi gửi mail; trường hợp gần đây nhất tôi nhớ là Microsoft đã nuốt mất mail của tôi, nhưng đó là do TLS giữa exim cũ và Outlook bị trục trặc. Chỉ cần chỉnh một thiết lập là xong. Việc bảo trì cũng không quá tốn công, nên mỗi lần phải đụng vào tôi xem như một dịp học cái mới. Năm nay tôi đã chuyển từ Debian jessie sang Arch Linux và chuyển toàn bộ tác vụ cron sang systemd timer. Khi gửi mail quan trọng tôi luôn kiểm tra log server, mà tôi nghĩ đây cũng là một thói quen tốt vì được tự xem log. Nếu phải đưa lời khuyên thì là: sẽ tốt hơn nhiều nếu bạn xem tự host như một thú vui và biết tận hưởng nó. Cuối cùng, người nghĩ ra cấu hình Exim trên Debian là kẻ đã khiến tôi lãng phí không ít thời gian. Nếu dựng Exim trên Debian, cách đúng là chuyển sang cấu hình Upstream chính thức rồi tùy biến theo nhu cầu của mình
Dạo này các mạng xã hội cứ khoe về “phi tập trung” hay “mở”, nhưng thật ra chúng ta đã có sẵn những công cụ để có thể hoàn toàn tự chủ một cách độc lập. Người ta hay nói đến việc cải thiện UX, nhưng lại bỏ qua thực tế là quyền kiểm soát của người dùng đang biến mất. Rốt cuộc nếu cứ quen với những hệ thống bị đơn giản hóa quá mức, rồi sẽ đến lúc trong tương lai bạn thậm chí không cài nổi một ứng dụng nếu không có ai đó ở nơi xa cho phép “giao dịch” đó
Tôi dùng email lần đầu từ thời đại học, trước cả WWW, sau đó vì tài khoản ISP chỉ có dung lượng rất hạn chế và chỉ hỗ trợ POP nên tôi chuyển sang tự chạy mail server. Khi đó tôi không phải lúc nào cũng kết nối Internet, nên nhận mail qua relay và dynamic DNS. Hiện tại tôi dùng VPS để chuyển tiếp rồi nhận và lưu mail ở server tại nhà. Trong nhiều năm, cũng có lúc tôi phải yêu cầu các dịch vụ mail lớn như Outlook gỡ chặn IP hoặc domain, nhưng không quá thường xuyên. Tôi không muốn sống trong một thế giới mà chỉ hai ba công ty thống trị toàn bộ email toàn cầu, nên tôi xem việc tự host này như một hành vi kháng cự nhỏ
Tôi chỉ ước mình còn được dù chỉ 1% động lực như 20 năm trước. Giờ thì công việc full-time và gia đình, vợ con, khiến tôi không còn thời gian cho mấy việc như vậy nữa
Tôi cũng từng tránh xa tự host, nhưng đang nghĩ biết đâu giờ lại đáng làm vì cán cân thời gian/chi phí đã thay đổi. Điều tôi băn khoăn nhất khi host email là quản lý spam. Không biết dạo này tình hình thế nào, ai có mẹo gì thì chia sẻ với
Với tôi email là một dịch vụ cực kỳ quan trọng. Tôi đã tự host 15 năm rồi dừng lại vì 1) không làm tốt được backup/restore định kỳ và giám sát, 2) không có kế hoạch khôi phục sau thảm họa nên chi phí cao hơn các dịch vụ khác, và 3) không thể lúc nào cũng chú ý đầy đủ đến bảo mật. Server của một người bạn từng dính ransomware và mất sạch dữ liệu, còn tôi thì thoát vì dùng FreeBSD, không phải mục tiêu tấn công. Nhìn chung bảo trì không quá phức tạp, nhưng một khi đã rối thì có thể rất cực, thậm chí là chí mạng
Trước đây tôi từng tự host email, nhưng bỏ không phải vì danh tiếng gửi mail mà vì không thể tránh được yêu cầu uptime 100%, dẫn đến nguy cơ mất mail hoặc bị vào blacklist. Về mặt giao thức thì email đúng là chịu được downtime, nhưng trên thực tế các nhà cung cấp email lớn chỉ cần gặp trục trặc một lần là lập tức từ chối mail và không thử lại nữa. Ngày xưa GitHub cũng vậy, chỉ cần bounce một lần là đánh dấu “không nhận được” rồi thôi không gửi nữa. Giờ thì đã đỡ hơn, nhưng hệ thống email hiện đại đang ngầm giả định là “luôn online”
Mail server của tôi cố ý dùng greylisting để từ chối mail đến lần đầu. Tôi đã nhận vô số email nhưng chưa từng có trường hợp mail hợp lệ nào bị thất lạc. Việc gửi lại đã được tích hợp trong chuẩn email, nên nếu lo thì cứ thêm một mail server nhận dự phòng rồi backhaul bằng LMTP. Bản thân hệ thống email vốn được thiết kế cho thời đại mà không phải lúc nào cũng kết nối 24 giờ mỗi ngày
Cách nói đó hơi cường điệu. Trong trường hợp của tôi, nếu mail không tới thì vài tiếng hay một ngày sau nó vẫn tới, và nhìn chung cũng chẳng có cách nào biết chính xác vấn đề nổ ra ở đâu. Chỉ cần cấu hình xác thực đúng như dkim, spf thì tự host vẫn có thể đảm bảo khả năng chuyển phát trên 99%. Không cần phải sợ độ phức tạp. Bonus là còn có thể dùng caldav riêng
Tôi không hiểu vì sao chỉ cần server down vài tiếng mà lại lo “mất mail”. Server của tôi đang uptime liên tục 219 ngày. So với những việc chúng ta thường làm thì vận hành mail server thật sự là chuyện rất dễ
Nhìn hệ thống email ngày nay thật sự có cảm giác như “người ta đã làm gì với con trai tôi thế này”
Lời khuyên cho ai muốn bắt đầu tự host email: trước tiên hãy chỉ dùng email tự host để đăng ký tài khoản. Không cần dùng ngay cho liên lạc cá nhân từ đầu. Nếu dùng “Mail-in-a-box” https://mailinabox.email./ thì chỉ cần làm theo hướng dẫn cài đặt là có thể dựng xong trong vài giờ và chạy khá ổn. Hãy dùng thử 1-2 năm, đến khi đủ quen tay rồi hẵng chuyển email liên lạc cá nhân sang
Tôi khuyên dùng Stalwart https://github.com/stalwartlabs/stalwart. Đây là dịch vụ mail hoàn chỉnh trong một binary duy nhất, không phụ thuộc gì nên cài đặt/cập nhật cực kỳ dễ. Tôi đã thử nhiều dự án khác nhưng Stalwart là thứ đơn giản nhất, và chạy không lỗi gì cả
Tôi đã vận hành MIAB trên cloud nhiều năm. Chỉ cần IP reputation sạch thì gửi mail không vấn đề gì, còn khi mail không tới Outlook thì tôi gửi trực tiếp cho Microsoft postmaster để giải quyết. Tôi khuyên dùng vì bạn sẽ học được những thứ như DKIM/SPF/DMARC. Tuy vậy, nhận email đăng ký tài khoản thật sự rất khó. Greylisting của MIAB sẽ từ chối người gửi lần đầu và chờ họ thử lại, nhưng nhiều website bình thường cũng không thử lại. Mail xác thực, mã 2FA thường đến rất chậm, mà cũng không có cách dễ để tạm tắt bộ lọc spam
Dạo này cả email do ISP cung cấp, thậm chí cả Google Gmail, cũng hay có vấn đề về lọc spam. Ví dụ: khi đặt hàng qua Shopify thì mail từ Shopify cứ liên tục bị Gmail cho vào spam. DMARC, SPF, DKIM đều pass mà vẫn bị dính, đến mức chẳng hiểu vì sao. Bản thân việc gửi/nhận email về mặt kỹ thuật không khó, và dù dùng dịch vụ nào cũng không thể hoàn hảo 100%. Người dùng xấu, tức spammer, quá nhiều, nên việc hệ thống này vẫn vận hành được tốt đến vậy đã là điều đáng ngạc nhiên rồi
DMARC, SPF, DKIM các thứ chỉ là cấu hình liên quan đến xác thực, chứ không liên quan trực tiếp đến việc có phải spam hay không. Có những mail rác được xác thực đầy đủ, và cũng có những mail quý giá lại không được xác thực
Lý do mail Shopify bị phân loại spam là vì Shopify có quá nhiều người bị đánh dấu spam, hoặc có người dùng chung mail server với reputation xấu. Dù tôi có liên tục đánh dấu là không phải spam, nếu reputation chung của bên gửi quá tệ thì nó vẫn không thoát ra được khỏi thư mục spam
Tôi đã tự host email khoảng 20 năm. Trong 10-15 năm tôi forward toàn bộ mail sang Gmail, nhưng rồi chán ngấy bộ lọc spam làm biến mất cả mail quan trọng nên bắt đầu tự chạy imapd. Chỉ cần cấu hình đúng SPF và các thứ tương tự thì tôi thấy tự host tốt hơn hẳn
Chính những chính sách lọc như vậy mới là vấn đề. Nếu tự host hoặc dùng dịch vụ email nhỏ thì khả năng mail bị chặn, nhất là bởi các bộ lọc nghiêm ngặt như của Gmail, lại thấp hơn nhiều. Google có vô số người dùng Gmail là nguồn phát spam chính nhưng vẫn cố chấp duy trì chính sách lọc gắt như vậy
Dạo này bộ lọc spam của Gmail phản ứng quá nhạy với email marketing. Mười năm trước thì vấn đề lại ngược lại, còn bây giờ quá nhiều thứ rơi vào spam đến mức phiền. Trớ trêu là phần lớn spam hiện nay lại là cold email từ các địa chỉ mail mới nhỏ lẻ. Tính năng “hủy đăng ký” của Gmail hoạt động tốt với email marketing, nhưng hoàn toàn vô dụng với kiểu cold email này
Nếu muốn một hệ thống hoàn chỉnh và một IMAP server có thể tích hợp với nhiều client khác nhau, thì hướng dẫn https://workaround.org/ispmail-bookworm/ sẽ phù hợp hơn. Tôi đang vận hành đơn giản bằng file văn bản thuần thay vì database. Nếu chỉ có mình bạn là người dùng thì làm vậy cũng ổn, còn hướng dẫn trên thì đủ khả năng mở rộng cho cả doanh nghiệp lớn
Tự quảng bá một chút: chúng tôi đang beta test Hyvor Relay https://github.com/hyvor/relay, một giải pháp thay thế self-hosted. Chúng tôi tập trung vào khả năng quan sát như giám sát DKIM/SPF và tự động hóa DNS. Chỉ cần một lần
docker compose uplà có thể đưa vào vận hành ngay https://relay.hyvor.com/hosting/deploy-easyTrong 10-15 năm qua tôi tự host email bằng opensmtp, dovecot, rspamd trên hộp kimsufi giá rẻ. Không có vấn đề gì lớn; từng có một lần server bị telekom.de chặn, nhưng tôi gửi mail giải thích đàng hoàng thì họ whitelist ngay. Có lẽ vì tôi giữ IP đó rất lâu nên cá nhân tôi không gặp những vấn đề mà ai cũng hay kể. Tuy nhiên, server và IP đều đứng tên tôi
Tôi chia sẻ bài viết tiếng Đức về tự host email dựa trên Debian trixie tại https://krei.se/Doc. Nếu tự dựng cho ra hồn thì thật sự rất vui. Tôi nhận báo cáo trạng thái hằng ngày qua mail nhờ auto update, reboot tự động và systemd tùy biến. Trong 2-3 năm, với trixie thì tối đa 5 năm, gần như không cần đụng vào mà vẫn ổn định. Phần mềm mail server đã đủ trưởng thành từ lâu rồi. Tôi khuyên nên tự host. Sự tự chủ, sự yên tâm và quyền kiểm soát trực tiếp thực sự rất đáng giá
Tôi đã tự vận hành email hơn 10 năm, và trước đây cũng thường để lại link các bình luận HN cũ của mình (ví dụ: 39891262, 38471262). Vì IP của Digital Ocean bị đánh dấu xấu nên tôi thay việc gửi mail bằng Amazon SES, đồng thời dùng Gmail như một công cụ huấn luyện spam miễn phí để cải thiện bộ lọc riêng (38843288). Như nhiều người đã nói, greylisting giúp ích rất nhiều. Mail server hợp lệ chắc chắn sẽ thử lại, nên dù bất tiện cho 2FA nhưng về mặt hệ thống nó vẫn đáng tin cậy. Dù downtime vài ngày cũng không sao, và việc tách riêng server nhận/lưu trữ cũng giúp backup dễ hơn (38512732). Với email 2FA, tôi còn dùng kèm https://github.com/stevejenkins/postwhite, nhưng thật ra tôi không muốn khuyên dùng email cho 2FA chút nào, chuyện này cần một cuộc bàn luận riêng
Gần đây tôi đã không nhận được một email quan trọng gửi qua Amazon SES vì bị chặn bởi danh sách chống spam (bl.spamcop.net). Amazon thử lại bằng nhiều IP khác nhau, gặp greylisting nên cuối cùng có một lần bị từ chối. Có thể việc gửi giữa các bên lớn với nhau, tức MX sang MX, không gặp nhiều vấn đề như vậy, nhưng cấu trúc này cũng không phải là giải pháp hoàn hảo 100%
Nói dài nói dai rồi thì có vẻ kết luận vẫn là cứ dùng Gmail hay các dịch vụ email lớn thì hơn
UUCP đâu rồi, sao địa chỉ lại không phải bang path, và sendmail.cf đâu mất rồi?
Đúng vậy. Nếu bạn định tự host theo đúng kiểu năm 1984, email cổ điển, thì bạn sẽ thành open relay chuyển tiếp toàn bộ mail và bị phơi ra trước đủ loại lỗ hổng, rất nguy hiểm
Nhắc đến thời đó, tôi nhớ hồi ở phòng nghiên cứu đại học có 6 máy trạm Unix, email được chuyển từ server này sang server khác, và mình còn có thể cảm nhận thư đang đi lại qua tiếng ổ đĩa kêu
Tôi cũng đọc tiêu đề xong liền nghĩ đến bang path và địa chỉ “killer!jolet!”. Đúng là một thời để nhớ
Đồng ý. Tôi vào vì bị tiêu đề ‘1984’ dụ, nhưng hóa ra lại chỉ là chuyện ‘cấu hình postfix’, nên hơi thất vọng