โฮสต์อีเมลเองแบบสายฮาร์ดคอร์ เริ่มตั้งแต่บล็อก IPv4 ที่ประกาศเส้นทางได้เอง

 (anil.recoil.org)
1 คะแนน โดย GN⁺ 15 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงสร้างพื้นฐานอีเมลของ Recoil ที่ใช้งานมาตั้งแต่ปี 1997 ถูกปรับปรุงใหม่เป็นสแต็กโฮสต์เองที่จัดการการรับ·ส่ง·การเข้าถึงด้วยตัวเอง โดยผสาน dedicated IPv4 /24 block, Postfix, Dovecot, rspamd, Roundcube เป็นต้น
  • การรันระบบอีเมลเองให้ทั้งสิทธิ์ในการเข้าถึงข้อมูลและคุณค่าด้านการเรียนรู้ แต่บน SMTP ที่มีรากฐานจากความเชื่อใจต่ำ ผู้ดูแลต้องจัดการ ชื่อเสียงของ IP, ระเบียน DNS และการป้องกันสแปมด้วยตัวเอง
  • เส้นทางรับอีเมลถูกออกแบบให้ค่อย ๆ ลดทราฟฟิกบอตและเมลอันตรายผ่าน postscreen, DNSBL, greylisting, ClamAV, Bayesian filtering, LMTP และ Sieve
  • ความน่าเชื่อถือของการส่งออกขึ้นอยู่กับ SPF, DKIM, DMARC และ SRS หากตั้งค่าผิด เมลอาจถูกผู้รับอย่าง Gmail·Outlook จัดเป็นสแปมหรือถูกทิ้งแบบเงียบ ๆ
  • การโฮสต์อีเมลเองในปี 2026 ยังทำได้อยู่ แต่ต้องมี defense in depth เพื่อรับมือกับการหา IPv4, ระเบียน DNS หลายชุด, การอัปเดตความปลอดภัย และการโจมตีช่องโหว่ที่อาศัย AI

ทำไมต้องรันอีเมลเอง

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

โครงสร้างการรับอีเมล

  • โดเมนอินเทอร์เน็ตกำหนดเซิร์ฟเวอร์ SMTP ที่รับเมลผ่านระเบียน MX DNS โดย recoil.org ให้ pork.recoil.org เป็นผู้จัดการอีเมล
  • SMTP มีต้นกำเนิดจากการออกแบบยุค 1980 ที่ตั้งอยู่บนความเชื่อใจมากกว่าเดิม จึงไม่สามารถพิสูจน์ตัวตนผู้ส่งได้โดยพื้นฐาน และผู้ส่งของเมลขาเข้าก็ปลอมแปลงได้ง่าย
  • การตอบสนองของ IETF พัฒนามาเป็นการซ้อนการตรวจสอบตัวตนหลายชั้น และหากตั้งค่าการตรวจสอบเหล่านี้ผิด ความน่าเชื่อถือในการส่งเมลก็จะลดลง
  • รายการบล็อกตาม DNS รวบรวมข้อมูลบอตเน็ต โฮสต์ที่ถูกเจาะ และสแปมเมอร์ เพื่อให้เมลเซิร์ฟเวอร์ query RBL แล้วกรอง IP ที่น่าสงสัยได้
  • ชื่อเสียงของอีเมลสะสมที่ IP address ไม่ใช่โดเมน ดังนั้นที่อยู่ที่เคยถูกใช้ซ้ำในคลาวด์ หรือ IP ข้างเคียงในบล็อกเดียวกัน ก็อาจส่งผลต่อชื่อเสียงได้

  • การหา dedicated IPv4 block และการประกาศเส้นทาง

    • Recoil จัดหา dedicated IPv4 address block 185.33.27.0/24 เพื่อให้สามารถสะสมชื่อเสียงเมลได้อย่างเป็นอิสระ
    • RIPE NCC ใช้พื้นที่ IPv4 ที่ยังไม่ถูกจัดสรรหมดไปในเดือนพฤศจิกายน 2019 และหลังจากนั้นการจัดสรรโดยตรงจะทำผ่าน waiting list สำหรับ /24 ขนาดเล็ก
    • บล็อก /24 นี้ถูกจัดสรรหลังรอประมาณ 6 เดือน และหากจะยื่นขอเองในยุโรปต้องจ่ายค่าสมาชิก RIPE NCC และเปิดบัญชี LIR
    • IPv4 block ที่ได้รับจะกำหนดสิทธิ์ในการประกาศเส้นทางด้วยการสร้าง RPKI ROA โดยบล็อกของ Recoil ผูกกับ Mythic Beasts AS44684
    • reverse DNS ก็สามารถควบคุมได้เองเช่นกัน โดย 185.33.27.128 ถูกแมปเป็น pork.recoil.org และกลายเป็นสัญญาณด้านชื่อเสียงของอีเมล

การป้องกันบอตและสแปม

  • การมี IPv4 block ที่สะอาดอย่างเดียวไม่เพียงพอ เพราะการเชื่อมต่อ TCP ส่วนใหญ่ที่เข้ามาทางพอร์ต 25 คือความพยายามส่งสแปม สำรวจ open relay เดารหัสผ่าน และเก็บข้อมูลสำหรับฝึก AI
  • Postfix postscreen ทำงานอยู่หน้าพอร์ต 25 โดยตรวจ DNSBL แบบขนาน หน่วง pre-greet และตรวจการทำ pipelining กับคำสั่งที่ไม่ใช่ SMTP
  • postscreen จะส่งต่อเฉพาะไคลเอนต์ที่ดูปกติไปยัง smtpd จริงเท่านั้น ส่วนไคลเอนต์ที่ผิดปกติจะถูกตัดด้วย temporary failure เพื่อให้กรณี false positive ยัง retry ได้
  • รายการ Spamhaus, Spamcop และ Barracuda ถูกนำมารวมแบบถ่วงน้ำหนัก และตั้งค่าให้ปฏิเสธเมื่อโดน Spamhaus เพียงรายการเดียวหรือโดนสองรายการที่น้ำหนักอ่อนพร้อมกัน
  • MX pool สำหรับผู้ส่งจาก Apple iCloud ไม่ retry จาก IP เดิม จึงไม่เข้ากับ allowlist ของ postscreen ทำให้ต้องตั้ง bypass โดยอนุญาต 17.0.0.0/8 ทั้งช่วงก่อน

  • Greylisting และการตรวจเนื้อหา

    • Greylisting จะตอบ temporary failure กับผู้ส่งที่ไม่เคยเห็นมาก่อน และจะยอมให้ผ่านเมื่อ MTA ปกติ retry อีกครั้งหลังจากผ่านไปไม่กี่นาที
    • บอตเน็ตที่ยิงครั้งเดียวมักย้ายไปหาเป้าหมายถัดไปหลังล้มเหลว จึงแยกออกจากผู้ส่งปกติที่มีคิว retry ได้
    • หลังผ่าน postscreen และ greylisting แล้ว ทราฟฟิกบอตดั้งเดิมกว่า 99% จะถูกบล็อกด้วยต้นทุน CPU ต่ำ
    • rspamd ตรวจทุกข้อความผ่านโปรโตคอล milter โดยจะไม่รับเมลน่าสงสัยแล้วค่อยตีกลับภายหลัง แต่จะปฏิเสธหรือหน่วงไว้ตั้งแต่ตอนที่เซิร์ฟเวอร์ผู้ส่งยังเชื่อมต่ออยู่
    • ClamAV ตรวจไฟล์แนบไวรัสที่รู้จักและปฏิเสธข้อความที่ติดเชื้อทันที ส่วน Bayesian classifier ของ rspamd จะให้คะแนนข้อความจากคอร์ปัสสแปม·แฮมที่เก็บไว้ใน Redis

การส่งต่อภายใน การจัดเก็บ และการกรอง

  • ข้อความขาเข้าจะถูกส่งต่อไปยัง Dovecot หลังผ่าน postscreen, greylisting, rspamd, ClamAV และ Bayesian classifier
  • แทนที่ Postfix จะเขียนตรงไปยังโฮมไดเรกทอรีของผู้ใช้ ระบบจะส่งต่อผ่าน LMTP ไปยัง Dovecot เพื่อให้รับผิดชอบ indexing, quota, full-text search และการกรองด้วย Sieve
  • virtual_alias_maps จะแปลงที่อยู่อย่าง anything@recoil.org ให้เป็นที่อยู่ที่ส่งต่อภายในเครื่องได้
  • รูปแบบการจัดเก็บคือ Maildir ที่ใช้มาตั้งแต่ปี 1998 โดยเก็บอีเมลแต่ละฉบับเป็นไฟล์เดี่ยวใต้ ~/Maildir ของผู้ใช้
  • Maildir ใช้ไดเรกทอรีย่อยสามชุดคือ tmp/, new/, cur/ และอาศัย POSIX atomic rename เพื่อส่งข้อความใหม่ได้โดยไม่ต้องล็อกทั้ง mailbox

  • ดัชนีค้นหาและ Sieve

    • แม้จะพิจารณาเมลเซิร์ฟเวอร์สมัยใหม่อย่าง Stalwart ด้วย แต่เพราะมันไม่รองรับ Maildir และต้องใช้ที่เก็บฐานข้อมูลแบบกำหนดเองอย่าง RocksDB จึงไม่ได้ย้ายไปใช้
    • Dovecot แยกการจัดเก็บ Maildir ออกจากประสิทธิภาพการค้นหาด้วย Flatcurve ซึ่งเป็นดัชนี full-text แยกต่างหาก
    • Flatcurve เป็น wrapper ของ Xapian โดยเก็บดัชนี Xapian ของแต่ละ mailbox ไว้ใต้ ~/Maildir/fts-flatcurve และอัปเดตอัตโนมัติเมื่อมีเมลใหม่เข้ามา
    • Sieve เป็นภาษาประกาศสำหรับกรองเมลโดยเฉพาะ และปลั๊กอิน Pigeonhole Sieve ของ Dovecot จะรันฟิลเตอร์ของผู้ใช้ในจังหวะส่งมอบ
    • สคริปต์ Sieve ทั้งระบบจะส่งเมลที่ rspamd ทำเครื่องหมายไว้ไปยัง Junk ส่วนสคริปต์รายผู้ใช้จะจัดการการแยกโฟลเดอร์ กฎลาพักร้อน ลำดับความสำคัญ และการแก้ไข header

การส่งอีเมลออกอย่างน่าเชื่อถือ

  • หากต้องการส่งเมลได้เสถียร การยืนยันตัวตนขาออกสำคัญพอ ๆ กับการป้องกันขาเข้า เพราะถ้าล้มเหลวกับการตรวจข้อใดข้อหนึ่งของผู้รับรายใหญ่ เมลอาจลงโฟลเดอร์สแปมหรือถูกทิ้งแบบเงียบ ๆ
  • SPF คือระเบียน DNS TXT ที่ระดับบนสุดของโดเมน ซึ่งประกาศว่า IP address ใดมีสิทธิ์อ้างตัวว่าเป็นผู้ส่ง @recoil.org
  • SPF ของ Recoil คือ v=spf1 a mx -all ซึ่งหมายความว่าเฉพาะ pork.recoil.org ที่ MX ของ recoil.org ชี้อยู่เท่านั้นที่ถือเป็นผู้ส่งที่ถูกต้อง
  • Postfix ถูกผูกกับที่อยู่ขาออกเฉพาะผ่าน smtp_bind_address และ smtp_bind_address6 เพื่อป้องกันไม่ให้เคอร์เนลเลือกที่อยู่แบบสุ่มบนโฮสต์ที่มีหลาย IP
  • DKIM ใส่ลายเซ็นเข้ารหัสกับรูปแบบที่ normalize แล้วของเนื้อความและ header บางส่วนของข้อความ โดยเก็บ public key สำหรับตรวจสอบไว้ใน DNS ที่ <selector>._domainkey.<domain>

  • DMARC และ SRS

    • DMARC ตรวจว่าโดเมนที่ผ่านการยืนยันด้วย SPF และ DKIM ตรงกับ header From: ที่ผู้ใช้มองเห็นหรือไม่ และบอกผู้รับว่าควรจัดการอย่างไรเมื่อไม่ผ่าน
    • นโยบาย DMARC ของ Recoil คือ p=quarantine และรับรายงานสรุปผ่านที่อยู่ rua= เพื่อดีบักปัญหาด้านการส่งถึง
    • ผู้รับรายใหญ่จะส่งรายงาน XML สรุปข้อความที่อ้างตัวว่าเป็น recoil.org ประมาณวันละครั้ง ซึ่งรวมถึง Google, Microsoft, Yahoo และ Fastmail
    • เมลที่ถูกส่งต่ออาจกลายเป็นรูปแบบที่โดเมนผู้ส่งเดิมถูกส่งออกจาก IP ของ Recoil ทำให้ SPF ล้มเหลวได้
    • SRS จะเขียน envelope sender ใหม่ให้อยู่ในรูปแบบเช่น SRS0=…=example.com=original@recoil.org เพื่อให้การตรวจ SPF ฝั่งปลายทางประเมินโดยอิงโดเมนของ Recoil

การเข้าถึงของผู้ใช้และเว็บเมล

  • ผู้ใช้สามารถเข้าถึงอีเมลผ่าน IMAP client ทั่วไปที่เชื่อมกับเซิร์ฟเวอร์ Dovecot หรือเปิดเว็บเมลที่โฮสต์เองผ่านเบราว์เซอร์
  • Dovecot จัดการการเข้าถึง mailbox ของ pork และเข้ารหัส listener ด้วย TLS เพื่อไม่ให้อีเมลหรือรหัสผ่านแบบ plain text วิ่งผ่านเครือข่ายสาธารณะ
  • ใช้ใบรับรองจาก LetsEncrypt และให้บริการ host alias หลายตัวอย่าง imap.recoil.org, smtp.recoil.org ผ่าน SNI
  • Dovecot ยังทำหน้าที่เป็น SASL backend ให้ Postfix ด้วย ทำให้ผู้ใช้ใช้รหัสผ่านเดียวกันทั้งสำหรับ IMAP และการส่ง SMTP ได้
  • Roundcube รันเป็นบริการ Docker Compose อยู่หลัง Caddy TLS reverse proxy และเชื่อมต่อไปยัง pork ผ่าน TLS/IMAP เหมือนไคลเอนต์ทั่วไป

  • ปลั๊กอินของ Roundcube

    • ปลั๊กอิน managesieve ของ Roundcube ใช้โปรโตคอล ManageSieve เพื่อให้แก้ไข Sieve filter ผ่านเบราว์เซอร์ได้
    • ปลั๊กอิน markasjunk เปลี่ยนปุ่ม “Junk” ในเว็บเมลให้กลายเป็นการย้ายไปโฟลเดอร์ Junk ซึ่งการย้ายนี้จะช่วยฝึกการจำแนกแฮม·สแปมโดยผู้ใช้ไม่ต้องรับรู้รายละเอียด
    • UI ของ Roundcube ManageSieve ไม่เปิดเผย Sieve DSL แบบดิบ

งานที่ยังเหลือและความหมายของการโฮสต์เอง

  • การตั้งค่าปัจจุบันค่อนข้างแข็งแรงในการใช้งานประจำวันตลอดช่วงไม่กี่สัปดาห์ที่ผ่านมา แต่ยังมีงานให้ทำอีก
  • recoil.org ประกอบการรับ·ส่ง·ตรวจสอบอีเมลด้วยการผสมระเบียน DNS อย่าง MX, A/AAAA, PTR, SPF TXT, DKIM TXT และ DMARC TXT
  • MTA-STS บอกให้เมลเซิร์ฟเวอร์อื่นสื่อสารผ่าน TLS ที่มีใบรับรองถูกต้องเท่านั้น เพื่อลดการโจมตีแบบ STARTTLS downgrade
  • DANE/TLSA ใช้ค่าแฮชของใบรับรอง TLS ที่ตรึงไว้ใน DNS แทน HTTPS แต่ต้องมี DNS zone ที่เซ็นด้วย DNSSEC จึงยังไม่ได้ deploy
  • SRS ถูก deploy ไปบางส่วนแล้ว แต่ยังไม่ได้ตรวจยืนยันในทุกเส้นทางการส่งต่อ และกรณีล้มเหลวที่เกี่ยวกับ INRIA ยังน่ากังวลเพราะอาจเชื่อมโยงกับ DMARC failure และผลต่อชื่อเสียงโดเมน

  • JMAP, ความปลอดภัย และการโฮสต์เองในอนาคต

    • JMAP เป็นโปรโตคอลเข้าถึงอีเมลที่ใช้ HTTPS และ JSON ซึ่งเหมาะกับไคลเอนต์เครือข่ายสมัยใหม่มากกว่า IMAP
    • Dovecot ไม่รองรับ JMAP แบบ native และ JMAP server อิสระที่ประเมินไว้ก็บังคับให้เลิกใช้ Maildir แล้วหันไปใช้ mailbox store ของตัวเอง
    • แผนที่กำลังพิจารณาคือวาง implementation ของ JMAP ที่เขียนด้วย OCaml ไว้หน้า Dovecot ในรูปแบบ translation proxy เพื่อแมปคำขอ JMAP ไปเป็นการเรียก IMAP แล้วส่งกลับเป็นคำตอบ JSON
    • การรันเมลเซิร์ฟเวอร์ในปี 2026 ต้องตั้งระเบียน DNS อย่างน้อยหกรายการให้ถูกต้อง และการหา IPv4 block จาก RIPE ใช้เวลาเกือบ 1 ปี
    • ช่องว่างเวลาระหว่างการเปิดเผย CVE กับการมีการปล่อย exploit จริงใส่ listener ของ SMTP/IMAP อาจไม่ได้วัดเป็นสัปดาห์อีกต่อไป แต่เป็นเพียงไม่กี่ชั่วโมง จึงต้องมี defense in depth เช่น การตรึงที่อยู่เฉพาะ การแยกคอนเทนเนอร์เว็บเมล greylisting และ DNSBL

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

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

 
GN⁺ 15 시간 전
ความคิดเห็นจาก Lobste.rs

  • ยังคงเห็นพวก คนเฝ้าประตู ที่ยืนกรานว่าสิ่งที่ทำกันมาหลายสิบปีนั้นเป็นไปไม่ได้อยู่เรื่อย ๆ
    ทั้งที่จริงแล้วแค่ตั้งค่า reverse DNS, SPF, DMARC, MTA-STS ก็เพียงพอแล้ว ค่าใช้จ่ายก็ไม่มากและไม่ได้ยากขนาดนั้น
    ตัวอย่างเมลเซิร์ฟเวอร์: https://poofydoof.zia.io/

    • ผมดูแล อีเมลแบบ self-hosted เองมาตั้งแต่ราว ๆ ปี 2008 และยังรู้สึกงงที่ยังมีคนจำนวนมากพูดว่ามันเป็นไปไม่ได้
      ตอนนี้ใช้ Debian + Postfix, Dovecot, rspamd และ Google Workspace ที่ที่ทำงานของผมกลับมีปัญหาบ่อยกว่าคอนฟิกของผมเองอีก
    • ผมคิดว่าประเด็นสำคัญคือส่วนที่ว่า “สิ่งที่ทำกันมาหลายสิบปี”
      การบอกว่าแค่ตั้ง reverse DNS, SPF, DMARC, MTA-STS ก็พอ นั้นถูกต้อง 100% สำหรับ โดเมนและ IP address ที่มีชื่อเสียงดีอยู่แล้ว
      ถ้าเพิ่มโดเมนใหม่เข้าไปในเมลเซิร์ฟเวอร์ที่ผู้ให้บริการรายใหญ่เชื่อถืออยู่แล้ว ชื่อเสียงก็จะสะสมได้เร็ว และถ้าย้ายโดเมนเดิมไปยัง IP ของเมลเซิร์ฟเวอร์ใหม่พร้อมตั้งค่า DKIM ด้วยก็ไม่น่ามีปัญหา
      แต่ถ้าเริ่มจากศูนย์ด้วยโดเมนใหม่และ IP ของเมลเซิร์ฟเวอร์ใหม่ ผมได้ยินมาว่าสถานการณ์ค่อนข้างต่างออกไป และมีโอกาสสูงที่จะถูกจัดเป็นสแปมอัตโนมัติจนกว่าระบบ machine learning ของผู้ให้บริการรายใหญ่จะพอใจ
      ดูเหมือนว่าวิธีที่ได้ผลบ่อยคือให้ผู้ใช้ของระบบฝั่งนั้นส่งอีเมลมาหาโดเมนของเรา แล้วดึงคำตอบกลับออกมาจากโฟลเดอร์สแปม
    • จากประสบการณ์ที่รันเมลเซิร์ฟเวอร์มาราว 3 ปี ส่วนที่ยากไม่ใช่การตั้ง DNS, SPF, DMARC, MTA-STS แต่เป็นเรื่อง อีเมลธุรกรรม ที่ต้องพยายามไม่ให้ไปชนบล็อกลิสต์ และการที่ผู้ให้บริการอีเมลบางรายไม่ยอมเพิ่มเราเข้า allowlist
      แทนที่จะเสียเวลาไล่ตามเรื่องพวกนี้ ผมคิดว่าจ่ายเดือนละประมาณ 5 ดอลลาร์ให้คนอื่นดูแลน่าจะคุ้มกว่า
    • เมลเซิร์ฟเวอร์ตัวอย่างดูเจ๋งดี และอันนี้ก็น่าสนใจ
      https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
      ผมอยากรู้รายละเอียดของชุดคอนฟิกนี้มากกว่านี้
      Mango Pi MQ-Pro ดูเหมือนจะหาซื้อยาก เลยสงสัยว่ามี อุปกรณ์ราคาถูกมาก ตัวอื่นที่รองรับ NetBSD/Linux ได้ดีไหม

  • อีกเหตุผลหนึ่งที่ควรรันเมลเซิร์ฟเวอร์เอง คือคุณอาจค้นพบว่ามีใครบางคนกำลัง ส่งสแปมโดยใช้โดเมนของคุณ อยู่แล้ว
    ตอนที่โดเมนหนึ่งของผมถูกย้ายไป Squarespace เพราะการขาย Google Domains, Squarespace ได้เพิ่ม DNS records สำหรับ MX/SPF/DKIM ของ Mailgun ให้อัตโนมัติ ทั้งที่ผมไม่มีบัญชี Mailgun
    มีใครบางคนไปยึดบัญชีนั้นบน Mailgun แล้วส่งสแปมมาหาผมโดยทำเหมือนว่าส่งมาจากโดเมนของผม
    ขอบคุณนะ Google

  • ส่วนของ การจัดสรร IPv4 น่าสนใจเป็นพิเศษ
    ถ้าจะทำเองในยุโรป บทความบอกว่าต้องจ่ายค่าสมาชิกรายปี RIPE NCC และเปิดบัญชี local internet registry (LIR) ซึ่งตาม https://www.ripe.net/membership/payment/ อยู่ที่ 1800 ยูโรต่อปี
    เจ็บพอตัว แต่ถ้าถูกกว่านี้พวกสแปมเมอร์ก็คงเอาไปใช้ในทางที่ผิดได้ง่ายขึ้นเหมือนกัน

    • มันไม่ถูก แต่ก็ตก ประมาณ 12 ปอนด์ต่อที่อยู่ต่อปี ดังนั้นถ้าแชร์กันใช้กับบริการสำหรับเพื่อนและครอบครัวในพื้นที่ก็ไม่ได้แย่มาก
      ความสนุกจากการเขียน BGP server ด้วย OCaml นั้นประเมินค่าไม่ได้ :-)

  • สงสัยว่าในทางปฏิบัติแล้วจะใช้ IPv6 สำหรับการรับส่งอีเมลได้จริงไหม

    • เป็นคำถามที่ดี
      ตอนเขียนบทความผมลองดูเรื่องนี้อยู่ แต่เพราะเมื่อหลายปีก่อนผมปิด IPv6 บนเมลเซิร์ฟเวอร์ไว้ เลยตัดสินใจพักเรื่องนี้ไว้ก่อนจนกว่าจะมีประสบการณ์มากขึ้น
      ตาม https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters ผู้ให้บริการอีเมลอย่าง Gmail, Microsoft, Yahoo ใช้ตัวกรองสแปมเฉพาะของตัวเองที่ให้น้ำหนักชื่อเสียงของโดเมนและชื่อเสียงของ IP ไม่เท่ากัน และการรองรับ IPv6 ก็ยังค่อย ๆ พัฒนาอยู่
      Gmail ต้องการ PTR record, SPF, DKIM ที่ถูกต้องสำหรับเมลผ่าน IPv6 และยังแนะนำอย่างมากให้ใช้ DMARC
      หากไม่มีองค์ประกอบเหล่านี้ อีเมลที่ส่งผ่าน IPv6 มักจะเข้าโฟลเดอร์สแปมหรือถูกหน่วงเวลา
      ระบบกรองของ Microsoft รวม IPv6 ไว้ในโปรแกรม SNDS และ JMRP แต่ก็อาจจำกัดหรือหน่วงอีเมลผ่าน IPv6 ได้หากชื่อเสียงของผู้ส่งยังไม่เป็นที่รู้จัก
      สุดท้ายแล้ว IPv6 ก็เป็นอีกหนึ่งจุดที่ล้มเหลวได้ และการตั้งค่า โดเมนส่งแบบผสม IPv4/IPv6 ตั้งแต่เริ่มต้นก็คงไม่ใช่ความคิดที่ดีนัก
      ผมยังไม่เจอ SMTP endpoint แบบ IPv6-only เลย