Nhà xử lý thanh toán lớn tại châu Âu không thể gửi email cho người dùng Google Workspace

• Công ty thanh toán lớn của châu Âu Viva.com đã gửi email xác thực không có header Message-ID, khiến máy chủ Google Workspace từ chối
• Trong RFC 5322 (ban hành năm 2008), Message-ID được quy định là một header ở mức bắt buộc thực tế, và Google áp dụng điều này rất nghiêm ngặt
• Email vẫn được nhận ở địa chỉ Gmail cá nhân, cho thấy sự khác biệt trong cách xử lý giữa Google Workspace và Gmail
• Bộ phận hỗ trợ khách hàng của Viva.com không thừa nhận có vấn đề kỹ thuật, mà chỉ xác nhận kết quả sau khi người dùng tự lách qua, thể hiện cách ứng phó thiếu chuyên nghiệp
• Đây là một trường hợp không tuân thủ ngay cả RFC cơ bản, cho thấy vấn đề suy giảm chất lượng và năng lực cạnh tranh của hạ tầng fintech châu Âu

---

Vấn đề email xác thực không đến

• Trong quá trình tạo tài khoản Viva.com, email xác thực hoàn toàn không đến
  • Đã sử dụng email tên miền tùy chỉnh dựa trên Google Workspace, và không có thư nào cả trong hộp thư rác
• Kết quả Email Log Search của Google Workspace cho thấy trạng thái là “Bounced”
  • Lý do trả lại là “Messages missing a valid Message-ID header are not accepted”
  • Google đã từ chối email do vi phạm chuẩn RFC 5322
• Email gửi đi từ Viva.com bị thiếu header Message-ID, trong khi đây là mục đã được yêu cầu từ năm 2008

Cách khắc phục tạm thời

• Khi đổi sang địa chỉ @gmail.com cá nhân, email xác thực được nhận bình thường
  • Có vẻ như hạ tầng nhận thư của Gmail dễ dãi hơn hoặc xử lý theo tuyến khác
• Tuy nhiên, việc phải dùng email cá nhân để đăng ký một nền tảng thanh toán cho doanh nghiệp bị xem là có vấn đề

Phản hồi của bộ phận hỗ trợ khách hàng

• Đã gửi cho bộ phận hỗ trợ của Viva.com ảnh chụp màn hình log Google Workspace và phần mô tả vấn đề
• Đội hỗ trợ trả lời rằng “tài khoản của bạn đã có email được xác thực nên không có vấn đề gì”
  • Không có dấu hiệu nhận thức về vấn đề kỹ thuật hay chuyển tiếp cho đội ngũ kỹ sư
  • Đây là cách xử lý xem việc người dùng tự lách qua được là không còn vấn đề

Bản chất của vấn đề

• Message-ID là header cơ bản mà mọi hệ thống email thông thường đều tự tạo
  • Nếu bị thiếu, điều đó có nghĩa là pipeline gửi mail đã được cấu hình sai nghiêm trọng
• Trong RFC 5322, Message-ID được quy định là “SHOULD”, nhưng Google xem nó trên thực tế là bắt buộc (MUST)
• Do Viva.com không tuân thủ điều này, email không thể đến được với người dùng Google Workspace
• Việc một công ty xử lý thanh toán trên toàn châu Âu không tuân thủ chuẩn RFC cơ bản đặt ra nghi vấn về độ tin cậy kỹ thuật

Vấn đề mang tính cấu trúc của hạ tầng fintech châu Âu

• Trong các API và dịch vụ doanh nghiệp ở châu Âu, tình trạng tài liệu không đầy đủ, xử lý lỗi kém, hỗ trợ thiếu chuyên nghiệp lặp đi lặp lại
• Điều này được cho là không phải vấn đề năng lực kỹ sư mà là thiếu cạnh tranh thị trường và vấn đề ưu tiên
• Stripe đã đặt ra chuẩn cao về trải nghiệm nhà phát triển, nhưng lại không hỗ trợ đầy đủ mạng thanh toán khu vực châu Âu (ví dụ: IRIS), khiến lựa chọn thay thế bị hạn chế
• Nếu không xuất hiện đối thủ ở đẳng cấp như Stripe, các vấn đề chất lượng kiểu này có khả năng sẽ tiếp diễn

Đề xuất chỉnh sửa kỹ thuật

• Viva.com cần thêm header Message-ID vào email gửi đi
  • Ví dụ: Message-ID: <[e-mail]>
  • Phần lớn thư viện email tự động tạo mục này, và có thể khắc phục chỉ bằng một dòng chỉnh sửa
• Cần sửa ngay để người dùng Google Workspace có thể nhận email xác thực bình thường

Phân biệt thuật ngữ RFC và chính sách của Google

• Theo RFC 2119
  • MUST: yêu cầu tuyệt đối
  • SHOULD: chỉ có thể lược bỏ khi có lý do đặc biệt
  • MAY: hoàn toàn tùy chọn
• Lý do Message-ID là SHOULD là vì một số client ủy quyền việc này cho máy chủ
• Google áp dụng điều này như một yêu cầu mang tính bắt buộc để chống spam, qua đó đóng vai trò như một chuẩn thực tế vượt lên trên RFC
• Nếu Viva.com đã cố ý bỏ qua điều này, ít nhất họ phải cung cấp cảnh báo rằng “không tương thích với Google Workspace”
  • Vận hành mà không có bất kỳ thông báo nào cũng đi ngược lại tinh thần của quy định SHOULD

[GN⁺]

Ý kiến Hacker News

• Vấn đề được chỉ ra là email xác thực của Viva.com không có header Message-ID
  Theo mục 3.6 của RFC 5322, có câu “every message SHOULD have a Message-ID field”, nhưng vì SHOULD không phải MUST nên có người đặt câu hỏi liệu có khó coi đây là một “yêu cầu” hay không

  • Có ý kiến giải thích rằng SHOULD trên thực tế là một yêu cầu gần như bắt buộc
    Trừ khi có lý do đặc biệt thì phải tuân theo, và đơn giản chỉ là “vì lười” thì không thể được xem là ngoại lệ
    Trước đây, nếu MUA gửi mail không có Message-ID thì server sẽ tự động thêm vào, nên mới được diễn đạt bằng SHOULD
    Nội dung liên quan được nêu rõ trong mục 8.3 của RFC 6409
  • Theo RFC2119, SHOULD có nghĩa là “có thể bỏ qua trong một số tình huống cụ thể, nhưng phải hiểu đầy đủ hậu quả và cân nhắc cẩn thận”
    Người viết nói rằng họ không rõ Google đã diễn giải điều này như thế nào
  • Với tư cách là postmaster của một công ty hosting, có người nhấn mạnh rằng trong môi trường vận hành thực tế thì Message-ID là bắt buộc phải có
    Mail thử nghiệm thì còn khác, nhưng nếu mail dịch vụ thật mà thiếu nó thì sẽ gặp vấn đề ở các bộ lọc spam và những nơi khác
    Việc không có Message-ID thường là dấu hiệu của một hệ thống gửi tùy biến cẩu thả
  • Có người nói Message-ID không phải là trường bắt buộc, nhưng vẫn khó chịu vì có những dịch vụ như Amazon SES ghi đè Message-ID sẵn có
  • Về mặt kỹ thuật thì có thể không cần, nhưng nếu muốn được xem là email bình thường hợp lệ thì thực tế gần như bắt buộc
    Đặc biệt, việc một dịch vụ thanh toán lại không hề thử nghiệm với các dịch vụ mail lớn như Google Workspace bị xem là khó chấp nhận

• Một người từng làm ở ESP (Email Service Provider) cho biết phần lớn phần mềm server đều từ chối mail không có Message-ID
  Họ nói thật khó tưởng tượng việc bỏ qua các bounce đến từ những bên nhận lớn như Google

  • Trên thực tế, việc ngăn vấn đề cho người dùng quan trọng hơn so với bám đúng tiêu chuẩn
    Dù hệ thống đối tác có vô lý đi nữa thì vẫn nên thích nghi để tránh gây bất tiện cho người dùng
  • Nếu muốn gửi mail tới Google Workspace thì Message-ID trên thực tế là MUST
    Nếu không muốn thêm nó thì nên ghi rõ là “không hỗ trợ người dùng Google Workspace”
  • Tuy vậy, phần lớn doanh nghiệp không quan tâm tới những chi tiết kỹ thuật như vậy, mà chỉ có thái độ “miễn chạy được càng sớm càng tốt”
    Họ cho rằng cả Viva lẫn Google đều quá lớn nên sẽ không để tâm tới vấn đề của một phần khách hàng
  • Cũng có người chỉ ra rằng vì tập trung vào doanh nghiệp châu Âu nên tỷ trọng Google Workspace có thể không quá lớn

• Cũng có nhiều lời phàn nàn về các dịch vụ gửi phần thay thế text/plain của email một cách cẩu thả
  Có trường hợp bản text không có link, hoặc chỉ gửi những nội dung vô dụng kiểu “đây là email plain text”

  • Có người nói khó chịu nhất là bản plain text chỉ hiện lên một câu chữ dễ thương trong thông báo
    Họ còn đùa rằng cần một tính năng để email client dùng AI tóm tắt HTML
  • Có dịch vụ từng gửi cả thông tin đặt chỗ của khách hàng khác trong phần plain text (trường hợp Avis)
  • Có người từng thấy cách triển khai tạo text/plain bằng cách dump HTML qua trình duyệt Lynx, và tự hỏi liệu cách đó có thực sự có giá trị hay không
  • Cũng có trường hợp phần text/plain chứa nguyên mã HTML hoặc CSS

• Cũng có bình luận châm biếm về sự kém cỏi về kỹ thuật của các tổ chức tài chính
  “Major European Payment Processor” được diễn đạt thành “Major European Incompetence Center”

  • Một người khác nói rằng nghe có vẻ cường điệu, nhưng thực tế họ từng thấy mức độ bảo mật của các tổ chức tài chính tệ hại đến vậy
    Ví dụ, Harland Financial Systems dùng mã hóa XOR 2 byte và gửi khóa ở dạng plain text ngay đầu kết nối
  • Một người khác nữa nhắc tới các vụ bê bối tham nhũng ở tổ chức tài chính Mỹ (phê duyệt sai, mở tài khoản trái phép, v.v.) rồi hỏi liệu ở châu Âu có tương tự không

• Một người dùng chuyển từ Gmail sang Fastmail cho biết họ phần nào đồng cảm với việc Google lọc spam rất nghiêm ngặt
  Trên Fastmail, spam và mail phishing lọt vào nhiều hơn

  • Người khác nói Message-ID thực tế là chuẩn ngành cho mail tự động, nên phản ứng của Google không phải là quá đáng
    Cũng có trường hợp startup dùng nguyên template mặc định rồi bị hiểu nhầm là phishing
  • Có lời khuyên rằng bộ lọc spam của Fastmail sẽ học dần theo thời gian và trở nên tốt hơn
  • Một người dùng Fastmail lâu năm đùa rằng thỉnh thoảng spam vẫn lọt, nhưng chỉ có mail LinkedIn là luôn vượt qua được
  • Có ý kiến nói Fastmail đôi lúc phản ứng chậm với spam theo từng giai đoạn, nhưng nhìn chung vẫn hài lòng

• Theo RFC thì Viva.com là bên sai, nhưng cũng có ý kiến cho rằng Google từ chối mail chỉ vì một mục SHOULD là không phù hợp
  Dù vậy, nếu xác suất spam cao thì nên đưa vào thư rác thay vì từ chối hẳn

  • Có người chỉ ra thực tế là đội hỗ trợ khách hàng không chuyển vấn đề lên đội kỹ thuật mà chỉ lặp lại các câu trả lời mang tính hình thức
  • Cũng có người chia sẻ kinh nghiệm nội bộ rằng ở vị trí nhân viên hỗ trợ, nếu thừa nhận vấn đề thì sẽ bị ảnh hưởng đánh giá hiệu suất, nên họ cũng khó làm khác
  • Có ý kiến mỉa mai rằng tiêu chuẩn email trên thực tế không bao giờ vận hành hoàn hảo, và mọi quy tắc rốt cuộc đều chỉ ở mức “SHOULD”

• Có người nhấn mạnh rằng điều nghiêm trọng nhất là Viva.com thậm chí còn không kiểm thử vấn đề gửi mail với Google Workspace

  • Họ châm biếm rằng trên thực tế công ty đang “kiểm thử thời gian thực” thông qua việc người dùng thất bại khi đăng ký
    Vấn đề có thể do thay đổi từ phía Google, nhưng thiếu giám sát mới là vấn đề lớn hơn
  • Cũng có phản biện rằng đâu phải mọi công ty trên thế giới đều dùng Google Workspace

• Có người đặt câu hỏi Viva.com đã không nhận ra vấn đề này trong bao lâu
  Họ nói nếu dùng phần mềm mail thông thường thì có lẽ sự cố này đã không xảy ra, và nhắc tới khả năng cấu hình sai
  SHOULD không phải MAY, và nếu không triển khai thì phải chấp nhận rủi ro phát sinh
  Việc Google đưa luôn nguyên nhân trong thông báo lỗi thậm chí còn được xem là may mắn

• Có người giải thích rằng Message-ID vốn là một trường bắt buộc bắt nguồn từ Usenet,
  và cần thiết cho threading, trả lời và lưu trữ của email
  Việc thiếu Message-ID bị xem như mang ý nghĩa “không muốn ai trả lời cũng không muốn để lại dấu vết”, nên trông rất đáng ngờ

• Đáp lại bài viết gốc chỉ trích chất lượng API của doanh nghiệp châu Âu,
  có người nói đây không phải vấn đề riêng của khu vực nào mà là một mô thức chung của startup và tổ chức tài chính trên toàn thế giới
  Doanh nghiệp lớn thường xem API là việc phụ, hoặc miễn cưỡng vận hành chỉ để đáp ứng quy định
  Trong khi đó, những công ty như Stripe có API chất lượng cao vì đó là huyết mạch sống còn của họ
  Còn startup do thiếu nguồn lực nên buộc phải ưu tiên “API chạy được” hơn là “API dễ dùng”