อีเมลที่ส่งผ่าน VPN: คำตอบไปถึงที่ไหนจริง ๆ

คุณส่งข้อความผ่านอุโมงค์ ตัดการเชื่อมต่อ แล้วคำตอบก็มาถึงเช้าวันรุ่งขึ้น ไม่มีอะไรในนั้นที่ต้องใช้ที่อยู่ VPN เก่า และไม่มีอะไรเสียหาย อีเมลไม่ได้ส่งคำตอบไปยังที่อยู่ที่ส่งข้อความออกไป แต่ส่งไปยังกล่องจดหมาย ที่นี่เส้นทางสามเส้นถูกรวมเป็นคำถามเดียว และการแยกมันออกจากกันตอบข้อกังวลส่วนใหญ่ได้

สามเส้นทางที่คนมักรวมเป็นหนึ่ง

การส่ง การนำส่ง และการอ่านเป็นการเชื่อมต่อสามอย่างแยกกัน และมีเพียงสองอย่างที่เกี่ยวกับอุปกรณ์ของคุณ

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPN ส่งผลต่อเส้นทางแรกและเส้นทางที่สามได้ เพราะเป็นการเชื่อมต่อที่อุปกรณ์ของคุณสร้างขึ้น มันส่งผลต่อเส้นทางที่สองไม่ได้ เพราะเส้นทางนั้นวิ่งระหว่างเซิร์ฟเวอร์อีเมลสองเครื่องที่คุณไม่ได้ควบคุม คำตอบไม่ใช่แพ็กเก็ตที่ย้อนกลับไปยังที่อยู่ที่คุณส่งออกไป แต่เป็นข้อความใหม่ที่บริการอีเมลของอีกฝ่ายนำส่งไปยังบริการกล่องจดหมายของคุณ

เมื่อแยกสามสิ่งนี้ออกจากกัน คำถามที่ว่าคำตอบจะมาถึงคุณหรือไม่ก็ไม่ใช่เรื่องลึกลับอีกต่อไป

ฟิลด์ Reply-To คือที่อยู่ ไม่ใช่เส้นทาง

RFC 5322 กำหนดให้ Reply-To คือกล่องจดหมายหรือกล่องจดหมายที่คำตอบควรถูกส่งไป หากไม่มี ค่าเริ่มต้นปกติคือกล่อง From เว้นแต่ผู้ตอบจะพิมพ์อย่างอื่น ทั้งสองเป็นที่อยู่อีเมลที่อยู่ในส่วนหัว ไม่มีอันใดเป็นคำสั่งให้เปิดการเชื่อมต่อเครือข่ายที่ส่งข้อความต้นฉบับอีกครั้ง

นี่คือเหตุผลที่ที่อยู่ทางออกของ VPN ไม่เคยปรากฏในเส้นทางของคำตอบ แม้เซิร์ฟเวอร์ที่รับส่งจะบันทึกที่อยู่ทางออกนั้นไว้ที่ใดที่หนึ่ง คำตอบก็ยังจ่าหน้าถึงกล่องจดหมาย และเซิร์ฟเวอร์ที่ส่งจะค้นหาเมลเอ็กซ์เชนเจอร์ของโดเมนแทนซ็อกเก็ตเก่าของคุณ

หากคำตอบไปที่ใดอย่างไม่คาดคิด ให้อ่าน Reply-To และการตั้งค่าไคลเอนต์ของผู้ส่งเองก่อนจะสงสัยอุโมงค์

ส่วนหัวการติดตามบันทึกอะไรจริง ๆ

ทุกฮอป SMTP จะเพิ่มส่วนหัว Received ไว้ข้างหน้าซึ่งอธิบายการเชื่อมต่อที่จัดการ และอันบนสุดคือฮอปสุดท้ายก่อนการนำส่ง ข้อความที่ส่งจึงอาจมีรายละเอียดเครือข่ายที่ควรตรวจสอบ และรายละเอียดเหล่านั้นเซิร์ฟเวอร์เป็นผู้เขียน ไม่ใช่คุณเลือก สิ่งที่บรรจุอยู่ขึ้นกับสถาปัตยกรรมการส่งของผู้ให้บริการและการจัดการส่วนหัวของเขา

อ่านมันแทนการเดา จากข้อความที่บันทึกไว้:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

วินัยที่เป็นประโยชน์คือการระบุว่าบริการที่เชื่อถือได้ใดเพิ่มแต่ละฟิลด์ ข้อความตามอำเภอใจที่อยู่ก่อนหน้าในบล็อกส่วนหัวไม่ใช่หลักฐานที่เชื่อถือได้ และชื่อผลิตภัณฑ์ไม่ใช่คำสัญญาถาวรว่าที่อยู่บ้านของคุณมีอยู่เสมอหรือไม่มีอยู่เสมอ

การอ่านอีเมลภายหลังคือการเชื่อมต่อใหม่

เมื่อคุณเปิดคำตอบ ไคลเอนต์ของคุณเชื่อมต่อกับบริการกล่องจดหมายผ่านเครือข่ายที่คุณอยู่ตอนนี้ นี่คือการเชื่อมต่อใหม่ที่มีที่อยู่ต้นทางของตัวเอง ไม่ใช่ความต่อเนื่องของซ็อกเก็ตที่ใช้ส่งเมื่อวาน มันเป็นไปตามนโยบายปัจจุบันของเครือข่ายที่คุณใช้อยู่ในขณะนั้น

เนื้อหาภายนอกก็เป็นอีกเรื่องที่สาม ไคลเอนต์อีเมลที่โหลดภาพจากระยะไกลหรือตามลิงก์จะสร้างคำขอแยกตามการตั้งค่าปัจจุบัน และคำขอนั้นอาจพาตัวระบุใด ๆ ที่ข้อความฝังไว้ไปด้วย นั่นไม่ใช่คำตอบ SMTP ที่มาถึงที่อยู่เก่า และการถือว่าเป็นเช่นนั้นก็ปิดบังการเปิดเผยที่แท้จริง

ปิดเนื้อหาภายนอกหากคุณต้องการอ่านข้อความโดยไม่ประกาศว่าคุณเปิดมัน

สิ่งที่ควรตรวจสอบก่อนจะเรียกมันว่าการรั่วไหล

เริ่มจากมุมมองข้อความต้นฉบับและฟิลด์ Reply-To จากนั้นระบุว่าบริการใดเพิ่มรายการ Received ที่กังวลคุณ และเปรียบเทียบกับเอกสารปัจจุบันของผู้ให้บริการแทนคำตอบในฟอรัมเก่า

สุดท้าย แยกคำถามออกจากกัน: เซิร์ฟเวอร์ที่รับส่งสังเกตเห็นอะไร ห่วงโซ่การนำส่งเพิ่มอะไร และไคลเอนต์ของคุณขออะไรเมื่อคุณเปิดข้อความ

การตอบสามข้อนี้แยกกันต้องใช้แรงมากกว่าการตรวจหน้าหนึ่งของ IP และเป็นเวอร์ชันเดียวที่ให้ข้อสรุปที่คุณปกป้องได้ การตอบกลับที่อยู่อีเมลไม่ได้เปิดเผยที่อยู่บ้านของคุณ และไม่จำเป็นต้องให้อุโมงค์เก่ายังเปิดอยู่