- Mối quan tâm chính là quy trình lưu trữ và quản lý nhãn cho email Internet của những người dùng đăng ký nhiều mailing list và xem xét nhiều bản vá
- Đặc biệt là câu hỏi dành cho những người dùng Lobsters đã tham gia 20 mailing list và những người xem xét nhiều bản vá
- Xác nhận xem có quy trình cụ thể nào để xử lý việc lưu trữ và nhãn hay không
- Hỏi về những công cụ đã giúp ích rất nhiều, kèm điều kiện nếu có thể thì ưu tiên công cụ FOSS
- Ví dụ cụ thể là có sử dụng các công cụ như script Sieve hay không
1 bình luận
Ý kiến trên Lobste.rs
Rất thích Sieve
Roundcube còn có plugin cho phép chỉnh sửa Sieve bằng GUI trong WebUI, nên rất tiện để làm quen với các tính năng của ngôn ngữ Sieve, và nếu cần thì vẫn có thể tự sửa trực tiếp file script
Thường đăng ký ở mỗi trang bằng địa chỉ email theo từng tên miền để dễ lọc, ví dụ như
lobsters@example.comKhông dùng mailing list, nhưng nếu có thử thì chắc sẽ tạo một hộp thư đến cho từng list, rồi nhóm theo thread trong mail client và chỉ hiển thị các thư chưa đọc
Với spam, chỉ cần các quy tắc cơ bản như kiểm tra xem trong nội dung có cụm như "my salacious friend" hay không, và từ chối các hộp thư chung kiểu
info@, cũng đã đủ dùng hơn 6 năm nay; chỉ có 6 quy tắc thủ công nên với nhu cầu cá nhân, không thấy lý do gì để đầu tư vào giải pháp machine learning như rspamdThỉnh thoảng có đổi mail client, nhưng quy trình lấy về-lọc thư thì gần như giữ nguyên suốt nhiều năm
Hiện tại đang đánh giá Gnus sau thời gian dài dùng mutt; dùng mpop để lấy thư từ máy chủ của nhà cung cấp dịch vụ mail, pipe sang maildrop, rồi lưu vào một trong nhiều thư mục
maildirtrong thư mục mail cục bộThư sẽ vào thư mục nào là do một script lớn tên
.mailfilterquyết định, còn mailing list thì chủ yếu được match bằng headerList-Id. Trong nhiều năm đăng ký list, chưa từng thấy mailing list nào không đặt header RFC2919 nàyThư cá nhân thì phần lớn được lọc bằng header
From, còn spam thì nhà cung cấp xử lý quá tốt nên không có quy tắc riêng nào; mỗi năm chỉ vài lần lọt vào inbox thì xóa tayCách này gần như giống hệt workflow cổ điển dựa trên
procmail, chỉ là dùngmaildropthay choprocmail. Khi đó từng đọc rằngprocmailkhông còn được bảo trì nên đi tìm phương án thay thế, và chọnmaildrop, vốn là một phần của Courier MTA nhưng cũng có thể dùng độc lậpƯu điểm của kho thư cục bộ dựa trên
maildirlà có thể gắn nhiều mail client nhẹ, hay theo thuật ngữ email là MUA, vào cùng một cấu trúc thư mụcmaildirmà không gặp vấn đề gìCấu hình này rất đáng hài lòng và đã chứng minh tính hữu dụng suốt nhiều năm. Điều đáng lo nhất lúc này là xu hướng các nhà cung cấp mail chỉ mở giao diện webmail mà không còn cung cấp cả POP3 hay IMAP nữa. Ở chỗ làm hiện tại thì trận này đã thua rồi: dùng MS Exchange on-premise và cách duy nhất để đọc mail là webmail, thật kinh khủng
Webmail, Outlook, hoặc không có gì cả. Việc họ chủ động chọn không cho phép client khác, bất kể mức độ hỗ trợ ra sao, khiến điều đó giống như một sự xúc phạm đối với chính phương tiện email
Có thể nói rằng “nếu đủ nhiều người dùng thì rồi họ cũng sẽ phải hỗ trợ các email client khác”, nhưng đó chính là vấn đề. Phải có khả năng dùng những cách tốt hơn webmail và Outlook
Trước đây từng tự vận hành mail server và IMAP server, bạn bè còn host MX dự phòng giúp, nhưng cuối cùng đã chuyển sang Fastmail để đơn giản hóa cuộc sống
Sắp xếp thư bằng script Sieve và Sieve thông qua “filters and rules” của Fastmail, rồi dùng isync/mbsync để kéo về
maildirtrên thiết bị cá nhânCuối tháng sẽ tự dọn dẹp thủ công, còn các thư mục có ít mail thì cứ 6 tháng một lần hoặc mỗi năm sẽ lưu trữ thành
archive/<folder>-YYYYMM. Phần archive cũng được đồng bộ cục bộ và sao lưu toàn bộ, nhưng vẫn chưa có cách nào tốt cho patch reviewTự vận hành mail server cho tới năm 2020, rồi bỏ cuộc vì lượng spam đầu vào liên tục thay đổi và đăng ký Fastmail
Nói một cách ưu ái thì Fastmail giống như một phiên bản Squirrelmail hào nhoáng hơn. Đã dùng tính năng Mail filtering của họ để lọc kiểu gửi một số người nhận nhất định vào các thư mục
Bất kể nhà cung cấp nào, vẫn dùng một cấu trúc lưu trữ đơn giản có thể dễ dàng nạp vào bất kỳ mail client nào. Cách làm là có một thư mục cho mỗi năm, như 2025, 2024, 2023, và trong mỗi thư mục có khoảng một nghìn email
Khi năm mới bắt đầu, sẽ chuyển thư của năm 2026 trong thư mục Archive sang thư mục 2026 mới. Khi cần tìm mail, chỉ nhìn thư mục cũng có thể đoán được nó nằm trong vòng 1 năm hay từ 8 năm trước, nên dễ tìm hơn
Dùng cả imapfilter và imap_tools
Dùng theo thứ tự Postfix → spfpolicyd → https://github.com/fazalmajid/gtldmilter → Procmail
Biết là nên dùng Sieve. Trong những trường hợp đặc biệt, cũng từng viết trình xử lý email tùy biến như https://github.com/Dirac-Software/mailsink
Giống như Cal Newport nói, email không có cấu trúc thì không nên dùng cho các workflow lặp đi lặp lại; rất ghét các workflow dựa trên email nên tránh chúng. Vì vậy nhìn chung khá đồng cảm với mục tiêu của SourceHut, nhưng chưa cân nhắc dùng
Trước đây dùng procmail rồi chuyển sang Sieve, và vài năm gần đây dùng script gắn thẻ notmuch
Phần gắn thẻ này mới thực sự mạnh. Có thể tạm thời gắn tag cho thread mà vẫn giữ nguyên các tag còn lại, và xem mail theo nhiều cách khác nhau tùy vào việc muốn làm gì hoặc muốn tìm gì
Kết hợp thêm miền email catchall, rồi đăng ký từng list và dịch vụ bằng địa chỉ riêng, thì việc lọc và gắn thẻ trở nên cực kỳ dễ dàng
Hơi là một câu hỏi phụ, nhưng tôi tò mò mọi người dùng gì cho máy chủ gửi thư
Hiện tại tôi đang tự vận hành máy chủ mail trên DigitalOcean và cũng đã cấu hình DKIM/SPF/DMARC, nhưng việc chuyển phát thư vẫn hơi thiếu ổn định
Tôi muốn trả tiền cho một nơi như Proton Mail để dùng làm relay, nên cần được gợi ý
Trước đây ở đây đã từng có thảo luận về email setups, nên có thể bạn sẽ tìm được một hai gợi ý trong đó
Ngay trước khi tôi từ bỏ hoàn toàn việc tự host máy chủ email, tôi từng xem Roundcube để cố tạo trải nghiệm tốt hơn, nhưng rồi phát hiện Fastmail và buông hết
Họ không làm đủ để tránh bọn spammer nên danh tiếng khá tệ. Tôi thích Panix; mặc định họ chặn cổng gửi đi 25 nhưng sẽ mở nếu bạn yêu cầu, và nếu là khách hàng thì bạn cũng có thể dùng máy chủ gửi thư của họ làm relay. Tôi chưa từng gặp vấn đề chuyển phát nào
Như đã được nói, DigitalOcean không phải là lựa chọn tốt để chạy máy chủ mail
Trước đây tôi đã viết một script Sieve đơn giản để đưa các email có header
List-IDvào thư mục riêng của chúng. Nếu thư mục chưa tồn tại thì nó sẽ được tạo: https://gist.github.com/epilys/bf190ffb0147aa5ab863f7fa886a27daĐiểm trừ là giá trị
List-IDcủa một số newsletter là những chuỗi khó đọc với con người, kiểu như UUIDTôi dùng Thunderbird
Việc lưu trữ thì tính năng archive sẵn có là đủ. Theo tôi biết, nó lưu email thành các tệp văn bản trên đĩa. Bạn có thể cấu hình cách lưu trữ như thư mục theo năm hoặc theo năm+tháng
Ban đầu tôi cũng làm vậy, nhưng cuối cùng quyết định để kho lưu trữ phản chiếu nguyên cấu trúc thư mục của tài khoản email
Với mailing list thì header
List-Idlà tốt nhất. Tôi dùng nó để đưa thư vào một thư mục cụ thể. Về nhãn, Thunderbird có hỗ trợ tag nhưng tôi không dùng, chỉ thư mục đích là đủTôi không review patch qua email nhiều, nhưng cũng từng dùng thử SourceHut một chút, nơi coi quy trình qua email là tính năng hạng nhất
Thunderbird có hệ thống lọc phía máy khách riêng, và vì máy chính của tôi về cơ bản luôn bật nên nó khá phù hợp. Theo thời gian, tôi đã tích lũy vài chục bộ lọc để chuyển thư dựa trên domain, thường là top-level domain, hoặc header
List-Idcủa danh sách emailTuy vậy, câu chuyện đồng bộ của Thunderbird gần như không tồn tại ở mọi mặt: archive, thư, cài đặt, bộ lọc, gần như mọi thứ
Họ đang làm việc trên đó, nhưng lần cuối tôi kiểm tra thì họ tập trung vào việc hiện đại hóa và hợp nhất phần backend codebase — sản phẩm của hơn 20 năm kiểu kỹ nghệ miền Viễn Tây. Mỗi người đóng góp lại tạo ra cách riêng với SQLite, plain text, tệp JSON, cơ sở dữ liệu mork, v.v., nên chỉ biết chúc may mắn thôi :D