อีเมลทำงานอย่างไร

ขั้นแรก คุณใช้ตัวแทนผู้ใช้อีเมลหรือ MUA เพื่ออ่านและส่งอีเมลจากอุปกรณ์ของคุณ (เช่น Gmail หรือแอปอีเมลบนอุปกรณ์ Apple) โปรแกรมเหล่านี้จะใช้งานได้เมื่อคุณใช้งานเท่านั้น

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

อีเมลจะถูกเก็บไว้จากระยะไกลจนกว่าคุณจะเปิด MUA เพื่อตรวจสอบอีเมลของคุณ อีเมลถูกส่งโดยตัวแทนจัดส่งทางไปรษณีย์ (MDA) ซึ่งโดยทั่วไปจะรวมอยู่ใน MTA

เมลเคยถูกส่งไปยังเซิร์ฟเวอร์เมลโดยใช้ SMTP หรือ Simple Mail Transfer Protocol SMTP เป็นโปรโตคอลการสื่อสารสำหรับอีเมล

แม้ในขณะนี้ แม้ว่าระบบที่เป็นกรรมสิทธิ์หลายอย่าง เช่น Microsoft Exchange และโปรแกรมเว็บเมล เช่น Gmail จะใช้โปรโตคอลของตนเองภายใน ระบบก็ใช้ SMTP เพื่อถ่ายโอนข้อความนอกระบบ (เช่น หากผู้ใช้ Gmail ต้องการส่งอีเมลไปยังไคลเอนต์ Outlook)

จากนั้นเมลจะถูกดาวน์โหลดจากเซิร์ฟเวอร์โดยใช้ Post Office Protocol (POP3) POP3 เป็นโปรโตคอลระดับแอปพลิเคชันซึ่งให้การเข้าถึงผ่านเครือข่ายอินเทอร์เน็ตโปรโตคอล (IP) สำหรับแอปพลิเคชันผู้ใช้เพื่อติดต่อกับกล่องจดหมายบนเซิร์ฟเวอร์เมล มันสามารถเชื่อมต่อ ดึงข้อความ เก็บไว้ในคอมพิวเตอร์ของลูกค้า และลบหรือเก็บรักษาไว้บนเซิร์ฟเวอร์

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

ตอนนี้ IMAP ซึ่งเป็น Internet Message Access Protocol ได้เข้ามาแทนที่ POP3 เป็นส่วนใหญ่ IMAP สามารถอนุญาตให้ไคลเอ็นต์หลายเครื่องจัดการกล่องจดหมายเดียวกันได้ (เพื่อให้คุณสามารถอ่านอีเมลจากเดสก์ท็อป แล็ปท็อป และโทรศัพท์ ฯลฯ และข้อความทั้งหมดของคุณจะอยู่ที่นั่น โดยจัดระเบียบในลักษณะเดียวกัน)

ในที่สุด เว็บเมลก็เข้ามาแทนที่ทั้งคู่ เว็บเมลช่วยให้คุณลงชื่อเข้าใช้เว็บไซต์และรับข้อความจากทุกที่หรืออุปกรณ์ใดก็ได้ (ใช่แล้ว!) อย่างไรก็ตาม คุณต้องเชื่อมต่ออินเทอร์เน็ตขณะใช้งาน หากเว็บไซต์ (เช่น gmail) เป็น MUA ของคุณ คุณไม่จำเป็นต้องทราบการตั้งค่าเซิร์ฟเวอร์ SMTP หรือ IMAP

อีเมลมีความปลอดภัยอย่างไร

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

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

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

สถานที่ส่วนใหญ่ใช้ TLS (การรักษาความปลอดภัยเลเยอร์การขนส่ง การแทนที่ SSL การรักษาความปลอดภัยเลเยอร์ซ็อกเก็ต) โปรโตคอลการเข้ารหัสที่ให้การเข้ารหัสระหว่างการส่ง ให้การป้องกันเมื่อมีการส่งข้อความ แต่ไม่ใช่เมื่อข้อมูลหยุดนิ่ง (เช่น ถูกเก็บไว้ในคอมพิวเตอร์ของคุณ)

เพื่อให้แน่ใจว่าข้อความจะไม่ถูกแก้ไขหรือสอดแนมในขณะที่เดินทางจาก MTA ไปยัง MTA อย่างไรก็ตาม การดำเนินการนี้ไม่ได้ยืนยันว่าไม่มีการแก้ไขข้อความระหว่างการเดินทาง

ตัวอย่างเช่น หากอีเมลส่งผ่านเซิร์ฟเวอร์อีเมลหลายเซิร์ฟเวอร์ก่อนที่จะถึงปลายทาง การใช้ TLS จะช่วยให้มั่นใจได้ว่ามีการเข้ารหัสระหว่างเซิร์ฟเวอร์ แต่แต่ละเซิร์ฟเวอร์สามารถเปลี่ยนแปลงเนื้อหาข้อความได้ เพื่อแก้ไขปัญหานั้น เราได้สร้าง SPF, DKIM และ DMARC

SPF (กรอบนโยบายผู้ส่ง)

SPF อนุญาตให้เจ้าของโดเมน (เช่น google.com) ตั้งค่าระเบียน TXT ใน DNS ซึ่งระบุว่าเซิร์ฟเวอร์ใดได้รับอนุญาตให้ส่งอีเมลจากโดเมนนั้น (สำหรับคำแนะนำเกี่ยวกับวิธีการทำเช่นนี้สำหรับผู้ให้บริการโฮสต์หลายราย โปรดดูที่ เว็บไซต์)

ทำงานอย่างไร

บันทึกนี้แสดงรายการอุปกรณ์ (โดยทั่วไปตาม IP) ที่อนุญาตและสามารถลงท้ายด้วยตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้:

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

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

~all =หากการตรวจสอบล้มเหลว (แหล่งที่มาของอีเมลไม่ใช่หนึ่งในอุปกรณ์ที่อยู่ในรายการ) ผลลัพธ์จะเป็น SoftFail ซึ่งหมายความว่าข้อความนี้น่าสงสัย แต่ก็ไม่จำเป็นต้องเป็นข้อความที่ทราบกันดีอยู่แล้ว ระบบอีเมลบางระบบจะทำเครื่องหมายข้อความเหล่านี้เป็นสแปม แต่ส่วนใหญ่จะไม่ทำเครื่องหมาย

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

1. SPF ไม่ได้บอกเซิร์ฟเวอร์อีเมลว่าต้องทำอย่างไรกับข้อความ หมายความว่าข้อความอาจล้มเหลวในการตรวจสอบ SPF และยังส่งได้
2. ระเบียน SPF ไม่ได้ดูที่อยู่ 'จาก' ที่ผู้ใช้เห็น แต่กำลังดูที่ 'เส้นทางส่งคืน' โดยพื้นฐานแล้วจะเทียบเท่ากับที่อยู่ผู้ส่งที่คุณเขียนในจดหมาย มันบอกเซิร์ฟเวอร์อีเมลที่จัดการจดหมายที่จะส่งคืนข้อความ (และจะถูกเก็บไว้ในส่วนหัวของอีเมล - โดยพื้นฐานแล้วเซิร์ฟเวอร์ข้อมูลทางเทคนิคใช้ในการประมวลผลอีเมล)
   นั่นหมายความว่าฉันสามารถใส่อะไรก็ได้ที่ต้องการลงในที่อยู่จาก:และจะไม่ส่งผลต่อการตรวจสอบ SPF อันที่จริง ที่อยู่อีเมลทั้งสองนั้นสามารถปลอมแปลงได้โดยแฮ็กเกอร์ เนื่องจากไม่มีการเข้ารหัสที่เกี่ยวข้อง ส่วนหัว SPF จึงไม่น่าเชื่อถืออย่างสมบูรณ์
3. บันทึก SPF จำเป็นต้องอัปเดตอยู่เสมอ ซึ่งอาจเป็นเรื่องยากในองค์กรขนาดใหญ่ที่เปลี่ยนแปลงตลอดเวลา
4. การส่งต่อแบ่งค่า SPF เนื่องจากหากอีเมลจาก google.com ถูกส่งต่อโดย bob@bobsburgers.com ผู้ส่งซองจดหมายจะยังคงไม่เปลี่ยนแปลง (ที่อยู่ต้นทางยังคงเป็น google.com) เซิร์ฟเวอร์อีเมลที่รับคิดว่าอ้างว่ามาจาก google.com แต่มาจาก bobsburgers.com ดังนั้นจึงไม่ผ่านการตรวจสอบ SPF (แม้ว่าจริงๆ แล้วอีเมลจะมาจาก google.com)

สำหรับการอ่านเพิ่มเติมเกี่ยวกับ SPF โปรดดูบทความเหล่านี้ คุณสามารถตรวจสอบว่าโดเมนใดมีระเบียน SPF และ DMARC ที่กำหนดค่าไว้ที่นี่

DKIM (เมลที่ระบุโดเมนคีย์)

DKIM นั้นคล้ายกับ SPF ใช้ระเบียน TXT ใน DNS ของโดเมนที่ส่งด้วย และให้การรับรองความถูกต้องของข้อความด้วย จะพยายามยืนยันว่าข้อความไม่ได้ถูกแก้ไขระหว่างการส่ง

ทำงานอย่างไร

โดเมนที่ส่งจะสร้างคู่คีย์สาธารณะ/ส่วนตัวและใส่คีย์สาธารณะในระเบียน DNS TXT ของโดเมน (หากคุณไม่ทราบว่าคู่คีย์สาธารณะ/ส่วนตัวคืออะไร โปรดดูบทความเกี่ยวกับการเข้ารหัสนี้)

จากนั้นเซิร์ฟเวอร์อีเมลของโดเมน (ที่ขอบด้านนอก - เซิร์ฟเวอร์ที่ส่งจดหมายนอกโดเมน (เช่น จาก gmail.com ไปยัง outlook.com)) จะใช้คีย์ส่วนตัวเพื่อสร้างลายเซ็นของเนื้อหาข้อความทั้งหมด รวมถึง ส่วนหัว

การสร้างลายเซ็นมักต้องการการแฮชและเข้ารหัสข้อความ (สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการนี้ โปรดดูบทความนี้)

การรับเซิร์ฟเวอร์อีเมลใช้กุญแจสาธารณะในระเบียน DNS TXT เพื่อถอดรหัสลายเซ็น จากนั้นแฮชข้อความและส่วนหัวที่เกี่ยวข้อง (ส่วนหัวใดๆ ที่สร้างขึ้นในขณะที่อีเมลอยู่ในโครงสร้างพื้นฐานของผู้ส่ง - ตัวอย่างเช่น หากเซิร์ฟเวอร์ Gmail หลายเซิร์ฟเวอร์ประมวลผลอีเมลก่อนหน้านั้น ถูกส่งไปยัง outlook.com ภายนอก)

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

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

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

สำหรับการอ่านเพิ่มเติมเกี่ยวกับ DKIM โปรดดูบทความนี้ คุณตรวจสอบระเบียน DKIM ได้ที่นี่

DMARC (การตรวจสอบความถูกต้องของข้อความตามโดเมน การรายงาน และความสอดคล้อง)

DMARC เป็นคำแนะนำหลักสำหรับเซิร์ฟเวอร์อีเมลเกี่ยวกับวิธีจัดการระเบียน SPF และ DKIM ไม่ได้ทำการทดสอบใดๆ ในตัวมันเอง แต่จะบอกเซิร์ฟเวอร์อีเมลถึงวิธีจัดการกับการตรวจสอบที่ SPF และ DKIM ดำเนินการ

ISP ที่เข้าร่วมจะดูระเบียน DMARC ที่เผยแพร่และใช้เพื่อกำหนดวิธีจัดการกับ DKIM หรือ SPF ล้มเหลว ตัวอย่างเช่น แบรนด์ที่หลอกลวงโดยทั่วไปอาจเผยแพร่ระเบียน DMARC ซึ่งระบุว่าหาก DKIM หรือ SPF ล้มเหลว ให้วางข้อความนั้น

บ่อยครั้งที่ ISP จะส่งรายงานเกี่ยวกับกิจกรรมในโดเมนของคุณพร้อมแหล่งที่มาของอีเมลและแจ้งว่า DKIM/SPF นั้นผ่าน/ไม่ผ่านหรือไม่ ซึ่งหมายความว่าคุณจะได้เห็นเมื่อมีคนปลอมแปลง (อ้างว่าส่งมาจาก) โดเมนของคุณหรือแก้ไขข้อความของคุณ

ในการนำ DMARC ไปใช้ คุณจะต้องสร้างระเบียน DMARC ตามความต้องการของคุณ (ตั้งแต่การตรวจสอบปริมาณการใช้อีเมลเพื่อค้นหาว่าแหล่งที่มาของอีเมลทั้งหมดมีอะไรบ้าง ไปจนถึงขอให้ดำเนินการ เช่น การปฏิเสธอีเมลที่ล้มเหลวใน DKIM หรือ SPF) คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับการทำเช่นนั้นได้ที่นี่และที่นี่

สำหรับการอ่านเพิ่มเติมเกี่ยวกับ DMARC โปรดดูบทความนี้ คุณสามารถตรวจสอบว่าโดเมนใดมีการกำหนดค่าระเบียน SPF และ DMARC ที่นี่

สรุป

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

ยิ่งองค์กรที่ใช้มาตรการเหล่านี้ (ไม่ว่าจะใช้การใช้งานโอเพ่นซอร์สหรือจ่ายเงินเพื่อซื้อผลิตภัณฑ์) มากเท่าไร ทุกคนก็จะยิ่งดีขึ้นเท่านั้น การรักษาความปลอดภัยที่เพิ่มเข้ามาหลังจากพัฒนาโปรโตคอลหรือผลิตภัณฑ์มักจะมีราคาแพงกว่า มีประสิทธิภาพน้อยกว่า และใช้งานยากกว่าการรักษาความปลอดภัยที่มีอยู่ในผลิตภัณฑ์

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

ดังนั้น เนื่องจากอินเทอร์เน็ตมีการขยายตัวอย่างต่อเนื่อง เราจึงต้องปรับตัวและพัฒนาวิธีการใหม่ๆ ในการรักษาความปลอดภัยของระบบที่เราพึ่งพาต่อไป