Tự host email theo cách khó: bắt đầu từ một khối IPv4 có thể tự định tuyến

 (anil.recoil.org)
1 điểm bởi GN⁺ 15 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Hạ tầng mail Recoil vận hành từ năm 1997 đã được làm mới thành một stack tự host, tự xử lý trực tiếp việc nhận, gửi và truy cập bằng cách kết hợp khối IPv4 /24 chuyên dụng, Postfix, Dovecot, rspamd, Roundcube và nhiều thành phần khác
  • Tự vận hành mail mang lại quyền truy cập dữ liệu và giá trị học hỏi, nhưng trên nền SMTP vốn yếu về mô hình tin cậy, người vận hành phải tự quản lý uy tín IP, bản ghi DNS và phòng chống spam
  • Đường nhận thư đi qua postscreen, DNSBL, greylisting, ClamAV, lọc Bayesian, LMTP và Sieve, tạo thành cấu trúc giảm dần lưu lượng bot và thư độc hại theo từng lớp
  • Độ tin cậy khi gửi phụ thuộc vào SPF, DKIM, DMARC và SRS; nếu cấu hình sai, thư có thể bị các bên nhận như Gmail hay Outlook đánh dấu spam hoặc âm thầm loại bỏ
  • Việc tự host email vào năm 2026 vẫn khả thi, nhưng cần phòng thủ nhiều lớp để đối phó với việc giành được IPv4, nhiều bản ghi DNS, cập nhật bảo mật và các hình thức khai thác lỗ hổng có hỗ trợ AI

Vì sao tự vận hành email

  • Tự vận hành máy chủ là một trải nghiệm giáo dục để học về hệ thống và mạng, đồng thời là con đường hiểu cách Internet hoạt động và tham gia vào mã nguồn mở
  • Trong bối cảnh web ngày càng tập trung vào một số ít nhà cung cấp, tự host là cách duy trì quyền truy cập có chủ quyền đối với dữ liệu của chính mình
  • Một phân tích năm 2023 cho rằng các chủ thể có thể đọc lưu lượng email rốt cuộc phần lớn quy về Google và Microsoft
  • Email gắn với việc đặt lại mật khẩu của nhiều tài khoản trực tuyến, nên chiếm đoạt tài khoản hoặc phishing có thể làm lung lay cả quyền truy cập sang các dịch vụ khác
  • Tự vận hành mail đòi hỏi quản trị dài hạn, cùng với môi trường hosting Internet ổn định hơn mạng gia đình và quá trình tích lũy uy tín

Kiến trúc nhận email

  • Tên miền Internet chỉ định máy chủ SMTP nhận thư bằng bản ghi MX DNS, và với recoil.org thì pork.recoil.org xử lý thư
  • SMTP khởi nguồn từ thiết kế mang tính tin cậy cao hơn của thập niên 1980, nên về mặc định không chứng minh được danh tính người gửi; người gửi của thư đến có thể bị giả mạo dễ dàng
  • Phản ứng của IETF phát triển theo hướng chồng nhiều lớp kiểm tra danh tính, và nếu cấu hình sai các kiểm tra này thì độ tin cậy chuyển phát thư sẽ giảm
  • Danh sách chặn dựa trên DNS tổng hợp thông tin về botnet, máy chủ bị xâm nhập và spammer, cho phép mail server truy vấn RBL để lọc IP đáng ngờ
  • Uy tín email được tích lũy theo địa chỉ IP chứ không phải tên miền, nên địa chỉ tái sử dụng trên cloud hoặc các IP hàng xóm trong cùng khối có thể ảnh hưởng đến uy tín

  • Có được khối IPv4 chuyên dụng và định tuyến nó

    • Recoil đã có được khối địa chỉ IPv4 chuyên dụng 185.33.27.0/24, nhờ đó có thể tự xây dựng uy tín mail một cách độc lập
    • RIPE NCC đã cạn không gian IPv4 chưa phân bổ vào tháng 11/2019, sau đó việc cấp phát trực tiếp được xử lý thông qua danh sách chờ cho các khối /24 nhỏ
    • Khối /24 được cấp sau khoảng 6 tháng chờ; để tự đăng ký ở châu Âu cần trả phí thành viên RIPE NCC và mở tài khoản LIR
    • Khối IPv4 được cấp phát sẽ tạo RPKI ROA để chỉ định quyền định tuyến, và khối của Recoil được nối vào Mythic Beasts AS44684
    • Reverse DNS cũng có thể tự kiểm soát; 185.33.27.128 được ánh xạ tới pork.recoil.org và trở thành một tín hiệu uy tín email

Phòng thủ trước bot và spam

  • Chỉ có một khối IPv4 sạch là chưa đủ; phần lớn các kết nối TCP đi vào cổng 25 là để phát tán spam, dò open relay, đoán thông tin xác thực hoặc thu thập dữ liệu huấn luyện AI
  • Postfix postscreen đứng trước cổng 25 để thực hiện truy vấn DNSBL song song, trì hoãn pre-greet, và kiểm tra pipelining cũng như lệnh không phải SMTP
  • postscreen chỉ chuyển các client trông hợp lệ sang smtpd thực sự; các client lỗi bị ngắt bằng thất bại tạm thời để các trường hợp dương tính giả còn có thể thử lại
  • Các danh sách Spamhaus, Spamcop và Barracuda được kết hợp theo trọng số; cấu hình từ chối khi chỉ Spamhaus đánh dấu hoặc khi có đồng thời hai danh sách yếu hơn cùng đánh dấu
  • Pool MX gửi thư của Apple iCloud không thử lại từ cùng một IP nên không khớp với cơ chế allowlist của postscreen; vì vậy cấu hình cho phép ưu tiên toàn bộ 17.0.0.0/8 để bỏ qua

  • Greylisting và kiểm tra nội dung

    • Greylisting trả về thất bại tạm thời cho nguồn gửi lần đầu, rồi cho qua nếu MTA hợp lệ thử lại sau vài phút
    • Botnet dùng một lần thường chuyển sang mục tiêu tiếp theo sau khi thất bại, nhờ đó có thể phân biệt với bên gửi hợp lệ có duy trì hàng đợi thử lại
    • Sau khi vượt qua postscreen và greylisting, hơn 99% lưu lượng bot ban đầu bị chặn với chi phí CPU thấp
    • rspamd kiểm tra mọi thông điệp qua giao thức milter, và thay vì chấp nhận rồi bounce thư đáng ngờ, nó từ chối hoặc trì hoãn ngay khi máy chủ gửi vẫn còn kết nối
    • ClamAV quét tệp đính kèm chứa virus đã biết để từ chối ngay thư bị nhiễm; bộ phân loại Bayesian của rspamd chấm điểm thông điệp dựa trên tập ngữ liệu spam và ham lưu trong Redis

Chuyển phát cục bộ, lưu trữ và lọc

  • Thư đến sau khi đi qua postscreen, greylisting, rspamd, ClamAV và bộ phân loại Bayesian sẽ được chuyển cho Dovecot
  • Thay vì để Postfix ghi trực tiếp vào thư mục home của người dùng, nó chuyển qua LMTP cho Dovecot để đảm nhiệm việc lập chỉ mục, quota, tìm kiếm toàn văn và lọc Sieve
  • virtual_alias_maps chuyển đổi các địa chỉ như anything@recoil.org thành địa chỉ có thể chuyển phát cục bộ
  • Định dạng lưu trữ là Maildir được dùng từ năm 1998, lưu mỗi email thành một tệp riêng dưới ~/Maildir của người dùng
  • Maildir dùng ba thư mục con tmp/, new/, cur/ cùng thao tác đổi tên nguyên tử của POSIX để chuyển thư mới mà không phải khóa toàn bộ mailbox

  • Chỉ mục tìm kiếm và Sieve

    • Dù cũng đã cân nhắc các mail server hiện đại như Stalwart, chúng không hỗ trợ Maildir và yêu cầu lưu trữ trên cơ sở dữ liệu tùy biến như RocksDB, nên không chuyển đổi
    • Dovecot tách biệt lưu trữ Maildir và hiệu năng tìm kiếm thông qua Flatcurve, một chỉ mục toàn văn riêng
    • Flatcurve là một wrapper của Xapian, đặt chỉ mục Xapian theo từng mailbox dưới ~/Maildir/fts-flatcurve và tự động cập nhật khi có thư mới
    • Sieve là ngôn ngữ khai báo chuyên cho lọc mail, và plugin Pigeonhole Sieve của Dovecot chạy bộ lọc người dùng tại thời điểm phát thư
    • Script Sieve toàn hệ thống chuyển thư được rspamd đánh dấu sang Junk, còn script theo từng người dùng xử lý phân loại thư mục, quy tắc nghỉ phép, độ ưu tiên, chỉnh sửa header và hơn thế nữa

Gửi email đáng tin cậy

  • Để gửi thư ổn định, xác thực khi gửi quan trọng không kém phòng thủ khi nhận; chỉ cần trượt một trong các kiểm tra của bên nhận lớn là thư có thể vào thư rác hoặc bị loại bỏ âm thầm
  • SPF là bản ghi DNS TXT ở đỉnh tên miền, khai báo những địa chỉ IP nào được phép nhận là người gửi @recoil.org
  • SPF của Recoil là v=spf1 a mx -all, nghĩa là chỉ pork.recoil.org mà MX của recoil.org trỏ tới mới được xem là người gửi hợp lệ
  • Trên máy có nhiều IP, Postfix được buộc vào địa chỉ gửi cụ thể bằng smtp_bind_address và smtp_bind_address6 để kernel không chọn ngẫu nhiên địa chỉ nguồn
  • DKIM gắn chữ ký mật mã lên phần thân thư và các header được chuẩn hóa, còn khóa xác minh công khai được đặt trong DNS tại <selector>._domainkey.<domain>

  • DMARC và SRS

    • DMARC kiểm tra xem tên miền đã được xác thực bởi SPF và DKIM có khớp với header From: mà người dùng nhìn thấy hay không, đồng thời cho bên nhận biết cách xử lý khi thất bại
    • Chính sách DMARC của Recoil là p=quarantine, và nó nhận báo cáo tổng hợp qua địa chỉ rua= để debug các vấn đề về khả năng chuyển phát
    • Các bên nhận lớn gửi báo cáo XML tóm tắt khoảng mỗi ngày một lần về các thông điệp tự nhận là từ recoil.org, bao gồm Google, Microsoft, Yahoo, Fastmail và các bên khác
    • Thư chuyển tiếp có thể khiến tên miền người gửi gốc xuất hiện như thể được gửi từ IP của Recoil, làm SPF thất bại
    • SRS viết lại địa chỉ phong bì người gửi thành dạng như SRS0=…=example.com=original@recoil.org, để kiểm tra SPF ở đích được đánh giá theo tên miền Recoil

Truy cập người dùng và webmail

  • Người dùng có thể kết nối đến máy chủ Dovecot bằng các client IMAP thông thường, hoặc mở webmail tự host trong trình duyệt để truy cập thư
  • Dovecot xử lý truy cập mailbox trên pork và mã hóa listener bằng TLS để thư hay mật khẩu dạng văn bản thuần không đi qua mạng công cộng
  • Chứng chỉ dùng LetsEncrypt, và nhiều bí danh máy chủ như imap.recoil.org, smtp.recoil.org được cung cấp qua SNI
  • Dovecot cũng đóng vai trò backend SASL cho Postfix, cho phép người dùng dùng cùng một mật khẩu cho truy cập IMAP và gửi SMTP
  • Roundcube chạy như dịch vụ Docker Compose phía sau reverse proxy TLS Caddy, và kết nối tới pork qua TLS/IMAP như một client thông thường

  • Plugin Roundcube

    • Plugin managesieve của Roundcube dùng giao thức ManageSieve để cho phép chỉnh sửa bộ lọc Sieve trong trình duyệt
    • Plugin markasjunk biến nút “Junk” trong webmail thành thao tác chuyển sang thư mục Junk, và việc di chuyển này âm thầm kích hoạt huấn luyện phân loại ham/spam
    • Giao diện ManageSieve của Roundcube không phơi bày DSL Sieve thô

Việc còn lại và ý nghĩa của tự host

  • Cấu hình hiện tại đã khá vững cho việc sử dụng hằng ngày trong vài tuần gần đây, nhưng vẫn còn nhiều việc phải làm
  • recoil.org kết hợp các bản ghi DNS như MX, A/AAAA, PTR, SPF TXT, DKIM TXT và DMARC TXT để cấu thành việc nhận, gửi và xác minh email
  • MTA-STS cho các mail server khác biết chỉ giao tiếp qua TLS với chứng chỉ hợp lệ, giúp giảm thiểu tấn công hạ cấp STARTTLS
  • DANE/TLSA dùng hash chứng chỉ TLS được ghim trong DNS thay vì HTTPS, nhưng cần DNS zone được ký bằng DNSSEC nên vẫn chưa được triển khai
  • SRS đã được triển khai một phần nhưng chưa được xác minh trên mọi đường chuyển tiếp, và các lỗi liên quan đến INRIA là mối lo vì có thể dẫn đến thất bại DMARC và ảnh hưởng uy tín tên miền

  • JMAP, bảo mật và tương lai của tự host

    • JMAP là giao thức truy cập mail dùng HTTPS và JSON, phù hợp với client mạng hiện đại hơn IMAP
    • Dovecot không hỗ trợ JMAP gốc, còn các JMAP server độc lập được đánh giá thì từ bỏ Maildir và yêu cầu kho lưu trữ mailbox riêng
    • Kế hoạch đang được cân nhắc là đặt một triển khai JMAP bằng OCaml làm proxy dịch phía trước Dovecot, ánh xạ yêu cầu JMAP sang lời gọi IMAP rồi trả về phản hồi JSON
    • Để vận hành mail server vào năm 2026, tối thiểu phải cấu hình chính xác sáu bản ghi DNS, và việc có được một khối IPv4 từ RIPE gần như mất tới một năm
    • Khoảng thời gian giữa lúc công bố CVE và lúc exploit thực tế được tung vào các listener SMTP/IMAP giờ đây có thể được đo bằng giờ thay vì tuần, nên cần phòng thủ nhiều lớp như cố định địa chỉ cụ thể, cô lập container webmail, greylisting và DNSBL

Bài viết liên quan

1 bình luận

 
GN⁺ 15 giờ trước
Ý kiến trên Lobste.rs

  • Tôi cứ tiếp tục thấy những người gác cổng khẳng định rằng điều đã được làm suốt hàng chục năm là bất khả thi
    Thực tế, tôi vẫn nói rằng chỉ cần cấu hình reverse DNS, SPF, DMARC và MTA-STS là đủ, chi phí cũng không cao và cũng không khó
    Máy chủ thư ví dụ: https://poofydoof.zia.io/

    • Tôi đã tự vận hành email tự host từ khoảng năm 2008, vậy mà vẫn có nhiều người nói chuyện đó là không thể, điều này làm tôi khá ngạc nhiên
      Hiện tại tôi dùng tổ hợp Debian + Postfix, Dovecot, rspamd, và Google Workspace ở chỗ làm của tôi còn gặp sự cố thường xuyên hơn cấu hình của tôi
    • Tôi nghĩ điểm mấu chốt nằm ở cụm “đã làm suốt hàng chục năm”
      Câu nói chỉ cần cấu hình reverse DNS, SPF, DMARC và MTA-STS là đủ thì đúng 100% với tên miền và địa chỉ IP đã có uy tín tốt
      Nếu thêm một tên miền mới vào máy chủ thư vốn đã được các nhà cung cấp lớn tin cậy, uy tín sẽ tích lũy nhanh; và nếu chuyển một tên miền hiện có sang IP máy chủ thư mới đồng thời cấu hình cả DKIM thì cũng ổn
      Nhưng tôi nghe nói rằng nếu bắt đầu từ đầu với tên miền mới và IP máy chủ thư mới thì tình hình khá khác, và rất có thể thư sẽ bị tự động đánh dấu là spam cho đến khi hệ thống machine learning của các nhà cung cấp lớn thấy hài lòng
      Có vẻ cách thường hiệu quả là người dùng của các hệ thống đó gửi thư tới tên miền của mình rồi lấy thư trả lời ra khỏi thư mục spam
    • Theo kinh nghiệm vận hành máy chủ thư khoảng 3 năm của tôi, phần khó không phải là cấu hình DNS, SPF, DMARC hay MTA-STS, mà là tránh bị các blocklist giáng đòn khi gửi email giao dịch, và chuyện không thể được đưa vào allowlist của một số nhà cung cấp email
      Thay vì tốn thời gian liên tục đuổi theo những chuyện đó, tôi nghĩ trả khoảng 5 USD mỗi tháng để giao cho người khác làm thì tốt hơn
    • Máy chủ thư ví dụ trông rất tuyệt, và cái này cũng hay
      https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
      Tôi muốn biết thêm chi tiết về cấu hình này
      Có vẻ Mango Pi MQ-Pro hơi khó mua, nên tôi cũng muốn biết có thiết bị siêu rẻ nào khác hỗ trợ NetBSD/Linux tốt không

  • Một lý do khác để tự vận hành máy chủ thư là bạn có thể phát hiện ra rằng ai đó đã gửi spam bằng chính tên miền của bạn
    Khi một trong các tên miền của tôi được chuyển sang Squarespace vì vụ bán Google Domains, Squarespace đã tự động thêm các bản ghi DNS MX/SPF/DKIM cho Mailgun dù tôi không hề có tài khoản Mailgun
    Ai đó đã chiếm tài khoản đó trên Mailgun và gửi spam cho tôi như thể được gửi từ tên miền của tôi
    Cảm ơn nhé, Google

  • Phần phân bổ IPv4 đặc biệt thú vị
    Ở châu Âu, bài viết nói rằng để tự làm thì phải trả phí thường niên RIPE NCC và mở tài khoản local internet registry (LIR), mà theo https://www.ripe.net/membership/payment/ thì là 1800 euro mỗi năm
    Khá đau ví, nhưng nếu rẻ hơn thì có lẽ spamer sẽ càng dễ lạm dụng hơn

    • Không hề rẻ, nhưng tính ra chỉ khoảng 12 bảng mỗi địa chỉ mỗi năm, nên nếu chia sẻ cho bạn bè và gia đình trong khu vực thì cũng không đến nỗi tệ
      Niềm vui khi viết một máy chủ BGP bằng OCaml thì không gì định giá nổi :-)

  • Tôi tò mò liệu có thể dùng IPv6 một cách thực tế cho việc gửi và nhận email hay không

    • Câu hỏi hay
      Tôi đã xem xét khi viết bài, nhưng vì vài năm trước tôi đã tắt IPv6 trên máy chủ thư của mình nên quyết định để sau, đến khi có thêm kinh nghiệm
      Theo https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters, các nhà cung cấp email như Gmail, Microsoft và Yahoo dùng các bộ lọc spam riêng với trọng số khác nhau cho uy tín tên miền và uy tín IP, và hỗ trợ IPv6 cũng vẫn đang tiếp tục hoàn thiện
      Gmail yêu cầu thư qua IPv6 phải có bản ghi PTR hợp lệ, SPF, DKIM, và cũng rất khuyến khích dùng DMARC
      Nếu không có các yếu tố đó, thư gửi qua IPv6 thường sẽ vào thư mục spam hoặc bị trì hoãn
      Hệ thống lọc của Microsoft có đưa IPv6 vào các chương trình SNDS và JMRP, nhưng nếu uy tín của bên gửi chưa được biết đến thì thư IPv6 có thể bị hạn chế hoặc trì hoãn
      Rốt cuộc IPv6 lại là thêm một điểm có thể hỏng nữa, và có lẽ cấu hình miền gửi hỗn hợp IPv4/IPv6 ngay từ đầu không phải là ý hay
      Tôi vẫn chưa tìm được endpoint SMTP chỉ dùng IPv6 nào cả