Tương lai của email
(fastmail.com)- Trong môi trường nơi AI đọc hộp thư đến, tóm tắt và thậm chí thực hiện tác vụ, xác minh người gửi trở thành điều kiện cốt lõi của độ tin cậy email
- SPF, DKIM và DMARC kết hợp quyền của máy chủ, tính toàn vẹn của thông điệp và chính sách xử lý khi thất bại để tạo thành cấu trúc cơ bản của xác thực email
- Khi bộ lọc AI và công cụ hỗ trợ AI trở thành tính năng tiêu chuẩn của trải nghiệm email, kết quả xác thực trở thành đầu vào quan trọng cho việc đánh giá spam, lừa đảo và tác vụ tự động
- Khi Google và Yahoo yêu cầu các bên gửi số lượng lớn phải cấu hình DMARC từ đầu năm 2024, hạ tầng xác thực trở thành điều kiện tiên quyết cơ bản cho việc gửi đến ổn định
- Xác thực xác minh danh tính tên miền nhưng không đảm bảo được ý đồ, và trong môi trường email tự động hóa, nó có vai trò làm tăng chi phí và độ phức tạp của hành vi mạo danh
Xác thực email: tầng tin cậy mà tương lai của email phụ thuộc vào
- Email từ lâu đã gặp vấn đề giả mạo, khi bất kỳ ai cũng có thể điền bất cứ thứ gì vào trường “From” của email
- Trước đây, người dùng cẩn thận có thể nhận ra vấn đề từ các dấu hiệu như tên miền hơi khác, mức độ khẩn cấp phi thực tế hoặc cách diễn đạt gượng gạo
- Khi việc sử dụng AI trở nên phổ biến, cách người dùng xử lý email đang thay đổi, và việc có thể thực sự xác minh nguồn gốc trở nên quan trọng hơn việc chỉ biết thông điệp đã đến hay chưa
- Những tiêu chuẩn mà đa số người dùng email chưa từng phải nghĩ tới đang âm thầm trở thành nền tảng của trải nghiệm email
Xác thực email là gì
- Xác thực email gồm ba tiêu chuẩn liên kết với nhau: SPF, DKIM và DMARC
- SPF kiểm tra xem máy chủ gửi thông điệp có quyền gửi thay mặt cho tên miền đó hay không
- DKIM gắn chữ ký mật mã vào từng thông điệp để máy chủ nhận có thể kiểm tra xem nội dung có bị thay đổi trong quá trình truyền hay không
- DMARC gắn kết SPF và DKIM, đồng thời chỉ dẫn cho máy chủ nhận rằng nên từ chối, cách ly hay cho qua những thông điệp không vượt qua kiểm tra
- Ba tiêu chuẩn này cho phép hộp thư đến đánh giá liệu một thông điệp trông như được gửi từ ngân hàng hoặc nhà tuyển dụng có thực sự đến từ tên miền đó hay không
- Nếu không có xác thực, không thể phân biệt giữa thông điệp giả mạo và thông điệp hợp lệ, và vấn đề này ngày càng lớn khi cách con người tương tác với email thay đổi
Cách AI tham gia vào email
- Có hai loại AI đang trở thành tính năng tiêu chuẩn trong trải nghiệm email
- Thứ nhất là lọc bằng AI, dùng để xác định thư rác, lừa đảo và các thông điệp đáng chú ý
- Các hệ thống như vậy đã tồn tại nhiều năm, nhưng phiên bản hiện đại mạnh hơn rất nhiều
- Kết quả xác thực ngày càng trở thành đầu vào cốt lõi khi bộ lọc AI đưa ra quyết định
- Thứ hai là công cụ hỗ trợ AI có thể tóm tắt hộp thư đến, làm nổi bật các mục công việc, tạo nháp trả lời và trong một số trường hợp còn hành động thay người dùng
- Fastmail không tích hợp AI vào hộp thư đến và thư của người dùng không bị mô hình xử lý ngầm ở hậu trường
- Máy chủ MCP là một điểm cuối API có thể kết nối với ứng dụng khách AI do người dùng chọn nếu người dùng cấp quyền rõ ràng
- Nếu người dùng không kết nối, sẽ không có gì thay đổi
- Trong hệ sinh thái email rộng lớn hơn, các công cụ hỗ trợ AI hành động tự chủ trong hộp thư đến đang ngày càng trở nên phổ biến
- Khi một người đọc email đáng ngờ, họ có thể nhận ra rằng tên miền người gửi có thêm ký tự hoặc yêu cầu nghe không tự nhiên
- Công cụ hỗ trợ AI có thể tìm các mục cần hành động, đọc nội dung và mức độ khẩn cấp rồi hành động tương ứng
- Với một thông điệp giả mạo đủ thuyết phục, xác thực phải ngăn chặn nó trước khi email đến được hộp thư đến
Xác thực đang trở thành hạ tầng
- Google và Yahoo bắt đầu yêu cầu các bên gửi số lượng lớn phải cấu hình DMARC đúng cách từ đầu năm 2024 nếu muốn gửi email ổn định
- Thay đổi này biến xác thực từ một hạng mục mà bên gửi có thể hạ thấp ưu tiên thành điều kiện tiên quyết để đến được hộp thư đến
- Xác thực email đang đi theo con đường tương tự như HTTPS trên web
- HTTPS đã đi từ thông lệ tốt thành điều được kỳ vọng, rồi trở thành hạ tầng
- Dù người dùng có thể không biết chính xác biểu tượng ổ khóa trên thanh địa chỉ trình duyệt có nghĩa gì, việc một trang web không có ổ khóa vẫn là tín hiệu cảnh báo không thể bỏ qua
- Các tiêu chuẩn mới đang được xây dựng trên nền tảng xác thực này
- BIMI cho phép người gửi đã được xác minh hiển thị logo trực tiếp trong các hộp thư đến được hỗ trợ
- Đây trở thành một tín hiệu tin cậy trực quan nhỏ nhưng hữu ích vào thời điểm ngày càng khó nhận ra lừa đảo do AI tạo ra chỉ từ nội dung
- Thiết kế của DKIM đang được xem xét lại dựa trên những bài học rút ra từ đặc tả ARC mang tính thử nghiệm
- Điều này giúp theo dõi và quy trách nhiệm cho các thay đổi trong các luồng email phức tạp để hệ thống lọc có thể xác định nguồn gốc của nội dung độc hại
- Nó cũng giúp tránh làm tổn hại danh tiếng của sai chủ thể
Chỉ xác thực thôi là chưa đủ
- Xác thực xác minh danh tính tên miền, nhưng không xác minh ý đồ
- Một kẻ lừa đảo với tên miền tương tự rất thuyết phục và bản ghi DMARC được cấu hình đúng vẫn có thể vượt qua kiểm tra xác thực người gửi
- Xác thực làm tăng đáng kể chi phí và độ phức tạp của việc mạo danh, và điều này càng quan trọng hơn khi tương lai của email ngày càng tự động hóa hơn
- Hộp thư đến trong tương lai sẽ nhanh hơn, thông minh hơn và có nhiều chức năng hơn so với thứ mà đa số người dùng hiện nay đang sử dụng
- Xác thực là yếu tố giúp tương lai đó không chỉ thuận tiện mà còn đáng tin cậy
- Các tiêu chuẩn này đã trưởng thành trong nhiều năm, và khi email tiếp tục tự động hóa, cần tiếp tục xây dựng trên nền tảng đó
Email sẽ không biến mất
- Ai cũng cần email: ngân hàng gửi sao kê, bác sĩ gửi thông tin lịch hẹn và các trang web khác gửi liên kết đặt lại mật khẩu
- Ai cũng có email
- Chỉ dấu tốt nhất cho tuổi thọ của một công nghệ là nó đã tồn tại bao lâu, và email đã tồn tại rất lâu
- Fastmail đang ở tuyến đầu của việc phát triển các tiêu chuẩn sẽ hỗ trợ email của tương lai, và sẽ tiếp tục cùng email tiến hóa để tạo ra trải nghiệm email tốt hơn cho tất cả mọi người
1 bình luận
Ý kiến trên Hacker News
Khó đánh giá việc này thực sự sẽ hữu ích đến đâu, nhưng tôi hoan nghênh hướng đi làm email an toàn hơn để các tổ chức, đặc biệt là ngân hàng, chính phủ và công ty bảo hiểm, không phải tạo ra các lựa chọn thay thế kiểu hộp thư bảo mật khép kín nữa
Họ bảo “hãy đăng nhập vào trung tâm tin nhắn bảo mật”, rồi ở đó chỉ xem được những tin nhắn trình bày cẩu thả trong thời gian ngắn trước khi bị xóa vĩnh viễn
Hộp thư đến của tôi ở mức nào đó là một bản ghi về cuộc đời có thể tìm kiếm được, còn những lựa chọn thay thế đó thì phá vỡ điều ấy
Ví dụ, công ty bảo hiểm phải tuân theo HIPAA, và thông tin liên quan đến sức khỏe chỉ có thể được gửi tới những hệ thống khác cũng tuân thủ HIPAA
Để làm được vậy, họ phải ký một hợp đồng gọi là BAA với hệ thống đó, mà với email thì điều này về mặt thực tế là bất khả thi
Công ty bảo hiểm không thể ký hợp đồng với mọi email host trên toàn thế giới, và cũng không thể biết chính xác email sau khi gửi cuối cùng sẽ đến đâu
Việc phân biệt chính xác giữa email có chứa thông tin sức khỏe và email không chứa cũng rất khó, ngay cả tên người hay địa chỉ IP tùy theo ngữ cảnh cũng có thể được tính là như vậy
Vì thế họ mặc định gửi mọi thứ vào trung tâm tin nhắn, và dù bảo mật email có tốt lên đến đâu thì phần này cũng khó thay đổi
Nó nên là cơ chế phê duyệt trước người gửi giống như thêm bạn trên mạng xã hội
Tôi từng thấy phòng khám y tế xóa các tin nhắn có thể khiến họ bất lợi trước tòa
Vì thế tôi bảo những người gửi kiểu đó hãy gửi bằng email thật sự
Rồi họ cũng gửi email riêng nữa, khiến thỉnh thoảng tôi lại đăng nhập lần nữa vì tưởng là một tin nhắn khác
Còn có nút “tải tin nhắn này dưới dạng PDF”, nhưng thực ra chỉ chuyển sang một lớp bọc web browser mà thôi
Họ bảo khoảng tuần sau sẽ tới
Chắc hẳn có đủ loại lý do tuân thủ quy định, nhưng tôi vẫn thấy hoàn toàn vô lý
Tôi đọc bài đến cuối và thấy ngạc nhiên. Toàn bộ bài như thể là phần dẫn nhập cho một thông báo hay điều gì đó mới mẻ, nhưng rốt cuộc chẳng có gì cả
Có thể là do tôi chậm hiểu, nhưng vì vậy tôi không biết kết luận cốt lõi là gì
Mỗi lần công ty bắt đầu nói về một tương lai tươi sáng thì thường có nghĩa là trải nghiệm người dùng của tôi sắp tệ đi
Nhưng thực ra chỉ là “giờ phải vượt qua DMARC”, mà điều đó đã là sự thật từ 2 năm trước rồi
Nội dung nói xác thực giúp ngăn domain giả mạo thì đúng, nhưng tôi cho rằng đó không phải vấn đề lớn nhất
Kẻ tấn công tìm ra cách khiến các nền tảng thanh toán như PayPal, Stripe gửi email
Sau khi nắm được loại thông tin nào sẽ được đưa vào email được tạo ra, chúng đặt tên công ty kiểu “có vấn đề rồi, hãy gọi số này”
Khi đó trong tiêu đề hoặc nội dung email hợp lệ thực sự đến từ PayPal sẽ có tên công ty đó, khiến nó trông khẩn cấp
Những email như vậy được gửi từ công ty thật và vượt qua mọi xác thực, nên DMARC không thể chặn được, và gần đây tôi đang thấy đúng kiểu tấn công này
Tôi đã thực sự hy vọng Fastmail sẽ đưa ra thứ gì đó để xử lý vấn đề này
Tóm lại chỉ có vậy. Đại loại là tôi không biết làm sao để đến đó, nhưng email sẽ nhanh hơn và thông minh hơn
Thành thật mà nói, tôi tự hỏi vì sao bài này được đăng và được upvote
Tôi thích Fastmail. Tôi đã chuyển từ Proton sang vài năm trước vì thấy những đánh đổi của email mã hóa không đáng giá đến thế
Dù có tin tưởng Proton hoàn toàn thì phần lớn email rốt cuộc vẫn đi qua AWS, Outlook, Gmail
Tôi rất hài lòng với dịch vụ Fastmail. Giá hợp lý, chạy rất nhanh ngay cả với hộp thư lớn, và không thêm các tính năng thừa hay sự cồng kềnh
Ban đầu tôi định dùng ứng dụng mail mặc định của hệ điều hành, nhưng ứng dụng và website của Fastmail tốt đến mức tôi cứ dùng luôn chúng
Trí nhớ cơ bắp tích lũy suốt 30 năm dùng webmail của tôi trở nên vô dụng vì cái “ứng dụng” này
Có vẻ như một lập trình viên web muốn đóng giả nhà phát triển ứng dụng desktop
Đây không phải tai nạn; họ nói đó là lựa chọn có chủ đích khi không thêm phím tắt quay về trang trước
Nhân viên hỗ trợ khách hàng nói sẽ thêm nó thành một “yêu cầu tính năng”
Về cơ bản chúng ta đang thuê ngoài việc phán đoán email cho AI, đồng thời cố bù lại bằng cách siết SPF/DKIM chặt hơn
Cảm giác như đang làm ổ khóa chắc hơn nhưng lại phát thêm nhiều chìa vạn năng hơn
Không thể nói như thể Fastmail có thẩm quyền tuyệt đối về email
Vì Fastmail không phải bản thân email, mà là một dịch vụ phụ thuộc vào email
Chừng nào chưa thể di chuyển hộp thư đến và định tuyến nó sang nhà cung cấp mình muốn, các hệ thống xác thực kiểu này dường như khó có giá trị thực sự ở quy mô lớn
Nếu có thể chuyển số điện thoại thì về lý thuyết cũng phải có thể chuyển địa chỉ email
Các hệ thống xác thực được nói đến ở đây không giúp đủ nhiều để làm cho tính di động đó khả thi
Bất kể dùng nhà cung cấp nào, cần có một cách hợp lệ để xác thực chính con người chứ không phải tên miền email
Tức là cần phát triển một tiêu chuẩn có thể ký thay cho chính nhà cung cấp hosting
Việc đến năm 2026 mà chữ ký và mã hóa vẫn chưa trở thành mặc định cho email thì thật vô lý
Nhưng chừng nào mô hình kinh doanh của các nhà cung cấp email lớn còn phụ thuộc vào việc chúng ta không dùng chúng, có lẽ mọi thứ vẫn sẽ như vậy
Muốn biến hộp thư đến thành thứ thực sự hữu dụng thì phải chạy đủ loại xử lý machine learning, mà muốn vậy thì email không được mã hóa
Nếu không thì Microsoft đã khó lòng chia sẻ dữ liệu Outlook với 1000 đối tác hơn nhiều
Email mã hóa nghe có vẻ thuyết phục, nhưng nếu xét các mối đe dọa thực tế thì nó không bảo vệ thêm được bao nhiêu so với hiện trạng, trong khi lại mất đi rất nhiều tính năng
Ngay từ giả định cơ bản, email đã được mã hóa từ máy tính của tôi đến máy chủ mail, từ máy chủ mail của tôi đến máy chủ mail của người nhận, rồi từ máy chủ mail của người nhận đến máy tính của họ
Ngoài tôi và người nhận, các bên có thể nhìn thấy chỉ là những máy chủ mail ở giữa, và điều tốt nhất mà email mã hóa có thể đạt được cũng chỉ là loại bớt một vài chủ thể đang đóng vai trò cốt lõi trong quá trình này
Đặc biệt, header email vẫn tiếp tục lộ ra ngoài, nên ngay cả trong trường hợp tốt nhất thì đây cũng không phải một kênh liên lạc thật sự riêng tư
Trong khi đó, email mã hóa lại phá vỡ các xử lý như bộ lọc phía máy chủ. Chống spam cũng vậy, nhất là khi nghĩ đến lượng spam khổng lồ còn không bao giờ tới được cả thư mục spam thì gần như không có lời giải thực tế
Người dùng kỳ vọng có thể đăng nhập webmail và đọc thư ngay, và webmail là ứng dụng email thống trị hiện nay
Nếu giải quyết chuyện này bằng cách đưa khóa cho máy chủ, thì máy chủ lại một lần nữa trở thành bên có thể đọc email, và rốt cuộc cũng chẳng khác gì hiện trạng
Vấn đề lớn hơn là phân phối khóa. Muốn gửi thư thì phải tìm được khóa của người nhận, mà ở quy mô lớn cách thực tế nhất là hỏi máy chủ mail xin khóa công khai của người dùng
Nhưng chính máy chủ đó lại là chủ thể duy nhất có thể chặn mọi thông điệp gửi đến người dùng ấy, nên nó có thể đưa ra khóa của chính nó, gỡ mã hóa rồi mã hóa lại cho người dùng mà rất khó bị phát hiện
Những phương án thay thế như máy chủ khóa PGP cũng không hiệu quả. Ngay cả vào thời kỳ số người quan tâm đến mã hóa PGP còn chưa tới một triệu, hệ sinh thái máy chủ khóa PGP đã sụp đổ từ vài năm trước, nên hoàn toàn không thể so với quy mô hàng tỷ người dùng email
Email mã hóa, theo tôi, không chỉ thất bại vì mô hình kinh doanh của các công ty email, mà gần như là một giấc mơ khó khả thi vì kiến trúc email vốn đã đem lại mức bảo mật đủ ổn, khiến lợi ích bổ sung từ mã hóa rất khó phát huy
Đó phải là một hệ thống có trải nghiệm người dùng tốt và khả năng mã hóa xuất sắc
Bài viết có nhắc đến đề xuất ARC thất bại, vốn nhằm tránh để DKIM bị hỏng trong quá trình chuyển tiếp email
https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...
Sẽ rất thú vị nếu Google có thể được thuyết phục để chuyển khỏi ARC sang một cách tiếp cận khác
Dạo này Gmail coi trọng uy tín của máy chủ email đến mức có thể đối xử tệ một cách ổn định với những máy chủ mail mà họ không thích
“Thứ hai là hỗ trợ AI. Các công cụ tóm tắt hộp thư đến, hiện các mục cần hành động, soạn nháp câu trả lời, và trong một số trường hợp còn hành động thay cho người dùng”
Đây là phần tà ác nhất. Cuối cùng sẽ thành cảnh bot nói chuyện với bot, còn con người bị gạt ra ngoài
Mọi vấn đề của email đều có thể giải quyết bằng GPG, nhưng như thế thì hoạt động kinh doanh của các dịch vụ email như Fastmail sẽ sụp đổ
Bởi họ sẽ không thể đọc và phân tích email của người dùng, không thể quảng cáo, không thể bán hồ sơ người dùng cho các công ty quảng cáo, cũng không thể dùng dữ liệu người dùng để huấn luyện AI
Tương lai của email mà tôi muốn thấy là theo hướng đó. Đáng tiếc là chẳng ai dùng GPG, và cũng khá khó để dạy mọi người dùng nó
Cách duy nhất để chứng minh giao tiếp là thật sẽ là trao đổi khóa trước mặt nhau từ trước
GPG chỉ là một trong những con đường đó, rồi sẽ có ai đó nghĩ ra cách làm dễ dàng ở cấp độ tổ chức
Với phân tích thì metadata còn có giá trị hơn cả nội dung thông điệp. GPG giải quyết chuyện đó như thế nào?
Tôi đã hy vọng bài này nói về JMAP
Không phải mã hóa phần thân, nhưng nó cho thấy môi trường email mặc định vẫn còn chỗ để cải thiện
Thật khó chịu khi trong một dự án sở thích, dù tuân thủ mọi quy tắc và thêm đúng các header thì vẫn không thể gửi email
Tôi đọc khá thích bài viết của jeremyevans về tự lưu trữ email, nhưng nó chỉ nói về nhận thư chứ không bàn đến gửi thư
https://code.jeremyevans.net/2021-07-29-running-my-own-email...