Giả sử nhóm của bạn phát hành một email đặt lại mật khẩu mới. QA duyệt trên staging: thư xuất hiện, liên kết chạy, mẫu thư đẹp. Hai ngày sau khi phát hành, bộ phận hỗ trợ có cả hàng đợi phiếu yêu cầu. Người dùng địa chỉ Gmail nói thư không bao giờ đến. Người ở vài công ty lớn nói thư có đến, nhưng liên kết báo "đã được dùng" ngay lần bấm đầu tiên. Giữa staging và production không ai đổi mã, và mọi bài kiểm thử vẫn đều qua.
Vậy địa chỉ email thử nghiệm nào dành cho lập trình viên sẽ bắt được lỗi này? Không có địa chỉ nào làm được một mình. Một bộ bắt SMTP cục bộ hợp với phát triển hằng ngày, môi trường sandbox của nhà cung cấp hoặc một tên miền thử nghiệm do bạn kiểm soát hợp với kiểm thử tự động, và một hộp thư bên ngoài thật hợp với bước kiểm tra thủ công xem thư có rời khỏi môi trường giống production của bạn và đến được tên miền của một người lạ hay không. Một hộp thư tạm thời như VookMail đảm nhận trường hợp cuối này mà không cần cài đặt, vì địa chỉ có sẵn ngay khi trang tải xong. Các tài khoản mồi tại những nhà cung cấp hộp thư lớn rồi sẽ lo phần mà không cách nào trong số đó nhìn thấy. Phần còn lại của hướng dẫn nói về cách chọn giữa các lựa chọn đó, cách đọc lỗi khi chúng xảy ra, và những việc cần kiểm tra trong mỗi lần phát hành.
Vì sao email đặt lại mật khẩu đó qua được staging
Staging và production hiếm khi giống nhau như sơ đồ triển khai gợi ý, và email lộ ra sự khác biệt rõ hơn hầu hết các tính năng khác. Một thư đi qua ứng dụng của bạn, một hàng đợi, một nhà cung cấp, DNS, máy chủ của người nhận và ứng dụng của người nhận. Staging có thể dùng một phiên bản khác của gần như tất cả những thứ đó.
Hãy xem phiếu đầu tiên, những người dùng Gmail không nhận được gì. Giả sử staging gửi qua một tên miền con của nhà cung cấp đã được xác thực từ nhiều tháng trước, còn production gửi từ một tên miền From mới đưa vào cùng đợt đổi thương hiệu. Hướng dẫn dành cho người gửi của Google yêu cầu mọi người gửi phải xác thực bằng SPF hoặc DKIM, và bảng lỗi của Gmail ghi 5.7.26 cho thư không được xác thực. Một hộp thư QA nội bộ trên tên miền của chính bạn có thể cho thư đó qua, vì máy chủ của bạn có thể tin relay của chính bạn. Bài kiểm thử không bao giờ có thể thất bại.
Phiếu thứ hai, liên kết "đã được dùng", có nguyên nhân khác. Các cổng bảo mật của doanh nghiệp thường mở liên kết trong thư đến để quét trước khi người nhận nhìn thấy. Nếu liên kết của bạn đổi token bằng một yêu cầu GET thông thường, trình quét sẽ dùng hết nó, và nhân viên bấm vào một liên kết đã chết. Không hộp thư staging nào của bạn chạy trình quét đó, trừ khi công ty bạn tình cờ dùng một cái.
Hai lỗi này không thể thấy từ cùng một chỗ. Một lỗi cần gửi thật đến một hệ thống nhận mà bạn không vận hành. Lỗi kia cần thay đổi cách liên kết hoạt động, điều mà đọc lại mã dễ bắt hơn một bài kiểm thử. Đó là lý do cho việc kiểm thử theo lớp: mỗi loại địa chỉ trả lời một câu hỏi và im lặng với những câu còn lại.
| Thường khác nhau giữa staging và production | Điều nó có thể che giấu |
|---|---|
Tên miền gửi và địa chỉ From | SPF và DKIM thiếu hoặc không khớp |
| Tài khoản hoặc tài khoản phụ của nhà cung cấp | Chế độ sandbox, giới hạn gửi, danh tiếng IP khác |
| Người nhận | Tên miền nội bộ tin tưởng bạn, và danh sách cho phép che đi địa chỉ xấu |
| Theo dõi lượt bấm | Liên kết bị viết lại bị hỏng, hoặc tên miền theo dõi không có chứng chỉ hợp lệ |
| Lưu lượng | Hàng đợi và giới hạn tốc độ chỉ lộ ra khi tải cao |
| Danh sách chặn gửi | Địa chỉ production từng bị trả lại thư và giờ bị âm thầm bỏ qua |
| Thiết lập URL gốc | Liên kết trỏ sai máy chủ |
Địa chỉ nào trả lời câu hỏi nào
Dưới đây là các lựa chọn, mỗi lựa chọn kèm câu hỏi mà nó thật sự trả lời được.
Bộ bắt thư cục bộ: "ứng dụng của tôi đã tạo ra gì?"
Bộ bắt SMTP nhận mọi thứ ứng dụng của bạn gửi và hiển thị trên một trang web mà không gửi đi đâu cả. Mailpit là lựa chọn mã nguồn mở được ưa chuộng. Theo mặc định nó lắng nghe SMTP ở cổng 1025 và phục vụ giao diện web ở cổng 8025, nên bạn trỏ cấu hình phát triển đến localhost:1025 và mở http://localhost:8025. Ethereal của Nodemailer là ý tưởng tương tự với một dịch vụ SMTP giả được lưu trữ sẵn. Bộ bắt thư nhanh và riêng tư, cho phép bạn gửi đến bất kỳ địa chỉ nào mà không có nguy cơ đến tay người thật. Nó cũng không nói gì về DNS, xác thực hay lọc thư, vì không có gì đi qua internet.
Công cụ hỗ trợ kiểm thử của framework: "mã của tôi đã yêu cầu đúng thư chưa?"
Hầu hết framework có thể ghi lại thư gửi đi trong bộ nhớ khi chạy kiểm thử. Laravel có Mail::fake(), Django thu thập thư trong django.core.mail.outbox, và Rails có ActionMailer::Base.deliveries. Hãy dùng chúng để khẳng định một tác vụ chạy đúng một lần với đúng người nhận và token. Đây là phản hồi nhanh nhất bạn có thể có, và chúng kiểm tra thế giới bên ngoài còn ít hơn cả bộ bắt thư.
Chế độ thử của nhà cung cấp: "tích hợp của tôi có chạy không?"
Các nhà cung cấp hỗ trợ theo nhiều cách khác nhau, và sự khác biệt có ý nghĩa. Amazon SES có bộ mô phỏng hộp thư với các địa chỉ như success@simulator.amazonses.com, bounce@simulator.amazonses.com và complaint@simulator.amazonses.com, tạo ra các kết quả đó mà không làm tổn hại danh tiếng của bạn. Một tài khoản SES mới cũng bắt đầu trong sandbox, nơi nó chỉ gửi được đến các địa chỉ đã xác minh. Chế độ sandbox của SendGrid, đặt qua mail_settings.sandbox_mode.enable, kiểm tra yêu cầu của bạn mà không gửi đi. Postmark chấp nhận token POSTMARK_API_TEST cho cùng mục đích. Những cách này tốt để thử lỗi API và webhook cho thư bị trả lại hoặc bị báo cáo, nhưng chúng không chứng minh thư đã đến ai. Hãy xem tài liệu hiện hành của nhà cung cấp bạn dùng, vì các tính năng này thay đổi.
Tên miền thử nghiệm của riêng bạn: "toàn bộ luồng có chạy, lặp đi lặp lại không?"
Với kiểm thử tự động đầu cuối, hãy thiết lập một tên miền hoặc tên miền con do bạn kiểm soát, với một hộp thư nhận tất cả hoặc một webhook thư đến, để mã kiểm thử đọc được thư qua API. Việc thiết lập tốn chút công sức, nhưng nó riêng tư và ổn định, và không phụ thuộc vào trang web của ai khác. Đừng tự bịa địa chỉ trên tên miền bạn không sở hữu. Có thể ai đó đang sở hữu testuser@gmail.com, và họ sẽ nhận những gì bạn gửi. RFC 2606 dành riêng example.com cùng các tên miền cấp cao nhất .test và .example để tài liệu và dữ liệu thử có chỗ trỏ đến an toàn. Những tên đó không nhận được thư, nên chúng đúng cho dữ liệu mẫu và vô dụng cho kiểm thử gửi thư.
Hộp thư tạm thời bên ngoài thật: "tên miền của một người lạ có nhận được thư này không?"
Đây là chỗ hộp thư tạm thời xứng đáng có mặt. Nó là một hộp thư thật trên tên miền bạn không kiểm soát và không có danh sách cho phép nào cho nó. Thư của bạn phải tìm được bản ghi MX, thiết lập kết nối SMTP và được chấp nhận. Trên VookMail, bản ghi MX của các tên miền trỏ đến một nhà cung cấp chuyển thư, nơi nhận thư rồi chuyển tiếp qua HTTPS. Một địa chỉ mới cũng nghĩa là không có lịch sử: không có thư cũ, không có lần trả lại thư trước đó trong danh sách chặn gửi của bạn, không có bộ lọc. Nhờ vậy đây là cách nhanh để tái hiện tình huống "tôi đăng ký bằng một địa chỉ mới và không nhận được gì". Nó cũng hữu ích với người không làm lập trình. Một nhà thiết kế hay quản lý sản phẩm có thể đọc những gì người dùng mới nhận mà không cần truy cập công cụ của bạn.
Tài khoản mồi tại các nhà cung cấp hộp thư lớn: "thư rơi vào đâu?"
Một thư được gửi đến thành công ở một tên miền không cho bạn biết gì về thư mục thư rác ở tên miền khác. Hãy giữ một nhóm nhỏ tài khoản thật tại những nhà cung cấp mà người dùng của bạn thực sự dùng, và kiểm tra nơi thư rơi vào trước các thay đổi lớn về mẫu thư hoặc tên miền. Sau đó theo dõi số liệu thư bị trả lại và bị báo cáo sau khi phát hành. Nếu thư của bạn trông giống vấn đề thư rác, các tài khoản này là nơi bạn thấy nó đầu tiên.
| Cách tiếp cận | Đi qua internet | Thiết lập | Tự động hóa | Riêng tư nội dung | Giai đoạn phù hợp nhất |
|---|---|---|---|---|---|
| Công cụ hỗ trợ kiểm thử của framework | Không | Không | Rất tốt | Nằm trong tiến trình | Kiểm thử đơn vị và tính năng |
| Bộ bắt SMTP cục bộ | Không | Thấp | Tốt | Nằm trên máy cục bộ | Phát triển |
| Chế độ thử của nhà cung cấp | Thường không | Thấp | Tốt | Nằm ở nhà cung cấp | Kiểm thử tích hợp |
| Tên miền thử nghiệm của bạn | Có | Trung bình đến cao | Tốt | Bạn kiểm soát | CI đầu cuối, staging |
| Hộp thư tạm thời | Có | Không | Không khuyến nghị | Coi như công khai | QA thủ công và kiểm tra trước khi phát hành |
| Tài khoản mồi | Có | Trung bình | Hạn chế | Vừa phải | Kiểm tra nơi thư rơi vào |
Một lượt chạy thủ công với hộp thư tạm thời
Đây là một lượt kiểm tra lặp lại được cho luồng đăng ký trên staging hoặc môi trường tiền production. Khi đã quen, nó chỉ mất khoảng mười phút.
- Xác nhận môi trường dùng cùng cấu hình nhà cung cấp như production, trừ thông tin xác thực, và chỉ chứa dữ liệu bịa. Nếu không, hãy ghi lại điều đó, vì nó giới hạn những gì bạn có thể kết luận.
- Mở VookMail và bấm Mới. Gõ một tên người dùng mã hóa bài kiểm thử, chẳng hạn
email-signup-03-x7, chọn một trong hơn 30 tên miền, rồi bấm mũi tên. Dùng nút Ngẫu nhiên màu vàng nếu có gì trong thư có thể nhạy cảm, vì bất kỳ ai biết hoặc đoán được một địa chỉ đều có thể mở hộp thư đó. - Bấm Sao chép và đăng ký như một người dùng mới với dữ liệu hồ sơ bịa ra.
- Ghi lại lúc bạn gửi và lúc thư xuất hiện. Hộp thư đến kiểm tra mỗi vài giây, nên khoảng chênh lệch vài phút cho thấy vấn đề ở hàng đợi hoặc nhà cung cấp của bạn. Bấm Làm mới nếu bạn muốn chắc chắn.
- Đọc thư như một người dùng mới: tên người gửi, tiêu đề, văn bản xem trước, nội dung, nút, liên kết trơn, chân thư. VookMail hiển thị các mã và liên kết xác nhận được phát hiện phía trên thư, đây là cách kiểm tra sơ bộ xem mã và liên kết của bạn có dễ nhận ra không.
- Xem thư khi tắt hình ảnh. VookMail giữ hình ảnh tắt cho đến khi bạn cho phép và loại bỏ các điểm ảnh theo dõi ẩn. Nếu thư vô nghĩa ở trạng thái đó, một số người dùng của bạn cũng đang thấy như vậy. Tuy nhiên đừng dùng hộp thư này để đánh giá việc theo dõi lượt mở của bạn, vì điểm ảnh sẽ không kích hoạt.
- Bấm nút QR, quét địa chỉ bằng một điện thoại thử nghiệm và mở cùng hộp thư đó ở đó để bấm liên kết thật trên một thiết bị thật, nhất là khi bạn dùng universal link hoặc app link.
- Hoàn tất xác minh và xác nhận trạng thái tài khoản thay đổi đúng như mong đợi.
- Chạy các trường hợp tiêu cực trong danh sách kiểm tra bên dưới: dùng lại liên kết, chờ hết hạn, yêu cầu gửi lại.
- Lưu bằng chứng: ảnh chụp màn hình, dấu thời gian và địa chỉ đã dùng. Thư bị xóa sau khoảng một ngày, nên một báo cáo lỗi viết vào tuần sau sẽ không còn gì để chỉ vào.
- Bấm Xóa và xóa tài khoản thử nghiệm nếu quy trình của bạn yêu cầu.
Có thể giữ nhiều địa chỉ trong cùng một trình duyệt, nên người mời và người được mời, hoặc địa chỉ cũ và mới khi đổi email, có thể được mở cùng lúc. Nếu bạn đính kèm tệp trong bài thử, hãy nhớ rằng VookMail từ chối các tệp chương trình phổ biến như .exe và hiện cảnh báo với tệp nén, nên một tệp đính kèm bị từ chối ở đó có thể không phải lỗi từ phía bạn.
Đọc một lỗi gửi thư
"Email không bao giờ đến" mô tả một triệu chứng có thể ở khoảng sáu chỗ, và các nhóm mất hàng giờ vì bắt đầu sai chỗ. Hãy đi theo đường từ mã của bạn ra ngoài, và dừng ở chỗ đầu tiên bạn không còn thấy thư nữa.
- Ứng dụng có thử gửi không? Tìm trong nhật ký ứng dụng lần thử gửi và mọi ngoại lệ. Tìm xem có tác vụ nào chưa bao giờ được tạo ra, thường vì một điều kiện hoặc feature flag là sai.
- Worker có chạy không? Kiểm tra các tác vụ bị kẹt, thất bại hoặc được thử lại. Một worker hàng đợi không được khởi động lại sau khi triển khai có thể chạy mã cũ, và chính sách thử lại có thể gửi trùng.
- Nhà cung cấp có chấp nhận không? Tra người nhận hoặc
Message-IDtrong nhật ký hoạt động của nhà cung cấp. Đã chấp nhận, bị hoãn, bị trả lại và bị loại bỏ là bốn câu chuyện khác nhau. - Có bị chặn gửi không? Nếu địa chỉ đó từng bị trả lại hoặc bị khiếu nại, nhiều nhà cung cấp âm thầm bỏ qua các lần gửi sau. Điều này thường làm vướng những người kiểm thử dùng lại địa chỉ cũ.
- Máy chủ nhận đã nói gì? Nhật ký của nhà cung cấp thường cho thấy phản hồi SMTP, và dòng chữ đó là dòng hữu ích nhất trong cả cuộc điều tra.
- DNS đúng chưa? Kiểm tra SPF, DKIM và DMARC của tên miền gửi thực tế.
- Thư có ở đó nhưng bị ẩn không? Thư mục thư rác, các tab và bộ lọc của ứng dụng đứng cuối cùng, khi một tài khoản mồi có thể cho bạn thấy.
Phản hồi SMTP đang nói gì với bạn
Theo RFC 5321, phản hồi bắt đầu bằng 4 là lỗi tạm thời, và bên gửi nên thử lại sau. Phản hồi bắt đầu bằng 5 là vĩnh viễn. Các mã trạng thái mở rộng từ RFC 3463 bổ sung chi tiết sau đó. Một dòng nhật ký bịa ra có thể trông thế này, chỉ để minh họa định dạng:
Chỉ là ví dụ: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"
Đọc từ trái sang phải. Số 5 nghĩa là thử lại cũng vô ích. Nhóm 5.7 liên quan đến bảo mật hoặc chính sách, đưa bạn đến DNS và chữ ký, và rời xa địa chỉ của người nhận. Bảng dưới đây cho bạn điểm xuất phát với các mẫu thường gặp.
| Điều bạn thấy | Lớp có khả năng nhất | Nơi xem đầu tiên |
|---|---|---|
| Không có gì trong nhật ký nhà cung cấp | Ứng dụng hoặc hàng đợi | Nhật ký ứng dụng và các tác vụ thất bại |
| Nhà cung cấp báo "dropped" hoặc "suppressed" | Danh sách chặn gửi của nhà cung cấp | Gỡ địa chỉ thử nghiệm đó, hoặc dùng địa chỉ mới |
| API trả về thành công, nhưng không có gì được ghi là đã gửi | Chế độ sandbox vẫn đang bật | Thiết lập nhà cung cấp cho môi trường đó |
5.1.1 hoặc tương tự | Địa chỉ người nhận | Lỗi gõ, và bước kiểm tra biểu mẫu đã sửa địa chỉ |
5.7.26 tại Gmail | Xác thực | SPF, DKIM và sự khớp với tên miền From |
Các lần hoãn 4xx tự hết sau một lúc | Bên nhận làm chậm bạn | Lưu lượng, danh tiếng, hoặc IP gửi mới |
| Đã đến hộp thư bên ngoài, mất ở Gmail | Chính sách hoặc bộ lọc của bên nhận | Tài khoản mồi và hướng dẫn dành cho người gửi của Google |
| Thư đến, nhưng liên kết báo "đã được dùng" | Trình quét tải trước liên kết | Đổi token bằng POST, không phải GET |
| Liên kết dẫn đến cảnh báo bảo mật | Tên miền theo dõi lượt bấm | Chứng chỉ của tên miền con theo dõi |
| Thư đến hai lần | Logic thử lại | Tính idempotent của tác vụ và các thời gian chờ kích hoạt việc thử lại |
| Thư đến rất muộn | Hàng đợi | Năng lực worker, và việc thư đặt lại mật khẩu có dùng chung hàng đợi với thư hàng loạt không |
Dòng cuối là một điểm thiết kế đáng thêm một câu. Nếu thư đặt lại mật khẩu dùng chung hàng đợi với một đợt gửi bản tin, chúng sẽ phải chờ sau đợt đó. Hãy cho thư giao dịch hàng đợi riêng, và tốt nhất là cả tên miền con và luồng gửi riêng, để một sự cố marketing không làm chậm một lần đăng nhập.
Các lệnh giúp rút ngắn việc tìm lỗi
Bạn có thể kiểm tra phần lớn việc này mà không rời terminal. Trong các ví dụ này, hãy thay các tên ví dụ bằng tên của bạn.
dig +short MX example.comcho thấy nơi một tên miền nhận thư. Kết quả rỗng cần xem kỹ hơn, vì RFC 5321 cho phép bên gửi quay về dùng bản ghi địa chỉ, trong khi kết quả0 .là null MX theo RFC 7505, nghĩa là tên miền hoàn toàn không nhận thư.dig +short TXT example.comcho thấy bản ghi SPF cùng các bản ghi văn bản khác.dig +short TXT selector._domainkey.example.comcho thấy khóa DKIM. Lấy selector thật từ giá trịs=trong tiêu đềDKIM-Signaturecủa thư.dig +short TXT _dmarc.example.comcho thấy chính sách DMARC.openssl s_client -starttls smtp -connect smtp.example.com:587kiểm tra bạn có kết nối được đến relay của mình không và cho thấy chứng chỉ của nó. Lỗi ở đây nghĩa là vấn đề tường lửa hoặc TLS, trước cả khi nói đến nội dung.swaks --to qa@example.test --from app@example.test --server localhost:1025gửi một thư đơn giản bằng tay. Nó bỏ qua ứng dụng của bạn, nên bạn biết vấn đề thuộc về mã của mình hay thuộc về đường đi.
Về bằng chứng ở mức tiêu đề, góc nhìn đáng tin cậy nhất là một hộp thư do bạn kiểm soát tại một nhà cung cấp lớn. Trong Gmail, mở thư, dùng menu ba chấm và chọn Show original, nơi liệt kê kết quả SPF, DKIM và DMARC ở đầu. Hãy nhớ rằng kết quả "pass" của một bên nhận không đảm bảo kết quả của bên khác.
Cần kiểm tra gì ở mỗi luồng
"Thư có đến không?" là câu hỏi đầu tiên, và thường là câu kém thú vị nhất. Sau đó mỗi luồng có những cách hỏng riêng.
Đặt lại mật khẩu
OWASP Forgot Password Cheat Sheet là tài liệu tham khảo để dựa vào ở đây. Nó yêu cầu một thông báo nhất quán dù tài khoản có tồn tại hay không, phản hồi mất thời gian đồng đều, token ngẫu nhiên, dài, được lưu an toàn và chỉ dùng một lần, và Referrer-Policy: no-referrer trên trang đặt lại.
- Trang yêu cầu hiển thị cùng một thông báo cho địa chỉ đã đăng ký và chưa đăng ký, và mất thời gian gần như nhau. Một phản hồi tức thì cho địa chỉ lạ làm lộ thông tin chẳng kém cách diễn đạt.
- Liên kết chỉ dùng được một lần. Mở nó lần thứ hai và bạn nhận được lời giải thích rõ ràng kèm cách yêu cầu liên kết khác.
- Yêu cầu đặt lại mới làm vô hiệu các liên kết cũ, hoặc thiết kế của bạn nói khác đi một cách có chủ đích.
- Việc hết hạn do máy chủ thực thi và đã được kiểm thử bằng cách chờ, hoặc bằng cách đổi giờ trong môi trường thử.
- Đặt lại thành công sẽ gửi email xác nhận, và các phiên khác được xử lý theo chính sách của bạn.
- Mở liên kết tự nó không thay đổi gì. Token chỉ được đổi khi biểu mẫu được gửi đi.
- Trang đặt lại không gửi URL của nó cho công cụ phân tích bên thứ ba hay công cụ theo dõi lỗi.
- Giới hạn tốc độ áp dụng theo từng tài khoản cũng như theo từng IP, để không ai làm ngập hộp thư của một người lạ.
- Địa chỉ viết hoa thường lẫn lộn hoặc có dấu cộng hoạt động giống địa chỉ đơn giản.
Xác minh khi đăng ký
- Một lần đăng ký gửi một thư, kể cả khi tác vụ được thử lại.
- Liên kết hoặc mã dùng được một lần, và trang liên kết hết hạn có chỉ đường đi tiếp.
- Gửi lại sẽ làm vô hiệu token trước đó hoặc cùng tồn tại với nó theo thiết kế, và có giới hạn tốc độ.
- Tài khoản chưa xác minh có đúng những hạn chế bạn định ra.
- Đăng ký lại bằng một địa chỉ đã đăng ký không cho khách vô danh biết tài khoản đã tồn tại, nếu sản phẩm của bạn coi điều đó là nhạy cảm. Một mẫu phổ biến là gửi email cho chủ sở hữu hiện tại thay vào đó.
- Liên kết trỏ đến đúng môi trường. Một thư staging có liên kết đến production sớm muộn sẽ làm thay đổi dữ liệu production.
Mã đăng nhập và liên kết ma thuật
- Mã đủ dài, hết hạn nhanh và có giới hạn số lần thử.
- Liên kết ma thuật hiển thị một trang đích có nút bấm, và đổi token ở yêu cầu POST đó, nên GET của trình quét không gây hại.
- Mở liên kết trên thiết bị khác làm đúng như thiết kế của bạn nói, và người dùng hiểu chuyện gì đã xảy ra.
- Tiêu đề thư chỉ chứa mã nếu bạn đã quyết định điều đó chấp nhận được, vì thông báo hiển thị nó trên màn hình khóa.
Đổi địa chỉ email
- Xác nhận được gửi đến địa chỉ mới, và không có gì thay đổi cho đến khi được xác nhận.
- Một thông báo được gửi đến địa chỉ cũ, để chủ sở hữu thật có thể phản ứng với thay đổi trái phép.
- Các token đặt lại còn tồn tại ngừng hoạt động sau khi đổi.
- Hai hộp thư tạm thời giúp chạy trường hợp này bằng tay rất nhanh.
Lời mời, biên lai và thông báo
- Lời mời gửi cho người chưa có tài khoản dẫn đến đăng ký với địa chỉ được điền sẵn hoặc khóa lại, theo thiết kế. Lời mời hết hạn hoặc bị thu hồi thì báo rõ như vậy.
- Một lời mời không thể được chấp nhận bởi tài khoản khác, trừ khi thiết kế của bạn cho phép.
- Biên lai hiển thị đúng số tiền, đơn vị tiền tệ, ngày và múi giờ theo ngôn ngữ của người dùng, và tệp đính kèm có tên hợp lý và mở được bình thường.
- Thay đổi tùy chọn có hiệu lực ở lần gửi kế tiếp.
- Thư không thiết yếu có chức năng hủy đăng ký hoạt động, và thư tài khoản, bảo mật được tách riêng rõ ràng. Bài viết của chúng tôi về quá tải bản tin cho thấy điều đó trông ra sao từ phía người đọc.
- Có các mẫu thư đã dịch cho từng ngôn ngữ được hỗ trợ, với bố cục từ phải sang trái đúng ở nơi cần, và không còn đoạn chưa dịch nào trong tiêu đề.
Xem lại mã xử lý token
Kiểm thử qua hộp thư cho thấy hành vi. Một lần xem lại mã ngắn bắt được những lỗi thiết kế mà không hộp thư nào cho bạn thấy. Khi đọc mã đằng sau đặt lại mật khẩu, xác minh và liên kết ma thuật, hãy tìm những điểm sau.
- Nguồn ngẫu nhiên. Phải là bộ sinh số an toàn về mặt mật mã, như
secrets.token_urlsafe(32)trong Python,crypto.randomBytes(32)trong Node hoặcrandom_bytes(32)trong PHP. Dấu thời gian, ID tăng dần hay hàm băm của email là không chấp nhận được. - Độ dài. Token trong liên kết thường mang ít nhất 128 bit ngẫu nhiên. Mã sáu chữ số chỉ ổn khi hết hạn nhanh và có giới hạn số lần thử.
- Lưu trữ. Hãy lưu hàm băm của token, để rò rỉ cơ sở dữ liệu không đưa ra các liên kết đặt lại còn dùng được.
- So sánh. Dùng hàm so sánh thời gian không đổi như
hmac.compare_digest,hash_equalshoặccrypto.timingSafeEqualkhi bạn so sánh trực tiếp các giá trị bí mật. - Mục đích. Token xác minh không được dùng được như token đặt lại, và token của tài khoản này không được dùng được cho tài khoản khác.
- Hết hạn. Máy chủ giữ thời điểm hết hạn, nên không thể đổi bằng cách sửa liên kết.
- Vô hiệu hóa. Việc dùng token, đổi mật khẩu bằng đường khác, hoặc đổi email đều phải hủy các token còn lại.
- Ghi nhật ký. URL đầy đủ có token không được lọt vào nhật ký ứng dụng, sự kiện phân tích hay công cụ theo dõi lỗi. Hãy kiểm tra cả nhật ký truy cập HTTP của bạn.
Tiêu đề và xác thực
Hãy mở nguồn thô trong bộ bắt thư để xem ứng dụng của bạn tạo ra gì, và trong hộp thư do bạn kiểm soát tại một nhà cung cấp lớn để xem nhà cung cấp và mạng đã thêm gì.
| Tiêu đề hoặc thành phần | Cần xác minh gì |
|---|---|
From | Đúng tên thương hiệu, trên tên miền bạn sở hữu và xác thực |
Reply-To | Một hộp thư có người theo dõi, hoặc bỏ đi một cách có chủ đích |
Return-Path | Tên miền nhận thư trả lại, khớp với tên miền của bạn nếu bạn dựa vào SPF cho DMARC |
DKIM-Signature | Có mặt, với tên miền d= khớp với tên miền From |
Message-ID | Có mặt và duy nhất, vì đó là khóa để bạn truy vết trong nhật ký nhà cung cấp |
Content-Type | multipart/alternative có cả phần HTML và phần văn bản thuần |
List-Unsubscribe, List-Unsubscribe-Post | Có trên thư hàng loạt và marketing, hỗ trợ hủy đăng ký một cú bấm theo RFC 8058 |
Auto-Submitted | auto-generated trên thư tự động, như định nghĩa trong RFC 3834, để giúp ngăn vòng lặp trả lời |
Vài quy tắc cần kiểm tra trước khi bạn đưa vào dùng một tên miền gửi mới. Một lần đánh giá SPF không được vượt quá mười lần tra cứu DNS (RFC 7208), và vượt giới hạn là cách dễ để thất bại sau khi thêm một nhà cung cấp nữa vào bản ghi của bạn. DKIM cần bản ghi selector của nhà cung cấp được công bố và xác minh được. DMARC cần một bản ghi trên tên miền From của bạn, thường bắt đầu từ p=none với báo cáo được bật, rồi siết chặt sau khi đã xác nhận sự khớp.
Lưu lượng cũng làm thay đổi quy tắc. Hướng dẫn của Google coi một người gửi là gửi hàng loạt ở mức khoảng 5.000 thư đến tài khoản Gmail cá nhân trong một ngày, và người gửi hàng loạt cần SPF, DKIM và DMARC, hủy đăng ký một cú bấm cho thư quảng cáo, và tỷ lệ thư rác do người dùng báo cáo giữ dưới 0,3%, với 0,1% là mục tiêu khuyến nghị. Các nhà cung cấp khác có quy tắc riêng. Amazon SES, chẳng hạn, đặt một tài khoản vào diện xem xét khi tỷ lệ thư trả lại đạt 5% hoặc tỷ lệ khiếu nại đạt 0,1%. Hãy đọc số liệu hiện hành từ tài liệu của nhà cung cấp trước khi lên kế hoạch dựa vào chúng, vì chúng thay đổi.
Xử lý và kiểm tra địa chỉ
Biểu mẫu từ chối địa chỉ hợp lệ thường xuyên hơn người ta nghĩ, và một lỗi kiểm tra ở đầu nguồn có thể trông y hệt lỗi gửi thư. Hãy thử biểu mẫu của bạn với các trường hợp này.
| Đầu vào | Cách xử lý mong đợi | Lỗi thường gặp |
|---|---|---|
user+tag@example.com | Chấp nhận | Một biểu thức chính quy từ chối dấu cộng |
User@Example.COM | Chấp nhận, và coi tên miền không phân biệt hoa thường | Tài khoản trùng lặp chỉ khác nhau ở chữ hoa thường |
o'brien@example.com | Chấp nhận | Bị từ chối, hoặc làm hỏng truy vấn hay mẫu thư nếu không được thoát ký tự |
first.last@sub.example.co.uk | Chấp nhận | Việc kiểm tra giả định tên miền chỉ có một dấu chấm |
| Khoảng trắng ở đầu hoặc cuối | Cắt bỏ trước | "Invalid email" khi dán một địa chỉ đúng |
| Một địa chỉ rất dài | Giới hạn 64 ký tự cho phần cục bộ và 254 ký tự tổng cộng | Một cột cơ sở dữ liệu ngắn âm thầm cắt bớt nó |
| Tên miền và địa chỉ quốc tế hóa | Chấp nhận hoặc từ chối nhất quán, kèm thông báo rõ ràng | Lỗi sập trong mã hóa hoặc ghi nhật ký |
| Tên miền không có đường nhận thư | Cảnh báo hoặc từ chối | Một tài khoản không bao giờ xác minh được |
Hãy kiểm tra thoáng ở biểu mẫu, rồi để email xác nhận chứng minh địa chỉ hoạt động. Một biểu thức chính quy chặt làm bạn mất người dùng thật và nói rất ít về việc hộp thư có tồn tại hay không.
Nếu sản phẩm của bạn từ chối các tên miền dùng một lần ở production, quy trình QA của bạn vẫn cần một lối đi trên staging. Các lựa chọn gồm danh sách cho phép các tên miền thử nghiệm ngoài production, một cờ tắt việc kiểm tra trong môi trường thử, hoặc tên miền thử nghiệm riêng của bạn. Đừng nới lỏng quy tắc ở production để việc kiểm thử dễ hơn. Và nếu bạn đang cân nhắc có nên đặt quy tắc đó hay không, bài vì sao các trang web chặn email dùng một lần của chúng tôi nêu chi phí và lợi ích từ góc nhìn của chủ trang.
Cách thư hiển thị
Hiển thị là nơi đánh giá của nhà thiết kế giúp được nhiều nhất, và nó cần thư thật trong các ứng dụng thật.
- Phần văn bản thuần đọc tốt và có đủ liên kết. "Bấm nút bên dưới" vô dụng ở đó.
- Chế độ tối giữ logo nhìn thấy được và giữ độ tương phản. VookMail có chế độ tối, đó là một khởi đầu, còn các ứng dụng mà người dùng của bạn ưa chuộng mới là bài kiểm tra thật.
- Khi hình ảnh bị chặn, lời kêu gọi hành động vẫn là một liên kết văn bản thật hoặc một nút HTML.
- Nút đủ lớn để chạm, và URL dài không làm hỏng bố cục trên điện thoại.
- Văn bản xem trước được viết có chủ đích, không còn chữ thừa từ mẫu.
- Các tiêu đề đúng ngữ nghĩa, độ tương phản đủ, văn bản liên kết mô tả rõ, và HTML có thuộc tính ngôn ngữ.
- Dữ liệu thiếu không tạo ra "Hi {first_name}" hay "Hi ,".
- Kích thước thư giữ ở mức thấp hơn nhiều so với khoảng 102 KB, mức mà Gmail được nhiều nguồn cho là bắt đầu cắt các thư dài. Việc cắt có thể làm mất chân thư và liên kết hủy đăng ký trong phần nội dung.
Các rào chắn chống tai nạn
Những sự cố email đáng xấu hổ phần lớn là lỗi cấu hình: thư staging đến tay khách hàng thật, production dùng khóa thử nghiệm, liên kết đến localhost. Vài thiết lập ngăn được phần lớn những lỗi đó.
Giữ thông tin xác thực riêng cho từng môi trường, trong biến môi trường hoặc trình quản lý bí mật. Ngoài production, hãy dùng danh sách người nhận được phép để bộ gửi thư chỉ gửi đến các tên miền thử nghiệm đã duyệt và chuyển hướng hoặc bỏ mọi thứ còn lại. Tạo mọi liên kết từ một thiết lập duy nhất, như APP_URL, để mẫu thư không chứa máy chủ viết cứng. Thêm tiền tố cho tiêu đề ngoài production bằng thứ như [STAGING] để một thư gửi nhầm lộ ra rõ ràng với người nhận.
Nếu bạn sao chép dữ liệu production sang staging, hãy thay mọi địa chỉ thật bằng địa chỉ tổng hợp trước khi bất kỳ worker gửi thư nào khởi động. Thứ tự rất quan trọng, vì một worker khởi động trước có thể bắt đầu xử lý ngay các thư đã lên lịch. Và hãy theo dõi chế độ sandbox cho từng môi trường một cách có chủ đích. Phát hành khi production vẫn đang ở sandbox là lỗi kinh điển: API trả về thành công, nhật ký trông sạch sẽ, và không có thư nào được gửi ra.
Bộ kiểm thử tự động nên ở trên hạ tầng bạn kiểm soát
Một hộp thư tạm thời công khai là phụ thuộc sai chỗ cho CI. Cào dữ liệu từ trang web của người khác rất mong manh, và bản dựng của bạn sẽ thất bại vì những lý do không liên quan đến mã của bạn. Nó cũng đặt lưu lượng thử nghiệm của bạn lên một dịch vụ mà bạn không vận hành. Bất kỳ ai có địa chỉ đều đọc được thư ở đó, nên không thứ gì tự động nên phụ thuộc vào chúng.
Một cách sắp xếp hợp lý trông như sau. Công cụ hỗ trợ của framework khẳng định đúng thư đã được yêu cầu. Một container Mailpit trong môi trường kiểm thử nhận thư thật, và bài kiểm thử của bạn đọc nó qua API HTTP của Mailpit (GET /api/v1/messages), trích liên kết và theo liên kết đó. Chế độ thử của nhà cung cấp kiểm tra webhook và xử lý lỗi. Một tác vụ chạy hằng đêm trên tên miền thử nghiệm của bạn gửi qua nhà cung cấp thật và đọc kết quả qua webhook thư đến, nên bạn có tín hiệu hằng ngày rằng việc gửi thật vẫn hoạt động.
Thư tạm thời thuộc về những phần kiểm thử do con người làm: các buổi khám phá cần một danh tính mới thật nhanh, một bài kiểm tra nhanh trước khi phát hành, tái hiện báo cáo của người dùng, rà soát nội dung và thiết kế, và kiểm thử trên điện thoại. Với việc cuối cùng, nút QR hoặc ứng dụng từ Google Play hay Huawei AppGallery đưa hộp thư lên thiết bị thử nghiệm. Hãy kiểm tra liên kết có mở ứng dụng của bạn khi nó đã được cài và quay về một trang web hoạt động khi chưa cài, và ứng dụng nhận ra trạng thái đã xác minh mà không yêu cầu đăng nhập lại.
Một ca kiểm thử còn dùng được sau khi bàn giao
Các ca kiểm thử nhất quán dễ lặp lại ở mỗi lần phát hành và dễ chuyển giữa những người kiểm thử hơn. Ví dụ này có các trường thường quan trọng.
| Trường | Ví dụ |
|---|---|
| Mã ca kiểm thử | EMAIL-RESET-03 |
| Luồng | Đặt lại mật khẩu, dùng lại token |
| Điều kiện tiên quyết | Tài khoản thử nghiệm đã xác minh trên staging, với một địa chỉ tạm thời mới |
| Các bước | Yêu cầu đặt lại, mở liên kết, đặt mật khẩu mới, mở lại cùng liên kết đó |
| Kết quả mong đợi | Lần dùng thứ hai giải thích rằng liên kết không còn hiệu lực và đề nghị một yêu cầu mới |
| Bằng chứng | Ảnh chụp màn hình, Message-ID nếu có, dấu thời gian, địa chỉ đã dùng |
| Môi trường | Số hiệu bản dựng staging và cấu hình thư |
Đặt mã ca kiểm thử vào tên người dùng, như email-reset-03-x7, gắn mỗi hộp thư với ca của nó và ngăn hai người kiểm thử đụng nhau trên một địa chỉ. Hậu tố ngẫu nhiên ngắn được thêm vào vì bất kỳ ai cũng mở được một hộp thư nếu đoán ra tên.
Không nên gửi gì vào hộp thư công khai
Hãy coi mọi hộp thư tạm thời là có thể đọc được bởi bất kỳ ai biết địa chỉ, và kiểm thử cho phù hợp.
- Chỉ gửi dữ liệu tổng hợp: tên giả, đơn hàng giả, địa chỉ giả. Dữ liệu khách hàng thật không thuộc về đó, và tùy nơi bạn hoạt động, gửi nó còn có thể gây ra rắc rối pháp lý cho bạn.
- Không bao giờ gửi khóa API, thông tin xác thực cơ sở dữ liệu, hay lời mời quản trị cho các hệ thống thật.
- Thường xuyên xóa tài khoản thử nghiệm, nhất là những tài khoản có đặc quyền. Một người dùng quản trị thử nghiệm gắn với hộp thư công khai là một lối vào nếu người khác mở hộp thư đó và yêu cầu đặt lại. Vì địa chỉ không được dành riêng cho bạn sau khi đã bị xóa sạch, rủi ro này vẫn còn sau bài thử.
- Không bao giờ dùng địa chỉ tạm thời làm chủ sở hữu của một tài khoản production thật hoặc dịch vụ bên thứ ba mà công ty bạn dựa vào.
- Biết thời gian lưu giữ. Thư và tệp đính kèm bị xóa sau khoảng một ngày, và chính sách quyền riêng tư có chi tiết.
Kiểm thử sản phẩm của chính bạn là một trong những cách dùng hợp pháp rõ ràng nhất của email dùng một lần. Hãy giữ nó như vậy: chỉ kiểm thử những hệ thống bạn sở hữu hoặc được ủy quyền kiểm thử. Đừng dùng hộp thư tạm thời để tạo tài khoản trên dịch vụ của công ty khác trái điều khoản của họ, để gom các bản dùng thử, hay để kiểm thử tải biểu mẫu đăng ký của người khác. Điều khoản và điều kiện quy định việc sử dụng được chấp nhận, và trang phương pháp giải thích dịch vụ hoạt động thế nào. VookMail là một phần của mạng lưới công cụ miễn phí PAYATE.
Trước khi phát hành
- SPF, DKIM và DMARC đã được xác minh cho tên miền gửi production thực tế, với tên miền
Fromkhớp nhau. - Bộ gửi thư production dùng thông tin xác thực production, tắt chế độ sandbox, được xác nhận bằng một thư thật.
- Xác minh đăng ký được nhận ở một địa chỉ bên ngoài mới, liên kết dùng một lần, việc hết hạn đã được thử.
- Đặt lại mật khẩu được kiểm thử đầu cuối, gồm cả phản hồi giống hệt cho địa chỉ lạ và thư xác nhận.
- Token đặt lại và liên kết ma thuật được đổi khi biểu mẫu được gửi, để GET của trình quét không tiêu thụ chúng.
- Đổi email gửi đến cả địa chỉ mới và địa chỉ cũ.
- Mọi liên kết trỏ đến máy chủ production qua HTTPS, kể cả những liên kết bị viết lại bởi theo dõi lượt bấm.
- Thư giao dịch tách khỏi thư hàng loạt, ít nhất là ở hàng đợi của nó.
- Cả HTML và văn bản thuần đều có và đọc được, đã kiểm tra chế độ tối và hình ảnh bị chặn.
- Kiểm tra nơi thư rơi vào ở các tài khoản mồi nếu tên miền hoặc mẫu thư thay đổi đáng kể.
- Hủy đăng ký hoạt động trên thư không thiết yếu, và các mẫu thư đã dịch được rà soát.
- Bằng chứng đính kèm vào phiếu phát hành, và số liệu thư bị trả lại, bị khiếu nại nằm trên một bảng điều khiển sẽ có người theo dõi sau khi ra mắt.
Những câu hỏi lập trình viên hay hỏi
Một hộp thư thật đã nhận thư của tôi. Vậy ở Gmail tôi có an toàn không?
Không. Việc gửi đến một tên miền cho thấy thư của bạn đã đi ra, tìm được đường và được chấp nhận ở đó. Gmail áp dụng quy tắc xác thực và bộ lọc riêng của nó, mọi nhà cung cấp lớn khác cũng vậy. Hãy dùng tài khoản mồi và Postmaster Tools của Google cho câu hỏi đó.
Tôi có thể dùng lại cùng một địa chỉ thử nghiệm không?
Bạn có thể dùng trong một phiên, nhưng địa chỉ mới cho bài thử sạch hơn. Địa chỉ cũ tích lũy các mục chặn gửi và thư cũ, và trên dịch vụ tạm thời thì hộp thư cũng bị xóa sạch sau khoảng một ngày.
Thư đến bộ bắt thư của tôi nhưng không đến bên ngoài. Tôi nên bắt đầu từ đâu?
Bộ bắt thư chỉ cho thấy ứng dụng của bạn đã tạo ra một thư và không hơn, vì vậy hãy bắt đầu với nhật ký hoạt động của nhà cung cấp. Phần lớn thời gian, câu trả lời là một thiết lập sandbox, một mục chặn gửi, thông tin xác thực sai, hoặc một lần từ chối SMTP nêu tên xác thực.
Liên kết đặt lại nên còn hiệu lực bao lâu?
Đủ ngắn để hạn chế thiệt hại và đủ dài để thư chậm kịp đến. Nhiều nhóm chọn đâu đó từ 15 phút đến một giờ, nhưng còn tùy rủi ro của bạn và tốc độ gửi thư của bạn, và thư của người dùng có thể bị chậm ngoài tầm kiểm soát của bạn. Dù chọn thế nào, hãy kiểm thử trạng thái hết hạn và cho mọi người biết cần làm gì tiếp theo.