เจาะลึกที่อยู่อีเมล

 (lasans.blog)
4 คะแนน โดย GN⁺ 2 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • ที่อยู่อีเมลไม่ใช่แค่การรวมกันของชื่อผู้ใช้กับโดเมนเท่านั้น แต่เป็นระบบที่มี โครงสร้างและกฎที่ซับซ้อนตามมาตรฐาน RFC รวมถึงกับดักด้านความปลอดภัย
  • ใน local part (ส่วนหน้า @) มี รูปแบบที่ถูกต้องได้หลากหลาย ซึ่งคนทั่วไปไม่ค่อยรู้จัก เช่น รูปแบบใส่เครื่องหมายอัญประกาศ คอมเมนต์ และ Unicode แต่ส่วนใหญ่ไม่รองรับในสภาพแวดล้อมการใช้งานจริง
  • อีเมลทุกฉบับมี ที่อยู่ผู้ส่งสองแบบคือ Envelope Sender และส่วนหัว From และความแตกต่างนี้คือสาเหตุพื้นฐานของการปลอมแปลงและฟิชชิง
  • พฤติกรรมเฉพาะของผู้ให้บริการ เช่น นโยบายไม่สนใจจุด (dot) ของ Gmail, การกำหนดที่อยู่แบบบวก และโดเมนนามแฝง ส่งผลโดยตรงต่อความปลอดภัยและการตรวจสอบความถูกต้อง
  • เมื่อต้องสร้างระบบสำหรับเก็บรวบรวมหรือตรวจสอบที่อยู่อีเมล การเข้าใจ ช่องว่างระหว่างมาตรฐาน RFC กับการทำงานจริงอย่างแม่นยำเป็นสิ่งจำเป็น

โครงสร้างพื้นฐาน

  • ที่อยู่อีเมลประกอบด้วย 3 ส่วนคือ local part (หน้า @), ตัวคั่น @, และ โดเมน (หลัง @)
  • แม้ภายนอกจะดูเรียบง่าย แต่แต่ละส่วนมีกฎและ edge case ที่ส่งผลต่อความปลอดภัย ความเป็นส่วนตัว และการตรวจสอบความถูกต้อง

Local Part

  • อักขระที่อนุญาต

    • อักขระที่อนุญาตในรูปแบบมาตรฐานแบบไม่ใส่เครื่องหมายอัญประกาศ (dot-atom) ได้แก่ ตัวอักษรภาษาอังกฤษ a-z, A-Z, ตัวเลข 0-9, อักขระพิเศษ . _ - + ! # $ % & ' * / = ? ^ { | } ~
    • ความยาวสูงสุดคือ 64 octet โดยใน ASCII มาตรฐานจะเท่ากับ 64 อักขระ แต่ใน local part แบบ Unicode จะเกิดความแตกต่าง
      • octet หมายถึงกลุ่ม 8 บิตพอดี และใช้ในงานเครือข่าย (IPv4) เพื่อแทนช่วงค่า 0~255
      • 64 octet เทียบเท่ากับบล็อกข้อมูลความยาว 512 บิต

  • การแยกพิมพ์เล็กพิมพ์ใหญ่

    • ตาม RFC 5321 local part นั้นในทางเทคนิค แยกพิมพ์เล็กพิมพ์ใหญ่ ดังนั้น User@example.com และ user@example.com อาจเป็นคนละกล่องจดหมาย
    • ในทางปฏิบัติ ผู้ให้บริการอีเมลรายใหญ่ทั้งหมดไม่แยกพิมพ์เล็กพิมพ์ใหญ่ ดังนั้น การทำให้เป็นตัวพิมพ์เล็กก่อนจัดเก็บหรือเปรียบเทียบจึงเป็นค่าเริ่มต้นที่ปลอดภัย
    • ส่วนโดเมนจะไม่แยกพิมพ์เล็กพิมพ์ใหญ่เสมอ

  • การกำหนดที่อยู่ด้วยจุด (Dot)

    • อนุญาตให้ใช้จุดใน local part ได้ แต่มีข้อจำกัด 3 ข้อ: ห้ามขึ้นต้นด้วยจุด, ห้ามลงท้ายด้วยจุด, และ ห้ามมีจุดติดกัน
    • การ normalize จุดของ Gmail: Gmail จะมองข้ามจุดทั้งหมดใน local part ดังนั้น johndoe@gmail.com, john.doe@gmail.com, j.o.h.n.d.o.e@gmail.com จะถูกส่งไปยังกล่องจดหมายเดียวกันทั้งหมด
      • นี่เป็นพฤติกรรมเฉพาะของ Gmail ไม่ใช่มาตรฐาน RFC
      • เป็นช่องทางโจมตีที่ใช้งานได้จริง โดยผู้โจมตีอาจสร้างบัญชีแยกด้วยที่อยู่ที่แปลงจุดแล้วเพื่อ เลี่ยงข้อจำกัดบัญชีเดียว หรือรับช่วงทดลองใช้ฟรีซ้ำ

  • Subaddressing (การกำหนดที่อยู่แบบบวก)

    • สามารถเพิ่มแท็กใน local part โดยใช้ตัวคั่นได้ และเซิร์ฟเวอร์เมลจะส่งต่อไปยังที่อยู่หลักพร้อมคงแท็กไว้ (มาตรฐาน RFC 5233)
    • ตัวคั่นที่พบบ่อยที่สุดคือ + และรองรับใน Gmail, Outlook, ProtonMail, Fastmail เป็นต้น
      • ในบางการตั้งค่าของ Yahoo และ Postfix บางแบบจะใช้ -
      • ใน qmail ค่าเริ่มต้นคือ = และนี่คือเหตุผลที่ VERP เข้ารหัส @ เป็น =
    • กรณีการใช้งานหลัก:
      • ติดตามการรั่วไหล: สมัครบริการด้วยแท็กเฉพาะรายบริการ (เช่น yourname+servicename@gmail.com) เพื่อระบุแหล่งที่มาหากได้รับสแปม
      • กรองกล่องจดหมาย: ใช้กฎเมลเพื่อจัดหมวดหมู่อีเมลที่ส่งถึงที่อยู่แท็กเฉพาะโดยอัตโนมัติ
      • หลายบัญชี: สามารถสร้างบัญชีแยกด้วยอีเมลเดียวกันได้ในบริการที่ไม่ normalize เครื่องหมายบวก
    • ตัวตรวจสอบความถูกต้องของอีเมลบนหลายเว็บไซต์ปฏิเสธ + แต่สิ่งนี้คือ บั๊กของโค้ดตรวจสอบ ไม่ใช่ข้อจำกัดของอีเมล

  • รูปแบบสตริงแบบใส่เครื่องหมายอัญประกาศ (Quoted String Form)

    • หากครอบ local part ด้วยอัญประกาศคู่ ข้อจำกัดของอักขระส่วนใหญ่จะถูกผ่อนคลาย ทำให้สามารถใช้ช่องว่าง, @, จุดติดกัน รวมถึงจุดนำหน้าและลงท้ายได้
    • ตัวอย่าง: "john doe"@example.com, "user@name"@example.com, " "@example.com
    • ในทางปฏิบัติ ผู้ให้บริการอีเมลแทบทั้งหมดไม่รับ local part แบบใส่อัญประกาศ ดังนั้นแม้จะ ถูกต้องตาม RFC แต่ใช้จริงแทบไม่ได้

  • คอมเมนต์ (Comments)

    • คอมเมนต์ในวงเล็บสามารถอยู่ที่ต้นหรือท้ายของ local part ได้ และเซิร์ฟเวอร์เมลจะลบออกโดยไม่กระทบต่อการส่ง
    • แม้จะถูกต้องในทางเทคนิคตาม RFC 5322 แต่ปัจจุบันแทบไม่ใช้แล้ว
    • ตัวตรวจสอบความถูกต้องที่ปฏิเสธวงเล็บนั้น เข้มงวดกว่า RFC

  • local part แบบ Unicode (EAI)

    • Email Address Internationalization (EAI) ตามที่กำหนดไว้ใน RFC 6530, 6531, 6532 อนุญาตให้ใช้ตัวอักษร UTF-8 ใน local part
    • ต้องใช้ส่วนขยาย SMTPUTF8 ในเซสชัน SMTP และทั้งเซิร์ฟเวอร์ฝั่งส่งและรับต้องรองรับ
    • ณ ปี 2026 การนำไปใช้ยังมีจำกัด และเนื่องจากอักขระ Unicode ใช้ 2~4 octet จึงอาจชนขีดจำกัด 64 octet ได้ก่อนจำนวนอักขระที่มองเห็น

  • รูปแบบทางประวัติศาสตร์

    • Bang path (UUCP): วิธี routing ที่ใช้เส้นทางชื่อโฮสต์คั่นด้วย ! (machine1!machine2!user) บนเครือข่ายเครื่อง Unix ที่เชื่อมต่อผ่านโมเด็มก่อนยุค DNS ซึ่งเป็นเหตุผลที่ ! อยู่ในรายการอักขระที่อนุญาต ปัจจุบันเลิกใช้โดยสมบูรณ์แล้ว
    • Percent hack: กลเม็ด relay routing รูปแบบ user%otherdomain@relay.com โดยอักขระ % ยังคงใช้ได้ใน local part แม้กลไก routing นี้จะถูกยกเลิกใน RFC 5321 แล้ว
    • Source routing: รายการ relay hop แบบระบุชัดในคำสั่ง SMTP RCPT TO (@relay1,@relay2:user@domain) ถูกยกเลิกใน RFC 5321

  • VERP (Variable Envelope Return Path)

    • เทคนิคในระบบอีเมลปริมาณมากเพื่อ ติดตามผู้รับที่แน่ชัด ซึ่งทำให้เกิด bounce
    • จะเข้ารหัสที่อยู่ผู้รับไว้ใน envelope sender (MAIL FROM) โดยแทน @ ของที่อยู่ผู้รับด้วย =
      • ตัวอย่าง: bounces+alice=gmail.com@newsletter.com
    • Mailchimp, SendGrid, Amazon SES และรายอื่น ๆ ใช้ VERP หรือรูปแบบดัดแปลงสำหรับจัดการ bounce ในปริมาณมาก

  • SRS (Sender Rewriting Scheme)

    • รูปแบบที่อยู่ที่เกิดขึ้นเมื่อเซิร์ฟเวอร์ส่งต่ออีเมลแล้ว เขียน envelope sender ใหม่เพื่อให้ผ่านการตรวจสอบ SPF
    • อยู่ในรูปแบบ SRS0=HASH=TT=originaldomain.com=originaluser@forwardingdomain.com
    • หากมีการส่งต่อหลาย hop จะอยู่ในรูปแบบ SRS1=HASH=encodedSRS0@forwardingdomain.com
    • แม้จะเป็นที่อยู่อีเมลที่ถูกต้องตามโครงสร้าง แต่เป็น ผลลัพธ์จากระบบโครงสร้างพื้นฐาน ไม่ใช่ที่อยู่ที่มนุษย์ใช้งาน
    • ส่วนประกอบ HASH คือ HMAC ของ timestamp และที่อยู่ต้นทาง ทำหน้าที่ป้องกันการปลอมแปลงและจำกัดอายุการใช้งานของโทเค็น

ส่วนโดเมน (Domain Part)

  • กฎของเลเบล

    • โดเมนประกอบด้วยเลเบลที่คั่นด้วยจุด โดยในแต่ละเลเบลอนุญาตให้ใช้ตัวอักษรอังกฤษ a-z, ตัวเลข 0-9, และขีดกลาง -
    • ห้ามขึ้นต้นหรือลงท้ายด้วยขีดกลาง และห้ามมีขีดกลางติดกันในตำแหน่งที่ 3~4 (ยกเว้น Punycode label ที่ขึ้นต้นด้วย xn--)
    • เลเบลยาวได้สูงสุด 63 อักขระ, โดเมนทั้งชุดยาวได้สูงสุด 253 อักขระ, และที่อยู่อีเมลทั้งหมด (addr-spec) ยาวได้สูงสุด 254 อักขระ

  • ซับโดเมน

    • โดเมนสามารถมีได้หลายระดับ และนอกจากความยาวรวมของโดเมนที่ 253 อักขระแล้ว ก็ไม่มีข้อจำกัดแบบตายตัวทางเทคนิคเกี่ยวกับความลึกของซับโดเมน
    • การใช้งานทั่วไป: โครงสร้างพื้นฐานเมล(mail., smtp., mx.), การแยกองค์กร(sales.company.com), การส่งผ่าน ESP(email.company.com)

  • IP address literal

    • สามารถใช้ที่อยู่ IP ในวงเล็บเหลี่ยมแทนชื่อโดเมนได้: user@[192.168.1.1], user@[IPv6:2001:db8::1]
    • แม้จะใช้ได้ตาม RFC 5321 แต่แทบไม่ถูกรับโดยเมลเซิร์ฟเวอร์สาธารณะ และใช้กับ ระบบเมลภายในและการทดสอบ SMTP

  • โดเมนแบบเลเบลเดียว

    • โดเมนที่ไม่มีจุด (เช่น user@localhost) มีผลใช้ได้ทางเทคนิคในบางบริบท แต่เมลเซิร์ฟเวอร์สาธารณะจะปฏิเสธ
    • postmaster@localhost เป็น กรณีพิเศษตามธรรมเนียมของเมลระบบภายในเครื่อง บนระบบตระกูล Unix

  • ชื่อโดเมนสากล (IDN) และ Punycode

    • เนื่องจาก DNS รองรับเฉพาะ ASCII อักขระที่ไม่ใช่ ASCII จึงถูกเข้ารหัสเป็น Punycode (RFC 3492) และทุกเลเบลที่เข้ารหัสจะขึ้นต้นด้วยคำนำหน้า xn--
    • ไคลเอนต์อีเมลจะแสดงผลเป็นสคริปต์ดั้งเดิม ส่วน SMTP จะส่งในรูปแบบ Punycode
    • การโจมตีแบบ homograph: สามารถจดทะเบียนโดเมนที่คล้ายโดเมนที่รู้จักกันดีได้ โดยใช้อักขระจากสคริปต์ยูนิโคดอื่นที่มองเห็นเหมือนกัน เบราว์เซอร์มีฟีเจอร์ป้องกันโดยแสดง Punycode สำหรับ IDN ที่น่าสงสัย แต่ ไคลเอนต์อีเมลส่วนใหญ่ไม่มีการป้องกันแบบนี้ ทำให้การโจมตีผ่านอีเมลได้ผลมากกว่า

  • จุดท้ายโดเมน (Trailing Dot)

    • ใน DNS ทุกโดเมนจะลงท้ายด้วยจุดท้ายที่สื่อถึง root zone ในเชิงเทคนิค แต่สำหรับอีเมลจะถือว่ามีโดยปริยายและละไว้เสมอ
    • ตัวตรวจสอบความถูกต้องส่วนใหญ่จะปฏิเสธรูปแบบ user@example.com.

  • ระเบียน MX

    • โดเมนของที่อยู่อีเมลไม่จำเป็นต้องเป็นตำแหน่งของเมลเซิร์ฟเวอร์เสมอไป โดยเซิร์ฟเวอร์ต้นทางจะค้นหา ระเบียน DNS แบบ MX(Mail Exchanger) เพื่อดูชื่อโฮสต์ของเมลเซิร์ฟเวอร์จริง
    • หมายเลขลำดับความสำคัญที่ต่ำกว่าจะหมายถึงลำดับความสำคัญที่สูงกว่า และถ้าไม่มีระเบียน MX เลย จะ fallback ไปใช้ระเบียน A ของโดเมน
    • หากโดเมนไม่ควรรับอีเมลโดยเด็ดขาด สามารถประกาศ null MX record(MX 0 .) เพื่อแจ้งอย่างชัดเจนให้เซิร์ฟเวอร์ต้นทางไม่ต้องพยายามส่งต่อ (RFC 7505)

โดเมนระดับบนสุด (TLD)

  • gTLD ทั่วไปดั้งเดิม

    • gTLD 7 รายการของอินเทอร์เน็ตยุคแรก: .com(เชิงพาณิชย์, ปัจจุบันไม่จำกัด, ดำเนินการโดย Verisign), .net(เครือข่าย, ไม่จำกัด), .org(องค์กร, ไม่จำกัด), .edu(สถาบันการศึกษาที่ได้รับการรับรองในสหรัฐฯ, จำกัด), .gov(รัฐบาลสหรัฐฯ, จำกัด), .mil(กองทัพสหรัฐฯ, จำกัด), .int(องค์การระหว่างประเทศตามสนธิสัญญา, จำกัดมาก)
    • .arpa เป็น TLD สำหรับโครงสร้างพื้นฐาน ที่ดูแลโดย IANA และใช้ในการค้นหา DNS ย้อนกลับ

  • country code TLD (ccTLD)

    • เป็นรหัส 2 ตัวอักษรตามรหัสประเทศ ISO 3166-1 alpha-2 มีอยู่ราว 250 รายการ
    • ccTLD บางส่วนถูกนำไปใช้ใหม่โดยอุตสาหกรรมอื่น:
      • .io(British Indian Ocean Territory → บริษัทเทค), .tv(ตูวาลู → สื่อ·สตรีมมิง), .ai(แองกวิลลา → บริษัท AI), .co(โคลอมเบีย → ทางเลือกของ .com), .me(มอนเตเนโกร → เว็บไซต์ส่วนตัว), .ly(ลิเบีย → ย่อ URL), .sh(เซนต์เฮเลนา → โครงการซอฟต์แวร์)
    • หากใช้ ccTLD ที่ถูกเปลี่ยนวัตถุประสงค์เหล่านี้ ในทางเทคนิคจะถือว่าอยู่ภายใต้ เขตอำนาจของ registry ของประเทศนั้น และโดเมนจะถูกควบคุมโดย registry ของประเทศต้นทาง ไม่ใช่ ICANN

  • sponsored TLD (sTLD)

    • TLD ที่มีองค์กรผู้สนับสนุนและมีคุณสมบัติการลงทะเบียน: .aero(การขนส่งทางอากาศ, สนับสนุนโดย SITA), .coop(สหกรณ์), .museum(พิพิธภัณฑ์), .jobs(การจ้างงาน), .xxx(ผู้ใหญ่), .post(ไปรษณีย์), .cat(ภาษาคาตาลัน·วัฒนธรรม)

  • gTLD ใหม่ (ตั้งแต่ปี 2012)

    • ในปี 2012 ICANN เปิดรับสมัคร gTLD ใหม่ ทำให้มีการมอบหมาย TLD ใหม่ มากกว่า 1,200 รายการ
    • ผลกระทบสำคัญต่อการตรวจสอบความถูกต้องของอีเมล: ตัวตรวจสอบที่จำกัดความยาว TLD ไว้ที่ 4~6 ตัวอักษรจะ ใช้งานพัง (.photography, .international, .construction เป็นต้น)
    • สำหรับนักพัฒนา: .app, .dev, .web, .code / เชิงพาณิชย์: .shop, .store, .online / คอนเทนต์: .blog, .news, .media / ธุรกิจ: .tech, .agency, .cloud
    • gTLD ใหม่มี สัดส่วนสูงเกินจริงในการถูกใช้กับสแปมและฟิชชิง เนื่องจากค่าจดทะเบียนต่ำและนโยบายต่อต้านการใช้งานในทางที่ผิดของบาง registry ที่อ่อนแอ

  • brand TLD

    • ในการขยายของ ICANN ปี 2012 บริษัทขนาดใหญ่ได้ยื่นขอ TLD ของตนเอง: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
    • ส่วนใหญ่ไม่ได้ใช้เป็นที่อยู่อีเมลสาธารณะ และมักใช้เพื่อ วัตถุประสงค์ภายใน หรือไม่ได้ใช้งานเลย

  • TLD ภูมิศาสตร์·เมือง

    • เมืองและภูมิภาคมี TLD ของตนเอง: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
    • เมื่อลงทะเบียน มักต้อง พิสูจน์ความเกี่ยวข้องกับพื้นที่นั้น

  • TLD สากล

    • หลายประเทศมี TLD ที่ใช้สคริปต์ที่ไม่ใช่ ASCII ซึ่งใน DNS จะถูกเข้ารหัสเป็น Punycode
      • .xn--p1ai(รัสเซีย, อักษรซีริลลิก), .xn--fiqz9s(จีน, อักษรจีนตัวย่อ), .xn--mgberp4a5d4ar(ซาอุดีอาระเบีย, อักษรอาหรับ), .xn--h2brj9c(อินเดีย, อักษรเทวนาครี)

  • TLD ที่สงวนไว้·ใช้สำหรับเอกสาร

    • TLD ที่ RFC 2606 และ RFC 6761 สงวนไว้เพื่อการทดสอบและการจัดทำเอกสาร:
      • .test(ไม่มีอยู่จริงใน DNS สาธารณะ จึงปลอดภัยสำหรับการทดสอบซอฟต์แวร์), .example(สำหรับตัวอย่างในเอกสาร), .invalid(เมื่อต้องการโดเมนที่แน่นอนว่าไม่สามารถ resolve ได้), .localhost(สำหรับ loopback)
    • IANA ได้จดทะเบียน example.com, example.net, example.org ไว้สำหรับเอกสารและตัวอย่าง ทำให้สามารถใช้ในตัวอย่างโค้ดได้อย่างอิสระโดยไม่ต้องกังวลว่าจะไปถึงกล่องจดหมายจริง

  • TLD ที่ถูกยกเลิก

    • ccTLD ที่ถูกลบเพราะประเทศสิ้นสภาพ: .yu(ยูโกสลาเวีย, ลบในปี 2010), .cs(เชโกสโลวะเกีย, ลบในปี 1995), .dd(เยอรมนีตะวันออก, ลบในปี 1990), .tp(ติมอร์ตะวันออก, ถูกแทนที่ด้วย .tl และลบสมบูรณ์ในปี 2015)
    • ข้อยกเว้น: .su(สหภาพโซเวียต) ยังคงมีโดเมนที่ใช้งานอยู่แม้สลายตัวไปตั้งแต่ปี 1991 และแม้ IANA จะหารือเรื่องการเปลี่ยนผ่านมาหลายปี ก็ยังคงสถานะ active อยู่

โดเมนระดับที่สองของ ccTLD

  • ccTLD จำนวนมากเพิ่มหมวดหมู่ระดับที่สองเชิงหน้าที่ไว้ระหว่างชื่อที่จดทะเบียนได้กับ TLD
    • สหราชอาณาจักร: .co.uk, .org.uk, .gov.uk / ออสเตรเลีย: .com.au, .edu.au / ญี่ปุ่น: .co.jp, .ac.jp / อินเดีย: .co.in, .gov.in / บราซิล: .com.br, .gov.br
  • ในระบบยืนยันอีเมล เมื่อ ต้องค้นหา organizational domain จะส่งผลต่อการตรวจสอบความถูกต้องและการตรวจจับ organizational domain

  • Public Suffix List (PSL)

    • เป็นรายการที่ชุมชนดูแลที่ publicsuffix.org ซึ่งรวบรวม ส่วนต่อท้ายโดเมน ทั้งหมดที่ผู้ใช้อินเทอร์เน็ตสามารถจดทะเบียนชื่อได้โดยตรง
    • ครอบคลุมทั้งการมอบหมายอย่างเป็นทางการ (.co.uk, .com.au) และรีจิสทรีแบบส่วนตัว (github.io, wordpress.com, herokuapp.com)
    • ใช้สัญลักษณ์ wildcard (เช่น *.ck) และใช้ ! เพื่อระบุข้อยกเว้น (เช่น !www.ck)
    • ตัวตรวจสอบความถูกต้องของอีเมลและตัวกรองสแปมใช้เพื่อ ระบุ organizational domain จากสตริงโดเมนทั้งหมด
    • แม้จะไม่ใช่มาตรฐาน IETF แต่เป็น มาตรฐานโดยพฤตินัย (de facto standard) สำหรับปัญหานี้

รูปแบบฟอร์แมตของที่อยู่อีเมล

  • ที่อยู่พื้นฐาน (Bare Address)

    • เป็น addr-spec ในรูปแบบ local@domain ใช้ในคำสั่ง SMTP และบริบทแบบเรียบง่าย

  • รูปแบบวงเล็บมุม

    • ใน SMTP คำสั่ง MAIL FROM และ RCPT TO จะ ครอบที่อยู่ด้วยวงเล็บมุม: MAIL FROM:<sender@example.com>
    • วงเล็บมุมเป็นส่วนหนึ่งของไวยากรณ์คำสั่ง SMTP ไม่ใช่ส่วนหนึ่งของตัวที่อยู่เอง

  • รูปแบบชื่อที่แสดง (Display Name Format)

    • ในส่วนหัวข้อความ (From, To, Cc) สามารถมีชื่อที่มนุษย์อ่านได้อยู่หน้าที่อยู่ในวงเล็บมุม: "John Doe" <john@example.com>
    • หากชื่อที่แสดงมีอักขระพิเศษ ต้องใส่เครื่องหมายอัญประกาศ
    • การปลอมชื่อที่แสดง: ผู้ส่งสามารถตั้งชื่อที่แสดงได้ตามต้องการ จึงเกิดการโจมตีในรูปแบบ "PayPal Security <paypal@paypal.com>" <attacker@evil.com> ได้
      • ไคลเอนต์อีเมลจำนวนมากแสดงเฉพาะชื่อที่แสดงในรายการกล่องจดหมาย จึงเป็น เทคนิคฟิชชิงที่พบบ่อยที่สุดอย่างหนึ่ง

  • ไวยากรณ์แบบกลุ่ม (Group Syntax)

    • รูปแบบกลุ่มแบบมีชื่อสำหรับผู้รับหลายรายที่กำหนดไว้ใน RFC 5322: Marketing Team: alice@example.com, "Bob Smith" <bob@example.com>;
    • แพตเทิร์นผู้รับแบบไม่เปิดเผย: To: undisclosed-recipients:; — เป็นไวยากรณ์กลุ่มว่าง โดยผู้รับจริงอยู่ในซอง SMTP (RCPT TO) และไม่ปรากฏในส่วนหัวข้อความ

  • ชื่อที่แสดงแบบเข้ารหัส

    • ในระบบอีเมลรุ่นเก่า อักขระที่ไม่ใช่ ASCII ในชื่อที่แสดงจะถูกจัดการด้วย encoded-word ตาม RFC 2047: =?charset?encoding?encoded_text?=
    • การเข้ารหัสใช้ B (base64) หรือ Q (quoted-printable)
    • เมื่อรองรับ SMTPUTF8 ในระบบสมัยใหม่ ก็สามารถใช้ UTF-8 ได้โดยตรงในส่วนหัวโดยไม่ต้องมีตัวห่อหุ้มการเข้ารหัสนี้

ผู้ส่งสองคนในอีเมลทุกฉบับ

  • ผู้ส่งในซอง (Envelope Sender / MAIL FROM)

    • ถูกตั้งค่าจากคำสั่ง SMTP MAIL FROM: และไม่ใช่ส่วนหนึ่งของเนื้อหาข้อความเอง
    • ใช้สำหรับ การกำหนดเส้นทาง bounce เป็นสิ่งที่ตรวจสอบในการตรวจ SPF และเซิร์ฟเวอร์ผู้รับปลายทางจะบันทึกไว้ในส่วนหัว Return-Path:
    • เรียกอีกอย่างว่า envelope from, reverse path, หรือ RFC5321.MailFrom

  • ส่วนหัว From

    • คือที่อยู่ในส่วนหัว From: ของข้อความ ซึ่งเป็นสิ่งที่ไคลเอนต์อีเมล แสดงว่าเป็นผู้ส่ง
    • เป็นสิ่งที่ DMARC ปกป้องร่วมกับการจัดแนว SPF หรือ DKIM
    • ผู้ส่งสามารถกำหนดได้อย่างอิสระ และบนเมลเซิร์ฟเวอร์ส่วนใหญ่ ไม่มีการตรวจสอบเฉพาะตัว
    • ที่อยู่สองนี้อาจต่างกันโดยสิ้นเชิงได้ และนี่เป็นสถานการณ์ที่ปกติและคาดหมายได้:
      • ในการส่งจำนวนมากของ ESP MAIL FROM อาจเป็น bounce@esp.com ส่วนส่วนหัว From เป็น newsletter@yourbrand.com
      • ใน mailing list MAIL FROM เป็นที่อยู่ bounce ของรายการ ส่วนส่วนหัว From เป็นผู้โพสต์ต้นฉบับ
      • ในการส่งต่ออีเมล เซิร์ฟเวอร์ส่งต่ออาจเขียน MAIL FROM ใหม่ด้วย SRS แต่คงส่วนหัว From เป็นผู้ส่งเดิม
    • หากโดเมนไม่ได้ใช้ DMARC ใครก็สามารถส่งโดย ใช้ MAIL FROM ที่ไม่เกี่ยวข้องกันเลย ขณะใส่โดเมนนั้นไว้ในส่วนหัว From ได้

  • ส่วนหัว Sender

    • ใช้ระบุผู้ส่งจริงเมื่อผู้ส่งที่ยื่นข้อความแตกต่างจากที่อยู่ From: Sender: mailer@sendgrid.net

  • ส่วนหัว Reply-To

    • ระบุว่าจะให้การตอบกลับไปที่ใด และอาจแตกต่างจากที่อยู่ From
    • ยังถูกนำไปใช้เป็นเวกเตอร์ฟิชชิงได้ด้วย: ผู้โจมตีตั้งค่า From ให้ดูถูกต้องตามกฎหมาย แล้ว ตั้ง Reply-To เป็นที่อยู่ของตนเอง

  • Null Sender

    • MAIL FROM:<> เป็นโครงสร้าง SMTP ที่ถูกต้องและสำคัญ โดยผู้ส่งในซองที่ว่างจะใช้กับข้อความ bounce การตอบกลับอัตโนมัติ และข้อความที่ไม่ควรสร้าง bounce ซ้อนขึ้นมาเอง
    • เพื่อ ป้องกันลูป bounce ไม่สิ้นสุด ที่สองระบบแลกเปลี่ยนการแจ้งล้มเหลวกันต่อเนื่อง

ที่อยู่แบบบทบาท (Role-Based Addresses)

  • ข้อบังคับของ RFC 5321

    • postmaster@domain: ตาม RFC 5321 ทุกโดเมนที่รับเมลต้อง รับเมลสำหรับที่อยู่นี้เป็นข้อบังคับ ไม่มีข้อยกเว้น

  • คำแนะนำของ RFC 2142

    • abuse@domain (รายงานสแปม/การใช้งานในทางที่ผิด), hostmaster@domain (การจัดการ DNS zone), security@domain (การเปิดเผยช่องโหว่/รายงานความปลอดภัย), webmaster@domain (ปัญหาเว็บเซิร์ฟเวอร์), noc@domain (การปฏิบัติการเครือข่าย)

  • ที่อยู่ตามธรรมเนียมแบบบทบาท

    • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ เป็นต้น แม้ไม่ใช่มาตรฐานทางการ แต่ใช้กันอย่างแพร่หลาย
    • ที่อยู่แบบบทบาทมัก มีหลายคนใช้งานร่วมกัน ดังนั้นเมื่อส่งข้อมูลอ่อนไหว อาจมีสมาชิกทีมหลายคนเข้าถึงได้
    • abuse@ และ postmaster@ รับอีเมลร้องเรียน จึงเป็น เป้าหมายของ social engineering

  • ที่อยู่แบบ Catch-All

    • ไม่ใช่รูปแบบที่อยู่อีเมลเฉพาะ แต่เป็น การตั้งค่าเมลเซิร์ฟเวอร์ ที่ยอมรับการส่งต่อแม้สำหรับ local part ที่ไม่มีกล่องจดหมายเฉพาะ
    • กรณีใช้งาน: ดักจับการพิมพ์ผิด, ทดสอบสำหรับนักพัฒนา, สร้างที่อยู่เฉพาะรายบริการโดยไม่ต้องมีระบบ alias แบบเป็นทางการ
    • ข้อเสีย: เนื่องจาก local part ใดก็ส่งต่อได้ จึง มีสแปมไหลเข้าจำนวนมาก และไม่สามารถตรวจสอบความถูกต้องของที่อยู่ผ่าน SMTP probing ได้ (เพราะตอบกลับสำเร็จทุก probe)

พฤติกรรมเฉพาะของแต่ละผู้ให้บริการ

  • Gmail

    • การทำให้จุดเป็นมาตรฐาน: มองข้ามจุดทั้งหมดใน local part
    • Plus addressing: รองรับตัวคั่น +
    • @googlemail.com: ชื่อเรียกแทนในอดีตของ @gmail.com อันเกิดจาก ข้อพิพาทเครื่องหมายการค้า ในเยอรมนีและสหราชอาณาจักร โดยทั้งสองโดเมนส่งไปยังกล่องจดหมายเดียวกัน
    • ข้อจำกัดด้านอักขระ: อนุญาตเฉพาะตัวอักษรอังกฤษ ตัวเลข และจุดใน local part (รวมถึง + สำหรับ plus addressing) ไม่รองรับชุดอักขระ RFC แบบเต็ม
    • ข้อจำกัดความยาวของ local part: ต่ำกว่าค่าสูงสุดตาม RFC ที่ 64 อักขระมาก โดยอยู่ที่ 30 อักขระ

  • Microsoft (Outlook, Hotmail, Live)

    • ไม่มีการทำให้จุดเป็นมาตรฐาน: johndoe@outlook.com และ john.doe@outlook.com เป็น คนละกล่องจดหมาย
    • โดเมน alias: @hotmail.com, @live.com, @outlook.com อาจอ้างถึงบัญชีเดียวกันเมื่อกำหนดเป็น alias
    • รองรับ Plus addressing

  • Apple (iCloud)

    • โดเมน alias: @icloud.com, @me.com, @mac.com ไปยังกล่องจดหมายเดียวกัน (มี ประวัติการเปลี่ยนชื่อบริการ จาก .mac → .me → .icloud)
    • รองรับ Plus addressing
    • Hide My Email: สร้าง alias แบบสุ่ม ในรูป randomstring@privaterelay.appleid.com เพื่อซ่อนที่อยู่จริงด้วย alias เฉพาะสำหรับแต่ละบริการหรือแอป

  • ProtonMail / Proton

    • โดเมน alias: @proton.me, @protonmail.com, @pm.me ไปยังกล่องจดหมายเดียวกัน
    • รองรับ Plus addressing

  • บริการ alias อีเมล

    • ต่างจากอีเมลใช้ครั้งเดียว โดยเป็น บริการที่สร้างที่อยู่สำหรับส่งต่อซึ่งถาวรและควบคุมได้:
      • SimpleLogin (ในเครือ Proton): ส่งต่อไปยังกล่องจดหมายใดก็ได้ด้วย alias แบบกำหนดเองหรือแบบสุ่ม
      • Addy.io (เดิมชื่อ AnonAddy): คล้าย SimpleLogin และสามารถ self-host ได้
      • Firefox Relay (Mozilla): ให้ alias แบบสุ่มจำนวนจำกัดในแพ็กเกจฟรี
      • DuckDuckGo Email Protection: alias แบบ @duck.com
    • สร้างที่อยู่ที่สำหรับผู้ส่งแล้ว แยกไม่ออกในเชิงโครงสร้างจากกล่องจดหมายจริง
    • ความแตกต่างสำคัญจากอีเมลใช้ครั้งเดียว: alias เป็นแบบถาวรและควบคุมได้ สามารถปิดใช้งาน alias เฉพาะ ตรวจสอบว่าแต่ละบริการส่งมาจากที่ใด และส่งต่อไปยังกล่องจดหมายที่ต้องการได้

อีเมลใช้ครั้งเดียวและอีเมลชั่วคราว

  • ให้กล่องจดหมายที่ไม่ต้องสมัครและมักหมดอายุหลังช่วงเวลาสั้น ๆ โดยตัวอย่างที่พบได้บ่อยคือ Mailinator, Guerrilla Mail, 10 Minute Mail และ TempMail
  • ส่วนใหญ่ใช้ catch-all routing จึงส่งข้อความไปยังกล่องจดหมายได้ไม่ว่า local part ใดในโดเมนนั้น
  • กล่องจดหมายจำนวนมากเป็นแบบ สาธารณะ จึงทำให้ใครก็ตามที่รู้ที่อยู่นั้นสามารถอ่านข้อความได้
  • มีรายการบล็อกโดเมนใช้ครั้งเดียวที่รู้จักกันดี (ที่อ้างอิงกันมากที่สุดคือ GitHub repository disposable-email-domains) แต่ไม่เคยสมบูรณ์ และมีการ เปลี่ยนไปใช้โดเมนใหม่อย่างต่อเนื่อง เพื่อหลบเลี่ยงการบล็อก

การตรวจสอบความถูกต้อง (Validation)

  • ความถูกต้องทางเทคนิค vs ความถูกต้องในทางปฏิบัติ

    • สิ่งที่ถูกต้องตาม RFC แต่แทบไม่ถูกรับโดยเซิร์ฟเวอร์จริง: ช่องว่างในเครื่องหมายอัญประกาศ(" "@example.com), @ ในเครื่องหมายอัญประกาศ("user@name"@example.com), โดเมนแบบ IP literal(user@[192.168.1.1]), แบบอักขระเดียว/เลเบลเดียว(a@b)
    • สิ่งที่ถูกต้องตาม RFC และใช้งานได้จริงด้วย: user+tag@example.com, user_name@example.com, user@subdomain.example.co.uk, user@example.photography
    • สำหรับแอปพลิเคชันส่วนใหญ่ ตัวตรวจสอบความถูกต้องเชิงปฏิบัติมีประโยชน์กว่าตัวตรวจสอบที่สอดคล้อง RFC แบบครบถ้วน: ตรวจโครงสร้างพื้นฐาน ตรวจชุดอักขระที่สมเหตุสมผล และอาจทำ DNS MX lookup ของโดเมนเพิ่มเติม

  • บั๊กที่พบบ่อยของตัวตรวจสอบความถูกต้อง

    • ปฏิเสธ + ใน local part: user+tag@example.com ถูกต้องสมบูรณ์ และเป็นบั๊กที่พบบ่อยมาก
    • ปฏิเสธ _ ใน local part: ก็ถูกต้องเช่นกัน
    • ปฏิเสธ % ใน local part: เป็นอักขระที่ใช้ได้ สิ่งที่เลิกใช้คือการทำ percent-hack routing เท่านั้น
    • จำกัดความยาว TLD ไว้ที่ 4~6 ตัวอักษร: ทำให้ gTLD ใหม่ หลายร้อยรายการ เช่น .photography, .international, .construction ถูกบล็อก
    • ตรวจสอบด้วยรายการ TLD ที่ hardcode ไว้: รายการเปลี่ยนแปลงตลอด จึงทำให้ตัวตรวจสอบล้าสมัย
    • จำกัดความยาวรวมผิดพลาด: ใช้ 255 หรือ 256 แทน 254 โดยค่า 320 ที่มีการอ้างถึงกันแพร่หลายนั้นถูก แก้เป็น 254 ใน RFC 3696 erratum หมายเลข 1690
    • ปฏิเสธตัวพิมพ์ใหญ่ใน local part: ถูกต้องตาม RFC
    • ปฏิเสธ user@subdomain.co.uk: ถูกต้อง และโดเมนหลายจุดในรูปแบบ second-level ccTLD เป็นเรื่องปกติ
    • ปฏิเสธ .dev, .app, .io เป็น TLD: ทั้งหมดเป็น TLD ที่ได้รับการมอบหมายอย่างถูกต้อง

  • ข้อจำกัดด้านความยาว

    ส่วน ข้อจำกัด
    local part 64 octets
    domain label 63 octets
    โดเมนทั้งหมด 253 octets
    ที่อยู่ทั้งหมด (addr-spec) 254 octets

  • ข้อจำกัดของ local part นับเป็น octets ไม่ใช่จำนวนอักขระ ดังนั้นที่อยู่ EAI ที่มีอักขระ Unicode แบบหลายไบต์อาจดูเหมือนยาวไม่ถึง 64 อักขระ แต่ก็แตะขีดจำกัด octet ได้

  • การตรวจสอบความถูกต้องโดยอิง DNS

    • ตรวจสอบ MX record: ตรวจว่าโดเมนมี MX record หรือไม่ ซึ่งรวดเร็วและความเสี่ยงต่ำ แต่โดเมนที่ใช้ A record fallback (ไม่มีการตั้งค่า MX) อาจไม่ผ่านการตรวจนี้
    • ตรวจสอบ Null MX: หากโดเมนมี MX 0 . แปลว่า ไม่รับอีเมลอย่างชัดเจน
    • SMTP RCPT TO probing: เชื่อมต่อกับเมลเซิร์ฟเวอร์แล้วส่งคำสั่ง RCPT TO เพื่อตรวจว่ารับที่อยู่นี้หรือไม่ แต่หลายเซิร์ฟเวอร์ตอบ 250 กับทุกที่อยู่เพื่อป้องกันการเก็บเกี่ยวรายชื่ออีเมล จึง ไม่น่าเชื่อถือ ขณะที่โดเมนแบบ catch-all จะตอบรับเชิงบวกเสมอ และยังมีความเสี่ยงที่ IP ที่ใช้ probe จะถูกใส่ blacklist
    • วิธีเดียวที่ตรวจสอบที่อยู่อีเมลได้อย่างน่าเชื่อถือเต็มที่คือ ส่งข้อความจริงแล้วดูว่าส่งถึงหรือไม่ ส่วนวิธีอื่นทั้งหมดเป็นเพียง heuristic

นัยด้านความปลอดภัย

  • การปลอมชื่อที่แสดง

    • ใครก็สามารถตั้งชื่อที่แสดงในอีเมลเป็นอะไรก็ได้ และในมุมมองกล่องจดหมายที่แสดงเฉพาะชื่อนั้น ผู้ใช้จะ แยกไม่ออกจากผู้ส่งที่ถูกต้อง หากไม่ตรวจสอบที่อยู่อีเมลจริงอย่างชัดเจน

  • การโจมตีแบบ homograph ผ่าน Punycode

    • สามารถจดทะเบียน โดเมนที่ดูเหมือนกันทางสายตา กับโดเมนที่รู้จักกันดีได้ โดยใช้อักขระจาก Unicode script อื่น
    • ต่างจากเบราว์เซอร์ โปรแกรมรับส่งอีเมลโดยทั่วไป ไม่แสดงคำเตือน เกี่ยวกับเรื่องนี้

  • การเลี่ยงข้อจำกัดบัญชีด้วย Gmail dot trick

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

  • การนำที่อยู่อีเมลกลับมาใช้ใหม่

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

  • การเปิดเผยแท็ก subaddress

    • หากสมัครด้วย user+newsletter@gmail.com บริการปลายทางจะมองเห็นที่อยู่เต็มที่รวมแท็กนั้น
    • บริการที่ลบ plus tag ออกก่อนบันทึกจะเปิดเผยที่อยู่พื้นฐาน ส่วนบริการที่เก็บที่อยู่เต็มตามเดิมจะทำให้ กลยุทธ์การติดตามถูกเปิดเผย ผ่านการตั้งค่าบัญชีหรือการส่งออกข้อมูล

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น