Suy nghĩ công khai về email thế hệ thứ hai

Note: Bài viết này chỉ đơn giản là sắp xếp lại suy nghĩ của tôi. Tôi chưa suy nghĩ quá sâu về nó, và cũng không cần phải coi đây là một ý tưởng hay. Hãy hạ kỳ vọng xuống mức thấp nhất trước khi đọc.

Vấn đề của email

• Nhiều công nghệ cũ vẫn đang được sử dụng, nhưng email khiến tôi khó chịu gần như mỗi lần dùng.
• Từ góc nhìn người dùng, email hoạt động khá tốt. Thỉnh thoảng spam khiến số lượng email bị gửi đi quá nhiều, nhưng email thì lâu đời, đáng tin cậy, dễ hiểu và cũng tương đối dễ tìm kiếm.
• Tuy nhiên, backend của email là một mớ hỗn độn.

Các vấn đề của backend email

• Nhiều tính năng của email không có đặc tả rõ ràng. Ví dụ, khi gửi trả lời, không có gì quy định rõ là phải viết phần trả lời ở đầu hay ở cuối thư.
• Cũng không rõ email được phép chứa loại HTML nào. Microsoft Outlook đôi khi lạm dụng bộ dựng HTML của Microsoft Word.
• Cách mã hóa email cũng không rõ ràng. Người ta đã tạo ra OpenPGP, nhưng nó hầu như không được dùng và có những khiếm khuyết lớn.
• Tính xác thực của email vốn không phải lúc nào cũng kiểm tra được. Vì thế người ta tạo ra SPF, nhưng SPF cũng không giải quyết được mọi vấn đề. Rồi người ta tạo ra DKIM, nhưng DKIM cũng không giải quyết được mọi vấn đề. Sau đó là DMARC, nhưng vì bản thân DKIM có những lỗ hổng lớn nên DMARC cũng bị vượt qua.
• Người ta lại thêm một lớp khác là BIMI, nhưng nó cũng phụ thuộc vào DMARC, mà DMARC lại phụ thuộc vào DKIM, còn DKIM thì có khuyết điểm.
• Ngay cả khi có DMARC, 68.2% bản ghi vẫn được đặt là p=none. Điều đó có nghĩa là DMARC về cơ bản không làm gì cả.
• Tất cả những điều trên, cùng với các chính sách chống spam quá gắt, khiến việc tự host email trở nên rất khó khăn.
• Cuối cùng là quản lý danh tiếng IP. Một số địa chỉ IP “sạch” hơn những địa chỉ khác, đặc biệt trong các hệ thống dùng chung như SendGrid hay AWS SES. Điều này khiến việc đăng ký tài khoản gửi thư hàng loạt trở nên phức tạp và thường làm các email hợp lệ bị xếp vào spam.

Giả thuyết về email thế hệ thứ hai

• Tạo một bản ghi DNS mới là MX2. Phần lớn dịch vụ email sẽ có cả bản ghi MX2 lẫn MX. Các dịch vụ cũ chỉ có MX.
• Nếu một ứng dụng email cũ 20 năm muốn gửi thư, nó sẽ tra bản ghi MX rồi gửi thư. Còn client hiện đại sẽ nhìn vào MX2 và gửi thư theo đó.
• Các dịch vụ email triển khai MX2 sẽ công bố một ngày hiệu lực, và sau ngày đó, mọi thư gửi tới qua bản ghi MX sẽ tự động bị phân loại là spam.

Các ưu tiên của email thế hệ thứ hai

1. Cung cấp một đặc tả HTML chuẩn hóa cho email cùng với bộ test kiểm tra tính tương thích.
2. Cung cấp header cho tùy chọn chuỗi email hoặc các tùy chọn khác liên quan đến email.
3. Cung cấp một bản sao thuần văn bản, không phải HTML, đi kèm với phần hiển thị HTML.
4. Mọi bản ghi MX2 đều phải chứa khóa công khai.
5. Tạo hàm băm để xác minh tính xác thực và toàn vẹn của email, sau đó mã hóa nó và thêm vào header.
6. Loại bỏ SPF, DKIM, DMARC và chuẩn hóa vào một bản ghi MX2 duy nhất để đơn giản hóa stack email tự host.
7. Xác thực email theo domain thay vì theo địa chỉ IP.
8. Các client triển khai MX2 có thể chọn một sơ đồ mã hóa mới để thay thế OpenPGP.

Một số suy nghĩ thêm

• Cần có cách để chia sẻ các tệp dung lượng lớn.
• Nếu Google và Microsoft không tham gia thì MX2 sẽ không bao giờ thành hiện thực.
• Cũng có thể cân nhắc thay SMTP bằng HTTP với REST API chuẩn hóa và phần thân JSON.
• Việc dùng HTML tự nó cũng có thể gây tranh cãi. Email ban đầu không được thiết kế cho HTML.
• Có cơ hội để thực thi tiêu chuẩn mới một cách nghiêm ngặt.

Ý kiến của GN⁺

• Nỗ lực giải quyết độ phức tạp và các vấn đề bảo mật của hệ thống email là rất thú vị. Đặc biệt, việc đề xuất một cách mới để bảo đảm tính xác thực và toàn vẹn của email có thể sẽ hữu ích.
• Tuy nhiên, việc đưa vào một tiêu chuẩn mới là cực kỳ khó. Đặc biệt, sự tham gia của các bên lớn như Google và Microsoft là điều bắt buộc.
• Tranh cãi quanh việc sử dụng HTML vẫn còn tồn tại. Có thể cần cân nhắc một ngôn ngữ đánh dấu khác để giải quyết các vấn đề bảo mật.
• Việc thực thi nghiêm ngặt một tiêu chuẩn mới là điều lý tưởng, nhưng trên thực tế có thể rất khó. Cần thêm các cơ chế để ngăn tiêu chuẩn bị lệch dần và tránh lỗi triển khai.
• Việc hệ thống email ngày càng tập trung hóa có thể giúp ích cho việc đưa vào tiêu chuẩn mới, nhưng đồng thời cũng có thể làm tăng mức độ phụ thuộc vào một số công ty nhất định.

[cometkim]

Ít nhất về mặt cải thiện khả năng hiển thị, Google và Microsoft đã đầu tư từ trước rồi... vì cả hai đều tham gia và hỗ trợ dự án AMP Email.

[coremaker]

Việc tạo ra một tiêu chuẩn dữ liệu như JSON thì tốt.
Nhưng vì còn phải bàn cả về đặc tả render nữa nên có lẽ sẽ không dễ.

Có phải lý do người ta chọn HTML
cũng là để tận dụng miễn phí đặc tả render của HTML+CSS hay không?

[ldmsys]

Như các bác ở trên đã nêu ví dụ cực đoan là Shop Mail rồi. Cá nhân tôi khá hoài nghi về chính việc công khai xếp một giao thức vốn đang vận hành tốt vào loại deprecated, rồi chỉ làm cho tương thích với một tiêu chuẩn giao thức mới nào đó không tương thích.

[unsure4000]

4. Mọi bản ghi MX2 phải bao gồm khóa công khai.
   Điều này hơi khó hiểu, vì có vẻ như các nhà cung cấp dịch vụ sẽ dùng khóa công khai do chính họ tạo ra thay vì khóa công khai do người dùng gửi lên...

[iolothebard]

Vì vậy chúng tôi đã tạo ra một email rác… (Hử? Không phải cái đó…)

[xguru]

Hệ thống email đúng là tiện và tốt, nhưng tôi thực sự nghĩ rằng cần có những cải tiến dần dần cho giao thức.
Việc tiếp tục dùng theo cách này thêm vài chục năm nữa thì có vẻ hơi...

[GN⁺]

Ý kiến trên Hacker News

Tóm tắt các bình luận trên Hacker News

• Độ phức tạp và khả năng tương tác của hệ thống email

  • Dựa trên kinh nghiệm vận hành dịch vụ email Internet, hệ thống email tuy phức tạp nhưng đã được chấp nhận rộng rãi và có khả năng tương tác rất tốt.
  • Việc đưa vào một hệ thống mới gặp khó khăn vì phải cạnh tranh với khoản đầu tư R&D khổng lồ của hệ thống hiện tại.
  • Nếu muốn đề xuất một hệ thống email mới, nên đưa ra tại những nơi như IETF hoặc M3AAWG.

• Tính mơ hồ và các vấn đề của email

  • Header email có thể gây nhầm lẫn do các giá trị bị trùng lặp hoặc mâu thuẫn với nhau.
  • Tồn tại nhiều vấn đề khác nhau, chẳng hạn như trường hợp header vốn chỉ được phép dùng ASCII nhưng lại chứa giá trị 8-bit.
  • Cách quản lý luồng hội thoại email cũng chưa được tiêu chuẩn hóa, nên gây ra vấn đề.

• Vấn đề tập trung hóa của email

  • Việc email bị tập trung hóa là điều không mong muốn. Các công ty rất có thể sẽ hành động theo hướng có lợi cho họ chứ không phải tốt nhất cho nhân loại.
  • Tự host email không hẳn là khó, và cũng có thể dễ dàng host thông qua nhà cung cấp đáng tin cậy.

• Vấn đề của email HTML

  • Email HTML có thể dẫn đến các vấn đề như phishing và lừa đảo.
  • Nếu thiết kế lại email, có ý kiến cho rằng nên loại bỏ HTML và dùng định dạng như Markdown.

• Cần duy trì tính bất đồng bộ của email

  • Email cần phải giữ tính bất đồng bộ, vì đây là tuyến phòng thủ kỹ thuật cuối cùng giúp ngăn việc phải làm việc 24/7.
  • Đây cũng là lý do khiến mọi người không chuyển sang các hệ thống được cho là tốt hơn.

• Khó khăn trong vận hành máy chủ email

  • Việc vận hành máy chủ email ngày càng khó khăn hơn vì phải đáp ứng các yêu cầu từ những nhà cung cấp lớn.
  • Các máy chủ nhỏ đang dần bị đào thải bởi các nhà cung cấp lớn hoặc những kẻ gửi spam.

• Định nghĩa về email hợp lệ

  • Định nghĩa thế nào là email hợp lệ mang tính chủ quan. Spam đang làm hỏng Internet, và cần có cách áp chi phí để ngăn chặn điều đó.

• Sự cần thiết phải cải thiện hệ thống email

  • Dù có thiết kế lại hệ thống email, vẫn nên cải thiện trong khi duy trì hệ thống email hiện tại.
  • Cần đưa vào các hệ thống mã hóa hiện đại và hệ thống xác thực người gửi.

• Checklist ý tưởng chống spam

  • Cần một số điều chỉnh trong triển khai để chống spam.
  • Mail forwarder và máy chủ SMTP nên chuyển tiếp càng sớm càng tốt, còn lọc spam thì nên từ chối ở cấp độ SMTP.

Checklist ý tưởng chống spam