Vụ việc bí ẩn của dấu chấm bị biến mất

 (tjaart.substack.com)
1 điểm bởi GN⁺ 2024-05-22 | 2 bình luận | Chia sẻ qua WhatsApp

Bí ẩn về dấu chấm biến mất trong phần thân email

Giao thức truyền thư đơn giản nhưng không hề đơn giản

  • Tjaart
    • 20 tháng 2, 2024

Sự cố xảy ra

  • Nhận được phản ánh rằng dấu chấm đã biến mất trong phần thân email gửi cho một khách hàng.
  • Khi gửi cùng một email cho khách hàng khác thì dấu chấm không bị mất.

Nhìn lại dự án

  • Khoảng 7 năm trước, đã phát triển một giải pháp hợp nhất các mẫu tài liệu vào một hệ thống duy nhất.
  • Khách hàng sử dụng các mẫu Microsoft Word để chèn placeholder vào tài liệu.
  • Mỗi khi nhân viên gửi tài liệu qua email, cần thay thế placeholder bằng nội dung thực tế.

Vấn đề quản lý template

  • Có nhiều phiên bản template khác nhau nên rất khó quản lý.
  • Một số template vẫn dùng điều khoản, logo, phông chữ cũ, v.v.
  • Đã phát triển một giải pháp cho phép quản lý tập trung toàn bộ template.

Triển khai giải pháp

  • Khách hàng có thể quản lý tập trung các template để tạo tài liệu PDF, tin nhắn văn bản và phần thân email.
  • Ví dụ, có thể thiết lập một template thư chào mừng gửi cho khách hàng mới.
  • Có thể cấu hình template khác nhau cho từng phương thức gửi (email, tin nhắn văn bản, thư giấy).

Tái hiện vấn đề

  • Sự cố dấu chấm biến mất chỉ xảy ra trong email gửi cho một khách hàng cụ thể.
  • Trong mã nguồn template vẫn có chứa dấu chấm.
  • Khi xem trước phần thân email ở môi trường local, dấu chấm vẫn hiển thị.

Phân tích nguyên nhân

  • Khi tạo phần thân email, có đoạn mã giới hạn độ dài của từng dòng.
  • Nếu một dòng vượt quá giới hạn, hệ thống sẽ tạo dòng mới và chuyển phần nội dung còn lại sang đó.
  • Theo đặc tả SMTP, nếu một dòng bắt đầu bằng dấu chấm thì sẽ chèn thêm một dấu chấm, và server sẽ xóa dấu chấm đầu tiên.

Cách khắc phục

  • Sửa mã: nếu một dòng bắt đầu bằng dấu chấm thì chèn thêm một dấu chấm để sau khi server xóa đi, vẫn còn lại dấu chấm ban đầu.
  • Sau khi kiểm thử mã đã sửa, xác nhận rằng dấu chấm không còn bị biến mất.
  • Đã giải quyết sự cố và thông báo lỗi này cho các nhóm khác.

Vấn đề phát sinh sau đó

  • Vài tháng sau, một nhóm khác không sửa cùng lỗi này nên dấu chấm lại biến mất trong một email quan trọng.
  • Một số khách hàng nhận được email hiển thị phí hàng tháng mới là $2700 thay vì $27.00.
  • Sau khi vá mã ngay lập tức, sự cố được giải quyết.

Ý kiến của GN⁺

  1. Tầm quan trọng của việc hiểu đặc tả SMTP: Để giải quyết các vấn đề có thể phát sinh khi gửi email, cần hiểu sâu về đặc tả SMTP.
  2. Độ phức tạp của quản lý template: Việc quản lý nhiều phiên bản template có thể rất phức tạp, vì vậy cần có hệ thống quản lý tập trung.
  3. Kỹ năng debugging: Kỹ năng tái hiện vấn đề và phân tích nguyên nhân là rất quan trọng.
  4. Giao tiếp giữa các nhóm: Sau khi giải quyết vấn đề, việc chia sẻ thông tin với các nhóm khác là rất quan trọng.
  5. Kiểm thử tự động: Nên áp dụng kiểm thử tự động để ngăn những vấn đề như thế này.

Bài viết liên quan

2 bình luận

 
surfindia 2024-05-22

Có vẻ như trong tiêu đề, period đã được hiểu là khoảng thời gian chứ không phải dấu chấm haha
 
GN⁺ 2024-05-22
Ý kiến trên Hacker News

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

  • Độ khó khi triển khai SMTP client

    • Việc triển khai SMTP client khá khó, và nếu làm không đúng thì rất dễ phát sinh lỗi. Tầng template không nên phải bận tâm đến SMTP.
    • Nhiều người gặp vấn đề này vì không học giao thức cơ bản qua terminal. Quy tắc kết thúc thư bằng "một dấu chấm đơn" là rất quan trọng.
    • Nhiều lập trình viên không hiểu khái niệm escaping. Họ không tính đến trường hợp gửi email có chứa "một dấu chấm đơn".

  • Câu chuyện thư giới thiệu ở Đức

    • Ở Đức, việc nhận thư giới thiệu khi chấm dứt việc làm là chuyện phổ biến. Nếu câu cuối của thư không có dấu chấm câu, điều đó mang hàm ý tiêu cực.
    • Khi nhờ luật sư xem lại thư giới thiệu, người ta phát hiện câu cuối không có dấu chấm nên đã thành vấn đề.

  • Cron job và SMTP client

    • Một cron job gửi email không cần tự triển khai SMTP client. Có thể dùng các chương trình như mailutils.
    • Việc tự triển khai tương tác SMTP cơ bản qua socket là kém hiệu quả. Cần kết nối TLS và xác thực.
    • Bản thân cron đã có khả năng gửi email. Có thể đặt địa chỉ email bằng biến MAILTO.

  • Hai thói quen xấu

    • Không nên triển khai tiêu chuẩn một cách hời hợt. Cần đầu tư đủ sự cẩn trọng hoặc dùng thư viện có sẵn.
    • Không nên vendor dependency. Thư viện cần được cập nhật định kỳ. Nếu trì hoãn cập nhật, có thể dẫn đến vấn đề lớn.

  • Sự cần thiết của dot-stuffing

    • SMTP và POP3 đều cần dot-stuffing. Có thể tham khảo các tài liệu RFC liên quan.

  • Vấn đề với tệp đính kèm HTML MIME

    • Câu "We are happy to welcome you to our family." không vướng giới hạn độ dài dòng. Có thể đó là tệp đính kèm HTML MIME.
    • Nếu chia HTML thành các dòng một cách máy móc, thẻ có thể bị hỏng.

  • Trường hợp ký tự đầu tiên là dấu chấm

    • Nếu ký tự đầu tiên là dấu chấm và phía sau còn ký tự khác, ký tự đầu tiên sẽ bị xóa. Vì một dấu chấm đơn có nghĩa là kết thúc thư.
    • Khó hiểu vì sao lại xóa dấu chấm. Có thể giữ lại một byte để kiểm tra ký tự tiếp theo.

  • Thông báo vá lỗi

    • Vì mã SMTP client được mang sang từ dự án trước, nên đã báo lỗi này cho đội khác.
    • Có khả năng đội kia vẫn chưa vá lỗi này.

  • Kinh nghiệm triển khai NNTP server

    • Khi triển khai NNTP server dựa trên đặc tả RFC, người ta đã hiểu ngay vấn đề dot-stuffing. Đây là một giao thức từ thập niên 80.