Email gửi qua VPN: câu trả lời thực sự đi đâu
Câu trả lời được gửi đến một hộp thư, không phải địa chỉ VPN mà bạn đã gửi đi. Hãy tách riêng việc gửi, việc chuyển và kết nối sau đó để đọc câu trả lời.
Bạn gửi một thông điệp qua đường hầm, ngắt kết nối, và câu trả lời đến vào sáng hôm sau. Không có gì trong đó cần địa chỉ VPN cũ, và không có gì bị hỏng. Email không định tuyến câu trả lời đến địa chỉ mà thông điệp được gửi đi; nó định tuyến chúng đến một hộp thư. Ở đây ba con đường bị gộp thành một câu hỏi, và tách chúng ra sẽ trả lời phần lớn nỗi lo.
Ba con đường mà người ta gộp thành một
Gửi, chuyển và đọc là ba kết nối riêng biệt, và chỉ hai trong số đó liên quan đến thiết bị của bạn.
Submission: your mail app -> your mail service
Delivery: other mail service -> your mailbox service
Reading: your app now -> your mailbox serviceVPN có thể ảnh hưởng đến con đường thứ nhất và thứ ba, vì đó là những kết nối do thiết bị của bạn tạo ra. Nó không thể ảnh hưởng đến con đường thứ hai, vì con đường đó chạy giữa hai máy chủ thư mà bạn không kiểm soát. Câu trả lời không phải là một gói tin quay về địa chỉ bạn đã gửi đi. Đó là một thông điệp mới mà dịch vụ thư của phía bên kia chuyển đến dịch vụ hộp thư của bạn.
Khi bạn giữ ba thứ đó riêng ra, câu hỏi liệu câu trả lời có tìm thấy bạn không còn là điều bí ẩn.
Trường Reply-To là một địa chỉ, không phải một tuyến đường
RFC 5322 định nghĩa Reply-To là hộp thư hoặc các hộp thư mà câu trả lời nên được gửi đến. Không có trường này, giá trị mặc định thông thường là hộp From, trừ khi người trả lời gõ thứ gì khác. Cả hai đều là địa chỉ thư nằm trong phần đầu. Không cái nào là chỉ dẫn mở lại kết nối mạng đã gửi thông điệp gốc.
Đó là lý do địa chỉ thoát của VPN không bao giờ xuất hiện trên đường đi của câu trả lời. Ngay cả khi máy chủ gửi đã ghi lại địa chỉ thoát đó ở đâu đó, câu trả lời vẫn được gửi đến một hộp thư, và máy chủ gửi tra cứu máy chủ trao đổi thư của tên miền thay vì socket cũ của bạn.
Nếu một câu trả lời đi đâu đó bất ngờ, hãy đọc Reply-To và chính cài đặt ứng dụng của người gửi trước khi nghi ngờ đường hầm.
Các tiêu đề theo dõi thực sự ghi lại điều gì
Mỗi chặng SMTP thêm vào đầu một tiêu đề Received mô tả kết nối mà nó đã xử lý, và cái trên cùng là chặng cuối trước khi chuyển. Vì vậy một thông điệp đã gửi có thể mang những chi tiết mạng đáng xem xét, và những chi tiết đó do máy chủ viết chứ không phải bạn chọn. Nội dung của chúng phụ thuộc vào kiến trúc gửi của nhà cung cấp và cách họ xử lý tiêu đề.
Hãy đọc chúng thay vì đoán, từ một thông điệp đã lưu:
grep -E '^(Received|Return-Path|Reply-To|From):' message.emlKỷ luật hữu ích là xác định dịch vụ tin cậy nào đã thêm từng trường. Văn bản tùy tiện ở phía trước khối tiêu đề không phải bằng chứng đáng tin, và tên sản phẩm không phải lời hứa vĩnh viễn rằng địa chỉ nhà của bạn luôn hiện diện hay luôn vắng mặt.
Đọc thư sau đó là một kết nối mới
Khi bạn mở câu trả lời, ứng dụng của bạn kết nối đến dịch vụ hộp thư qua mạng mà bạn đang ở hiện tại. Đó là một kết nối mới với địa chỉ nguồn của riêng nó, không phải sự tiếp nối của socket gửi hôm qua. Nó tuân theo chính sách hiện hành của mạng bạn đang dùng vào lúc đó.
Nội dung từ xa lại là một thứ thứ ba. Ứng dụng thư tải một hình ảnh từ xa hoặc theo một liên kết sẽ thực hiện một yêu cầu riêng theo cài đặt hiện tại, và yêu cầu đó có thể mang bất kỳ định danh nào mà thông điệp đã nhúng. Đó không phải là câu trả lời SMTP đến một địa chỉ cũ, và coi nó như vậy sẽ che giấu mức phơi nhiễm thực sự.
Hãy tắt nội dung từ xa nếu bạn muốn đọc một thông điệp mà không thông báo rằng bạn đã mở nó.
Cần kiểm tra gì trước khi gọi đó là rò rỉ
Bắt đầu từ chế độ xem thông điệp gốc và trường Reply-To. Sau đó xác định dịch vụ nào đã thêm các mục Received khiến bạn lo lắng, và so sánh điều đó với tài liệu hiện hành của nhà cung cấp thay vì một câu trả lời cũ trên diễn đàn.
Cuối cùng, tách các câu hỏi ra: máy chủ gửi đã quan sát được gì, chuỗi chuyển đã thêm gì, và ứng dụng của bạn đã yêu cầu gì khi bạn mở thông điệp?
Trả lời ba câu đó riêng rẽ tốn nhiều công hơn việc kiểm tra một trang IP, và đó là phiên bản duy nhất đưa ra kết luận bạn có thể bảo vệ. Trả lời một địa chỉ email không tiết lộ địa chỉ nhà của bạn và không đòi hỏi đường hầm cũ phải tiếp tục hoạt động.