การทำให้อีเมลอ่านยาก: วิธีไหนยังได้ผลในปี 2026?

 (spencermortensen.com)
5 คะแนน โดย GN⁺ 27 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการทดลองเทคนิค HTML·CSS·JavaScript obfuscation หลายแบบเพื่อปกป้องที่อยู่อีเมลจาก ตัวเก็บสแปม และเปรียบเทียบอัตราการบล็อก
  • ผลทดสอบกับตัวอย่าง ข้อความ 426 รายการ และ ลิงก์ 399 รายการ พบว่า เทคนิคฝั่ง JS ส่วนใหญ่ รวมถึงบางเทคนิคของ CSS·SVG ทำอัตราบล็อกได้ 100%
  • วิธีแบบเก่าอย่าง HTML entities·URL encoding ก็ยังคงมีประสิทธิภาพในการบล็อกสูง
  • ในทางกลับกัน วิธีอย่าง การแสดงเป็นรูปภาพ·การแทนที่ด้วยสัญลักษณ์·การกลับทิศทางข้อความ กลับกระทบ accessibility และ usability อย่างรุนแรง
  • สำหรับปี 2026 วิธีที่ถูกประเมินว่า ปลอดภัยและใช้งานได้จริงที่สุด สำหรับการปกป้องอีเมลคือ การแปลงด้วย JS·การเข้ารหัส AES·วิธีที่อาศัยการโต้ตอบของผู้ใช้

เปรียบเทียบเทคนิคการทำให้อ่านที่อยู่อีเมลได้ยาก (อ้างอิงปี 2026)

  • นำเสนอเทคนิค obfuscation หลายแบบสำหรับซ่อนที่อยู่อีเมลจาก ตัวเก็บสแปม (harvester) พร้อมสถิติผลลัพธ์จริงของแต่ละวิธี
  • ปกป้องที่อยู่อีเมลแต่ละรายการด้วยวิธีที่ต่างกัน แล้ววัดว่าถูก harvester เข้าถึงได้หรือไม่จากตัวอย่าง 426 รายการ (ข้อความ) และ 399 รายการ (ลิงก์) เพื่อคำนวณอัตราการบล็อก
  • เทคนิคที่อิง JavaScript ส่วนใหญ่ และบางเทคนิคของ CSS·SVG ทำอัตราบล็อกได้ 100%
  • วิธีเก่าอย่าง HTML entities·URL encoding ก็ยังรักษาอัตราการบล็อกในระดับสูงไว้ได้
  • บางเทคนิคกระทบ accessibility หรือ usability อย่างรุนแรง จึงไม่เหมาะกับการใช้งานจริง

1. เทคนิคปกป้องอีเมลแบบข้อความทั่วไป

  • แสดงที่อยู่อีเมลบนหน้าเว็บโดยตรง แต่ใช้เทคนิค HTML·CSS·JS หลายแบบเพื่อทำให้ harvester อ่านไม่ได้
  • หาก ผสมหลายเทคนิคและปกป้องเป็นรายเซกเมนต์ ก็สามารถเพิ่มประสิทธิภาพได้สูงสุด

  • ไม่มีการป้องกัน (No protection)

    • อัตราการบล็อก 0% (บล็อกได้ 0 จาก 426 ราย)
    • ที่อยู่อีเมลถูกเปิดเผยตรง ๆ และถูกเก็บโดย harvester ทั้งหมด

  • HTML entities

    • อัตราการบล็อก 95%
    • แม้ไลบรารีฝั่งเซิร์ฟเวอร์จะถอดรหัสให้อัตโนมัติ แต่ในทางปฏิบัติก็ยังบล็อก harvester ได้ส่วนใหญ่

  • HTML comments

    • อัตราการบล็อก 99%
    • ป้องกันได้เฉพาะ harvester แบบพื้นฐานที่ตีความ HTML tags ได้ไม่ดี
    • แม้เรียบง่าย แต่ยังคงมีประสิทธิภาพในการบล็อกสูง

  • HTML SVG

    • อัตราการบล็อก 100%
    • ซ่อนที่อยู่อีเมลไว้เป็น ข้อความภายในออบเจ็กต์ SVG
    • screen reader สำหรับผู้พิการทางสายตายังเข้าถึงได้
    • ต้องใช้ element <object> เท่านั้น ส่วน <img> หรือ inline SVG มีความเสี่ยงที่ source จะถูกเปิดเผย
    • มีการพึ่งพาฟอนต์ จึงต้อง กำหนดเว็บฟอนต์

  • CSS display:none

    • อัตราการบล็อก 100%
    • อาศัยข้อจำกัดของ harvester ที่ไม่สามารถประมวลผลกฎ style ได้
    • ยังคงรักษา accessibility ได้ และแนะนำให้ใช้ display:none แทนการซ่อนแบบภาพลวงตา

  • JS concatenation

    • อัตราการบล็อก 100%
    • ทำได้ง่ายโดยไม่ต้องพึ่ง dependency ภายนอก
    • แต่อีเมลทั้งหมดยังคงอยู่ใน HTML source จึง อ่อนแอในเชิงความปลอดภัย

  • JS Rot18

    • อัตราการบล็อก 100%
    • ใช้การเข้ารหัสแบบหมุนอักขระคล้าย ROT13
    • harvester แบบง่ายจะถอดไม่ได้ แต่ เปราะบางต่อเครื่องมือเก็บข้อมูลที่ไม่สนใจ JS

  • JS conversion

    • อัตราการบล็อก 100%
    • ใน HTML จะมีเพียงสตริงที่ไม่มีความหมาย และฟังก์ชัน JS จะแปลงให้เป็นอีเมลจริง
    • harvester ส่วนใหญ่ไม่สามารถประมวลผล DOM·JS ได้ จึงกู้คืนไม่ได้
    • เป็น เทคนิคที่เรียบง่ายแต่มีประสิทธิภาพมาก

  • JS AES encryption

    • อัตราการบล็อก 100%
    • ปกป้องอีเมลด้วย การเข้ารหัส AES-256
    • ใช้ SubtleCrypto API ของเบราว์เซอร์ และทำงานได้เฉพาะบน HTTPS
    • หากไม่มีไฟล์ JS จะไม่สามารถถอดรหัสได้

  • JS user interaction

    • อัตราการบล็อก 100%
    • จะแสดงอีเมลก็ต่อเมื่อผู้ใช้มีการโต้ตอบกับหน้าเว็บ
    • harvester ต้อง รัน DOM + จำลอง user event ซึ่งแทบเป็นไปไม่ได้

  • HTML symbol substitution

    • อัตราการบล็อก 96%
    • แทนที่ด้วยคำอย่าง “AT”, “DOT”
    • ผู้ใช้ต้องแก้กลับเอง จึง ลดทอน usability

  • HTML instructions

    • อัตราการบล็อก 100%
    • ใส่คำสั่งแบบ manual ไว้ในอีเมล เช่น “remove the .fluff”
    • แม้มนุษย์หรือ AI จะตีความได้ แต่ สร้างความไม่สะดวกแก่ผู้ใช้ มาก

  • HTML image

    • อัตราการบล็อก 100%
    • แสดงที่อยู่อีเมลเป็นรูปภาพ
    • ผู้พิการทางสายตาเข้าถึงไม่ได้ คัดลอกก็ไม่ได้ เป็น การพังของ usability โดยสิ้นเชิง

  • CSS content

    • อัตราการบล็อก 100%
    • แสดงอีเมลด้วย pseudo-element ::after
    • มองเห็นได้ด้วยตา แต่คัดลอกไม่ได้ และยังสามารถกู้คืนได้จาก HTML เพียงอย่างเดียว
    • ถูกประเมินว่าเป็น เทคนิคที่ไร้ประโยชน์

  • CSS text direction

    • อัตราการบล็อก 100%
    • ใช้ direction: rtl เพื่อกลับสตริง
    • ถ้า harvester ไม่สนใจ CSS ก็ถอดได้ง่าย
    • ข้อความจะถูกคัดลอกแบบกลับด้าน ทำให้ usability แย่ลง

2. เทคนิคปกป้องลิงก์ที่คลิกได้

  • เป็นการปกป้อง attribute href ของลิงก์ mailto:
  • หากข้อความลิงก์มีอีเมลรวมอยู่ด้วย ก็จำเป็นต้องใช้ เทคนิค obfuscation สำหรับข้อความ ควบคู่กันด้วย

  • ไม่มีการป้องกัน

    • อัตราการบล็อก 0% (บล็อกได้ 0 จาก 399 ราย)
    • ที่อยู่อีเมลถูกเปิดเผยทั้งหมด

  • HTML entities

    • อัตราการบล็อก 100%
    • แม้จะมีการถอดรหัสอัตโนมัติฝั่งเซิร์ฟเวอร์ แต่ก็ยังบล็อก harvester ได้ส่วนใหญ่

  • URL encoding

    • อัตราการบล็อก 95%
    • แม้จะถอดรหัสได้ง่าย แต่ในทางปฏิบัติก็ยังบล็อก harvester ได้ส่วนใหญ่

  • HTTP redirect

    • อัตราการบล็อก 100%
    • ซ่อนลิงก์ mailto: ให้ดูเหมือนลิงก์ทั่วไป
    • ตั้งค่า redirect 302 หรือ 301 ใน .htaccess
    • ป้องกัน search engine indexing ด้วย nofollow, noindex
    • หากมีการเติมข้อมูลในฟิลด์อีเมลอัตโนมัติ ต้องใช้แฟลก QSA

  • HTML SVG

    • อัตราการบล็อก 100%
    • ซ่อนลิงก์อีเมลไว้ภายใน SVG
    • รักษา accessibility ได้ และต้องใช้ <object>
    • ต้องกำหนดฟอนต์

  • JS concatenation

    • อัตราการบล็อก 100%
    • ทำได้โดยไม่ต้องพึ่ง dependency ภายนอก
    • แต่อีเมลถูกใส่ไว้ใน HTML โดยตรง จึงไม่ปลอดภัย

  • JS Rot18

    • อัตราการบล็อก 99%
    • การหมุนอักขระคล้าย ROT13
    • harvester แบบง่ายจะถอดไม่ได้

  • JS conversion

    • อัตราการบล็อก 100%
    • ใน HTML จะมีเพียง ลิงก์ปลอม และ JS จะเปลี่ยนให้เป็น mailto: จริง
    • harvester เข้าถึงได้แค่ HTML จึงกู้คืนไม่ได้
    • เป็น เทคนิคที่เรียบง่ายแต่มีประสิทธิภาพมาก

  • JS AES encryption

    • อัตราการบล็อก 100%
    • ลิงก์อีเมลที่ถูกเข้ารหัสด้วย AES-256
    • ใช้ SubtleCrypto API ของเบราว์เซอร์ และต้องใช้ HTTPS

  • JS user interaction

    • อัตราการบล็อก 100%
    • ลิงก์จะทำงานก็ต่อเมื่อผู้ใช้มีการโต้ตอบ
    • harvester ทำซ้ำพฤติกรรมนี้ได้ยาก

3. คำวิจารณ์และข้อโต้แย้ง

  • ต่อข้ออ้างว่า “spammer ไม่ได้ไล่เก็บจากเว็บ แต่ซื้อฐานข้อมูลที่รั่วไหล”
    • ที่อยู่อีเมลในหน้านี้ ถูกเผยแพร่แค่บนหน้านี้เท่านั้น แต่ก็ยังได้รับสแปมหลายพันฉบับ
  • ต่อข้ออ้างว่า “ไม่จำเป็นต้องป้องกัน”
    • เนื้อหายอดนิยมมักถูกเก็บข้อมูลอย่างเข้มข้น จึง ควรป้องกันหากมีโอกาสกลายเป็นไวรัล
  • ต่อข้ออ้างว่า “มีแค่ตัวกรองสแปมก็พอ”
    • เทคนิคเหล่านี้ ทำได้ฟรีโดยไม่ทำให้เกิด false positive และควรใช้ร่วมกับตัวกรอง
  • ต่อข้ออ้างว่า “ถ้าคนรู้เทคนิคแล้วก็ไร้ประโยชน์”
    • สถิติยืนยันว่าเทคนิคเดิม ๆ ตลอดหลายทศวรรษยังคงใช้ได้ผล

4. วิธีการทดลอง

  • เผยแพร่ที่อยู่อีเมลที่ปกป้องด้วยเทคนิค obfuscation แต่ละแบบจริง ๆ และใช้งานเป็น honeypot สำหรับ harvester
  • เมื่อมีสแปมเข้ามา จะถือว่าเทคนิคปกป้องของที่อยู่นั้นถูกเจาะได้แล้ว
  • จัดกลุ่มข้อความตาม spammer เพื่อคำนวณสถิติโดยอิง จำนวนผู้ส่ง
  • เพื่อไม่ให้การกรองสแปมบิดเบือนสถิติ จึง สร้าง mail server และ client เองโดยตรง
  • เนื่องจาก harvester แบบข้อความและแบบลิงก์ต่างกัน จึง แยกสถิติคนละชุด
  • แม้จำนวนตัวอย่างยังไม่มาก แต่คาดว่าความน่าเชื่อถือของสถิติจะดีขึ้นเมื่อมีลิงก์เพิ่มขึ้น

สรุป

  • เทคนิคที่อิง JS สำหรับการแปลง·การเข้ารหัส·การโต้ตอบของผู้ใช้ ให้ทั้งความปลอดภัยและ accessibility สูงที่สุด
  • CSS display:none และ เทคนิค SVG object ก็โดดเด่นทั้งด้าน accessibility และอัตราการบล็อก
  • การแทนที่ด้วยสัญลักษณ์, รูปภาพ, การกลับทิศทางข้อความ กระทบ usability อย่างรุนแรง จึงไม่แนะนำ
  • หากจำเป็นต้องเผยแพร่อีเมล วิธี JS conversion แบบง่าย หรือการเข้ารหัส AES คือทางเลือกที่มีประสิทธิภาพที่สุด ณ ปี 2026

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

1 ความคิดเห็น

 
GN⁺ 27 일 전
ความคิดเห็นจาก Hacker News

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

    • ตั้งแต่ต้นยุค 2000 ผมใส่อีเมลเป็นข้อความธรรมดาพร้อมลิงก์ mailto: ไว้บนบล็อก และได้รับสแปมแค่วันละไม่กี่ฉบับ
      อาจเป็นเพราะ การกรองของ Zoho ทำได้ดี แต่ผมก็ไม่คิดว่ามันดีกว่าบริการรายใหญ่เป็นพิเศษ
    • บอทเก็บข้อมูลส่วนใหญ่มีที่อยู่อีเมลเป็นล้านๆ อยู่แล้ว เลยไม่ได้สนใจ อีเมลหายาก ไม่กี่อัน
      เพราะงั้นใช้วิธีง่ายๆ ของตัวเองก็พอได้ แต่ถ้าเผยแพร่มันออกไปก็อาจถูกทำให้หมดความหมายได้ทันที
    • หลังจากเอาอีเมลขึ้นเว็บไซต์บริษัท ผมได้รับ สแปมมากกว่า 1,500 ฉบับ ต่อเดือน
    • ผมก็เปิดเผยอีเมลแบบเดียวกันมาตลอด แต่ถ้าวิธีง่ายๆ อย่าง HTML entity หรือ display:none ช่วยกันได้เกิน 90% ก็น่าลองกลับมาพิจารณาอีกครั้ง
    • ผมคิดว่าอีเมลสุดท้ายก็หลุดอยู่ดี แต่ สแปมที่ใช้ LLM น่าจะมีโอกาสหลบตัวกรองได้มากขึ้นเรื่อยๆ

  • อีเมลของผมถูกใส่แบบข้อความธรรมดาในคอมมิตของ GitHub ของรีโปโอเพนซอร์สยอดนิยมมากกว่า 90 ครั้ง
    แต่ตลอด 8 ปีแทบไม่เคยได้รับสแปมเลย
    รูปแบบที่ครอบด้วย < และ > อาจจะ ทำให้ตัวเก็บข้อมูลสับสน ก็ได้
    ทุกวันนี้ดูเหมือน การซื้อรายชื่ออีเมล จะพบได้บ่อยกว่าการเก็บข้อมูลเองโดยตรง

    • ผมตั้งค่า wildcard address ไว้ในโดเมนของตัวเอง
      เลยมีสแปมส่งมาที่ git@, contact@, admin@ บ่อยๆ
      ช่วงหลังยังมี อีเมลปลอมเป็น CEO ส่งมาที่ที่อยู่ปลอมอย่าง finance@ ด้วย
      น่าขันตรงที่อีเมลที่ผมใส่แบบข้อความธรรมดาในโปรไฟล์ HN กลับแทบไม่มีสแปมเลย

  • สมมติฐานของผมคือ ตัวเก็บอีเมลไม่ได้ parse HTML แต่แค่หา สตริงรอบๆ อักขระ @ เท่านั้น
    การ parse HTML มีต้นทุนสูง วิธีง่ายๆ แบบนี้จึงอาจมีประสิทธิภาพกว่า
    เพราะงั้น HTML entity ถึงดูเหมือนจะได้ผล

    • เป็นไปได้ว่าตัวเก็บข้อมูลอาจเรียนรู้แล้วว่าสแปมที่ส่งไปยังที่อยู่แบบ obfuscate นั้น มีอัตราการตอบสนองต่ำ
      เลยอาจเลือกมองข้ามที่อยู่แบบนั้นไปเลย
    • ใช่ ส่วนใหญ่เป็นการค้นหาระดับไบต์แบบง่ายๆ แต่ฝั่งการตลาดสาย black-hat ก็มี เทคนิค scraping หลากหลายแบบอยู่เหมือนกัน
    • สุดท้ายแล้วขึ้นอยู่กับว่าคู่ต่อสู้ดื้อแค่ไหน ผู้โจมตีที่ไม่สมเหตุสมผล จะไล่ตื๊อไม่เลิก
    • การดึงข้อมูลแบบดู token รอบ @ ก็ยังใช้งานได้ดีพอด้วยการดัดแปลงนิดหน่อย

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

    • ผมก็ใช้วิธีนั้นมา 20 ปีแล้ว
      แต่สแปมส่วนใหญ่เกิดจากเพื่อนหรือครอบครัวเอาที่อยู่อีเมลของผมไปแชร์กับแอป
      สำหรับอีเมลที่เปิดเผยสาธารณะ ผมกันได้ 100% ด้วย วิธีประกอบผ่าน JavaScript แบบง่ายๆ
    • เมื่อก่อนผมพยายามสร้างอีเมลเฉพาะสำหรับแต่ละคน แต่สุดท้ายก็ลดรูปมาเป็น ที่อยู่เดียวแบบอิง whitelist
      ผลลัพธ์พอๆ กันและจัดการง่ายกว่ามาก

  • มีวิธีซ่อน tarpit email address ไว้ในเว็บไซต์
    ซ่อนด้วย CSS ให้คนมองไม่เห็น แล้วถ้าบอทส่งเมลไปยังที่อยู่นั้นก็แบน IP นั้น 24 ชั่วโมง

    • แต่แบบนี้เสี่ยงจะบล็อก เมลเซิร์ฟเวอร์หลักอย่าง Google ไปด้วย
      เพราะมีสแปมที่มาจากบัญชี Gmail เหมือนกัน เลยมีผลข้างเคียงสูง
    • แนวคิดคล้ายกันมี Project Honey Pot

  • เนื้อหาดี แต่ผมคิดว่าชื่อควรเป็น 'Email address obfuscation' มากกว่า
    แต่อีกด้านหนึ่ง บทความแบบนี้ก็ดูเหมือนจะช่วยให้พวกสแปมเมอร์เรียนรู้ได้เหมือนกัน

    • การใช้คำว่า “email” แทน “email address” ทำให้สับสน เพราะตามบริบทมันมักถูกอ่านเป็น “ข้อความอีเมล”
    • วิธีแสดงช่องทางติดต่อใน เว็บไซต์ของ Greg Egan ซับซ้อนเกินไปจนถอดไม่ออกเลย

  • เมื่อก่อนผมเคยทดสอบว่าแนวเขียนอย่าง “me at foobar dot com” ยังได้ผลอยู่ไหม
    พอลองใช้ LLM แกะ วิธี obfuscate อีเมล หลายแบบ ก็พบว่าถ้าไม่ใช่แบบอิง CSS หรือ JS ส่วนใหญ่ตีความได้หมด
    ถึงอย่างนั้น ทุกวันนี้ตัวกรองสแปมทำงานดีพอ การเปิดเผยอีเมลแบบข้อความธรรมดาเลยไม่ใช่ปัญหาใหญ่
    กลับกัน อีเมลแจ้งเตือนจากบริการต่างๆ น่ารำคาญกว่า

    • วิธีที่ดีกว่าคือให้ผู้เยี่ยมชมใช้ CPU เล็กน้อยเพื่อสร้าง อีเมลโทเคนเฉพาะตัว
      ถ้ามีการ abuse ก็ทิ้งเฉพาะที่อยู่นั้นได้เลย
      ถ้าไคลเอนต์กับเมลเซิร์ฟเวอร์รองรับ API แบบนี้ก็คงจะดีมาก
    • ตัวเก็บข้อมูลที่ใช้ LLM อาจตีความ คำสั่ง ได้ดีกว่าคนด้วยซ้ำ
      เพราะงั้น การ obfuscate ขั้นพื้นฐาน ที่ใช้กันบอท regex ธรรมดาจึงยังมีประโยชน์อยู่
    • มีการ์ตูน xkcd 1808 ที่เกี่ยวข้องด้วย

  • ช่วงต้นปีนี้ผมทำ อินเทอร์พรีเตอร์ Brainfuck ด้วย C แล้วลองเอามาใช้กับการ obfuscate อีเมล
    เก็บอีเมลแต่ละอันเป็นโปรแกรม Brainfuck แล้วให้ JS interpreter รันเพื่อแสดงข้อความจริง
    ตัว JS ถูกโหลดจากโดเมนภายนอก และจะส่งโค้ดจริงกลับมาหลังตรวจสอบ referer
    แน่นอนว่าถ้าเป็นตัวเก็บข้อมูลที่รัน JS ได้ก็ไร้ประโยชน์ แต่ก็สนุกดีในฐานะ การทดลอง obfuscate แบบสร้างสรรค์

    • สงสัยว่าวิธีนี้ต่างจากการ เข้ารหัส XOR ใน JS แบบตรงๆ อย่างไร
    • ถ้าตัวเก็บข้อมูล ป้อนภาพหน้าจอเข้า LLM หรือ OCR วิธีนี้ก็คงใช้ไม่ได้เหมือนกัน

  • บทความนี้ดูเหมือน คู่มือทำให้ตัวเก็บอีเมลฉลาดขึ้น อยู่บ้าง

    • ก็จริง แต่การรัน JS หรือ CSS การเรนเดอร์ SVG ฯลฯ ก็ยังเป็น งานที่มีต้นทุนสูง อยู่ดี เลยเป็นภาระสำหรับบอทขนาดใหญ่