Source: https://once-email.com/vi/blog/safe-email-test-evidence Kiểm thử và kỹ thuật · 2 thg 8, 2026Cập nhật 9 thg 8, 2026 # Cách lưu bằng chứng kiểm tra email mà không tiết lộ bí mật Tạo ảnh chụp màn hình, tiêu đề và báo cáo lỗi hữu ích trong khi xóa mã xác minh, đặt lại mã thông báo, địa chỉ email, số nhận dạng và dữ liệu cá nhân không liên quan. [Ban biên tập Once Email, Once Email author Ban biên tập Once Email]() Được duyệt bởi Đội ngũ chuyên môn Once Email Hướng dẫn này giúp bạn làm gì Người đọc có thể tạo ảnh chụp màn hình, tiêu đề và báo cáo lỗi hữu ích trong khi xóa thông tin xác thực, số nhận dạng và ngữ cảnh trực tiếp không hỗ trợ chẩn đoán. Hướng dẫn bài viết Vì sao bài viết này đáng đọc **Phân tích nguyên bản** Chúng tôi làm việc ngược lại với câu hỏi về khiếm khuyết để giảm thiểu bằng chứng được thu thập, tách bằng chứng cần thiết để sao chép khỏi bí mật và dữ liệu cá nhân không liên quan. **Bối cảnh xu hướng** Trình theo dõi vấn đề trên đám mây và các nhóm phân phối giúp chia sẻ bằng chứng dễ dàng hơn và khó rút lại hơn, làm tăng giá trị của việc thu hồi, cắt xén và tổng hợp mẫu. **Giá trị thực tế** Người đọc có thể tạo ảnh chụp màn hình, tiêu đề và báo cáo lỗi hữu ích trong khi xóa thông tin xác thực, số nhận dạng và ngữ cảnh trực tiếp không hỗ trợ chẩn đoán. Ảnh chụp màn hình có thể chứng minh rằng email được hiển thị không chính xác nhưng nó cũng có thể xuất bản liên kết đặt lại đang hoạt động. Tiêu đề được sao chép có thể giải thích đường dẫn phân phối trong khi hiển thị địa chỉ, ID tin nhắn, máy chủ nội bộ hoặc giá trị tương quan thử nghiệm. Bằng chứng tốt bảo vệ sự thật cần thiết để tái tạo một khiếm khuyết và loại bỏ mọi thứ không hỗ trợ sự thật đó. Hãy coi mã xác minh, liên kết ma thuật và URL đặt lại mật khẩu làm thông tin xác thực khi chúng hợp lệ. Việc chỉnh sửa không phải là sự thay thế cho việc hết hạn hoặc thu hồi: nếu một bí mật thực sự đã được chia sẻ, trước tiên hãy vô hiệu hóa hoặc xoay vòng bí mật đó. Hướng dẫn chính thức của GitHub về [xóa dữ liệu nhạy cảm khỏi kho lưu trữ]() cũng khuyên bạn nên thu hồi hoặc thay đổi mật khẩu, mã thông báo hoặc thông tin xác thực bị lộ trước khi thử dọn dẹp kho lưu trữ. ## [Bắt đầu bằng câu hỏi mà bằng chứng phải trả lời]() Viết một câu trước khi thu thập bất cứ điều gì: “Bằng chứng này sẽ cho thấy rằng…” Các ví dụ bao gồm “dòng chủ đề trên thiết bị di động chồng lên dấu thời gian”, “thông báo đặt lại đến sau khoảng thời gian hiệu lực đã nêu” hoặc “liên kết trỏ đến máy chủ lưu trữ”. Câu đó giới hạn việc sưu tầm. Lỗi bố cục có thể cần ảnh chụp màn hình và chiều rộng khung nhìn bị cắt chứ không phải thông báo thô. Lỗi gửi chậm có thể cần dấu thời gian UTC và giá trị tương quan ẩn danh chứ không phải nội dung thư. Lỗi phân tích cú pháp tiêu đề có thể cần một mẫu tiêu đề tổng hợp nhỏ chứ không phải tin nhắn gốc của khách hàng. Ưu tiên bằng chứng được tạo bằng tài khoản thử nghiệm chuyên dụng và dữ liệu hư cấu. Không sử dụng hộp thư đến của khách hàng thực chỉ vì nó đã cho thấy có vấn đề. ## [Biết những gì cần loại bỏ]() Xem lại cả dữ liệu hiển thị và ẩn. Các yếu tố nhạy cảm phổ biến bao gồm: - địa chỉ người gửi và người nhận đầy đủ; - mã xác minh, mật khẩu một lần và liên kết ma thuật; - mọi URL đặt lại, bao gồm chuỗi truy vấn và đoạn của nó; - mật khẩu, khóa API, cookie, trường ủy quyền và số nhận dạng phiên; - ` Message-ID `, ID hàng đợi của nhà cung cấp và ID tương quan ứng dụng; - tên máy chủ nội bộ, địa chỉ IP riêng và URL môi trường không công khai; - tên, số điện thoại, địa điểm, chi tiết đơn hàng và nội dung tin nhắn không liên quan; - các tab trình duyệt, dấu trang, thông báo và tên tệp trên màn hình được chụp xung quanh ảnh chụp màn hình; - siêu dữ liệu hình ảnh khi công cụ thu thập lưu giữ nó. [RFC 5322]() định nghĩa ` Message-ID ` là mã định danh duy nhất mà máy có thể đọc được cho một phiên bản cụ thể của tin nhắn. Nó có giá trị đối với mối tương quan nhật ký được kiểm soát, nhưng tính duy nhất cũng là lý do tại sao một báo cáo công khai thường cần một trình giữ chỗ ổn định thay vì giá trị ban đầu. Đừng quên URL đằng sau các nút. Ảnh chụp màn hình có thể ẩn đích đến, trong khi HTML được sao chép hoặc chú giải công cụ di chuột sẽ hiển thị mã thông báo đầy đủ. Ngược lại, việc vẽ lên văn bản hiển thị trong hình ảnh sẽ không xóa bí mật khỏi lớp HTML, PDF bên dưới, mô tả vấn đề hoặc tên tệp đính kèm. ## [Chọn định dạng bằng chứng an toàn nhỏ nhất]() Sử dụng ảnh chụp màn hình đã cắt để bố trí vị trí trực quan, bao bọc, độ tương phản hoặc phản hồi. Sử dụng đoạn trích văn bản ngắn để có các ký tự hoặc phân tích cú pháp chính xác. Sử dụng dòng thời gian có cấu trúc cho việc giao hàng chậm trễ. Sử dụng thông báo tổng hợp để kiểm tra trình phân tích cú pháp lặp lại. Tránh đính kèm bản xuất hộp thư đầy đủ khi ba dòng chứng tỏ có lỗi. Theo mặc định, không tải các tệp ` .eml ` thô lên trình theo dõi vấn đề hiển thị rộng rãi: chúng có thể chứa toàn bộ nội dung, tất cả các trường tiêu đề, URL tài nguyên từ xa và tệp đính kèm. Once Email hiển thị các tin nhắn đã nhận nhưng không cung cấp bảo đảm xuất khẩu hoặc biên tập bằng chứng. [bộ phân tích tiêu đề email]() của nó xử lý văn bản tiêu đề được dán cục bộ trong trình duyệt và có thể giúp xác định các trường nhưng bạn vẫn chịu trách nhiệm quyết định nội dung nào có thể được chia sẻ. ## [Chỉnh sửa lại ảnh chụp màn hình một cách an toàn]() Tạo một bản sao và chỉ giữ mọi bản gốc chưa được biên tập lại ở một địa điểm đã được phê duyệt và có quyền kiểm soát truy cập. Cắt thành phần có liên quan đầu tiên. Sau đó thay thế các vùng nhạy cảm bằng các khối mờ đục; không dựa vào độ mờ, tạo pixel, đánh dấu mờ hoặc đặt hình dạng có thể di chuyển lên trên nội dung có thể chỉnh sửa. Xuất kết quả đã được xử lý lại dưới dạng hình ảnh phẳng. Mở lại tệp đã xuất đó, phóng to và xác minh rằng không thể khôi phục bí mật bằng cách ẩn một lớp, sao chép văn bản hoặc tăng độ tương phản. Kiểm tra các cạnh hình ảnh và chrome trình duyệt xung quanh để tìm địa chỉ, tab và thông báo. Sử dụng phần giữ chỗ có ý nghĩa khi ngữ cảnh quan trọng: ``` [TEST_RECIPIENT] [VERIFICATION_CODE_REMOVED] https://staging.example/reset?[TOKEN_REMOVED] Message-ID: <[MESSAGE_ID_REMOVED]> ``` Giữ cùng một phần giữ chỗ cho các lần xuất hiện lặp lại chỉ khi cho thấy rằng hai giá trị khớp nhau là cần thiết. Nếu không, hãy tránh tạo một bút danh ổn định để người đọc có thể liên hệ với các báo cáo không liên quan. ## [Chỉnh sửa lại các tiêu đề và liên kết mà không phá hủy lỗi]() Sao chép các trường liên quan tối thiểu vào một tệp văn bản mới. Thay thế các giá trị nhạy cảm; không chỉnh sửa bằng chứng gốc duy nhất. Giữ nguyên tên trường, cách gấp và dấu phân cách nếu lỗi liên quan đến phân tích cú pháp. Đối với vấn đề về đơn hàng giao hàng, một mẫu ẩn danh có thể giữ lại dấu thời gian ` Received ` trong khi thay thế máy chủ, địa chỉ và ID hàng đợi. Đối với sự cố hiển thị xác thực, hãy giữ nguyên các từ khóa kết quả như ` spf=pass ` trong khi thay thế các miền bằng các ví dụ dành riêng như ` sender.example `. Giải thích mọi sự thay thế trong báo cáo. Nếu URL đặt lại hiển thị tên máy chủ sai, chỉ giữ lại lược đồ và máy chủ đã được làm sạch, sau đó thay thế đường dẫn, truy vấn và đoạn hoàn chỉnh trừ khi các thành phần đó bị lỗi. Không bao giờ giữ lại một phần mã thông báo thực: các định dạng bí mật có thể chứa số nhận dạng tài khoản hoặc vẫn có thể sử dụng được sau khi chỉ một vài ký tự bị ẩn. ## [Tách báo cáo công khai khỏi bằng chứng bị hạn chế]() Vấn đề chính phải bao gồm các bước có thể tái tạo, kết quả mong đợi, kết quả thực tế, môi trường, xây dựng và bằng chứng đã được vệ sinh. Nếu người đánh giá bảo mật hoặc quyền riêng tư được ủy quyền thực sự cần bản gốc, hãy đặt nó vào kênh hạn chế đã được phê duyệt của tổ chức cùng với chủ sở hữu và ngày xóa. Đừng tùy tiện đính kèm nó vào cuộc trò chuyện. Ghi lại ai có thể truy cập bản sao bị hạn chế và tại sao. Xóa nó khi cuộc điều tra kết thúc hoặc hết thời gian lưu giữ. Việc lưu trữ lâu dài các thông báo xác minh tạm thời sẽ tạo ra rủi ro mà không cải thiện được lỗi đã đóng. ## [Xem lại trước khi tải lên]() Sử dụng đánh giá hai lượt. Đầu tiên, trình báo cáo kiểm tra mọi giá trị hiển thị, mục tiêu liên kết, tên tệp và trường siêu dữ liệu. Thứ hai, một người được ủy quyền khác sẽ kiểm tra tạo phẩm được xuất ra với tư cách là người nhận sẽ nhìn thấy nó. Mở chính xác tệp sẽ được tải lên chứ không phải nguồn có thể chỉnh sửa. Xác nhận rằng: 1. không còn mã, liên kết, cookie hoặc thông tin xác thực hợp lệ; 2. địa chỉ và dữ liệu cá nhân bị xóa trừ khi thực sự cần thiết và được chấp thuận; 3. mã định danh là phần giữ chỗ hoặc chỉ được lưu trữ trong kênh bị hạn chế; 4. Chứng cứ vẫn chứng minh được kết quả thực tế đã nêu; 5. các bước tái tạo sử dụng dữ liệu thử nghiệm và môi trường được ủy quyền; 6. khả năng hiển thị của vấn đề phù hợp với độ nhạy còn lại; 7. có quyết định giữ lại hoặc xóa đối với các bản gốc bị hạn chế. ## [Nếu một bí mật đã được công bố]() Dừng chia sẻ liên kết và liên hệ với chủ sở hữu hệ thống. Hết hạn hoặc thay đổi thông tin xác thực, vô hiệu hóa các phiên bị ảnh hưởng khi thích hợp, hạn chế báo cáo và tuân theo quy trình dọn dẹp của hệ thống lưu trữ hoặc vấn đề. Việc xóa ảnh chụp màn hình hoặc cam kết mới nhất có thể không xóa các bản sao, thông báo, nhánh hoặc lịch sử được lưu trong bộ nhớ đệm. Sau khi ngăn chặn, hãy thay thế hiện vật bằng một phiên bản đã được xác minh lại và ghi lại mức độ phơi nhiễm thông qua quy trình xử lý sự cố của tổ chức. Mục đích không phải là làm cho lịch sử trở nên trong sạch; đó là làm cho bí mật không thể sử dụng được, hạn chế quyền truy cập và lưu giữ đủ bằng chứng an toàn để khắc phục khiếm khuyết cơ bản. Để biết quy trình làm việc đầy đủ chức năng tạo ra bằng chứng này, hãy sử dụng [danh sách kiểm tra email dành cho nhà phát triển]() . Cùng với nhau, cả hai phương pháp này giúp tái tạo lỗi luồng thư mà không biến báo cáo của nó thành sự cố bảo mật thứ hai. ## Hướng dẫn liên quan Danh sách kiểm tra email dành cho nhà phát triển: Từ yêu cầu đến hết hạn Một danh sách kiểm tra thực tế, được ủy quyền để kiểm tra các luồng email đăng ký, xác minh và đặt lại mật khẩu mà không che giấu các lỗi gửi hoặc làm suy yếu các biện pháp kiểm soát bảo mật. [Danh sách kiểm tra email dành cho nhà phát triển: Từ yêu cầu đến hết hạn]() Cách sử dụng API email tạm thời mà không cần xây dựng các bài kiểm tra dễ lỗi Một thiết kế thực tế để kiểm tra API email tạm thời: tách biệt từng lần chạy, thăm dò ý kiến ​​bằng thời gian chờ, xác định đúng thông báo, bảo vệ bí mật và luôn dọn dẹp. [Cách sử dụng API email tạm thời mà không cần xây dựng các bài kiểm tra dễ lỗi]() Postfix và Dovecot: Vai trò khác nhau trong máy chủ nhận email Xác định vị trí của Postfix, Dovecot, LMTP, hàng đợi và IMAP, rồi dùng bằng chứng để tìm ranh giới lỗi. [Postfix và Dovecot: Vai trò khác nhau trong máy chủ nhận email]() ## Công cụ email ưu tiên quyền riêng tư Tạo hash SHA-256/512 Tạo hash văn bản cục bộ bằng Web Crypto. Tạo hash SHA-256/512 [Danh sách kiểm tra email dành cho nhà phát triển: Từ yêu cầu đến hết hạn Một danh sách kiểm tra thực tế, được ủy quyền để kiểm tra các luồng email đăng ký, xác minh và đặt lại mật khẩu mà không che giấu các lỗi gửi hoặc làm suy yếu các biện pháp kiểm soát bảo mật.]() [Bí danh email so với Hộp thư đến tạm thời và Địa chỉ cố định: Bạn nên sử dụng cái nào? So sánh bí danh chuyển tiếp, hộp thư đến tạm thời chỉ nhận và tài khoản email cố định bằng cách khôi phục, quyền riêng tư, trả lời, lưu giữ hồ sơ và chính sách trang web.]()