รันเซิร์ฟเวอร์อีเมลด้วยตัวเองเหมือนปี 1984

• การรันเซิร์ฟเวอร์อีเมลด้วยตัวเองช่วยให้จัดการงานอัตโนมัติและเมลลิงลิสต์ได้ในต้นทุนต่ำ
• มีปัญหาเรื่องความน่าเชื่อถือในการส่งในโลกความเป็นจริง จึงอาจเกิดการส่งหรือรับอีเมลล้มเหลวกับบริการรายใหญ่ได้
• เพียงตั้งค่า Postfix และ OpenDKIM ก็สามารถสร้างระบบ SMTP และการส่งเมลที่ยืนยันตัวตนขั้นพื้นฐานได้
• การตั้งค่า ใบรับรอง SSL, DKIM, SPF, DMARC ช่วยเพิ่มความน่าเชื่อถือของอีเมลและความปลอดภัยในการส่ง
• หากตั้งค่า เรคคอร์ด PTR (reverse DNS) เพิ่มเติม ก็อาจช่วยเพิ่มอัตราการส่งถึงบริการอีเมลรายใหญ่ได้

---

ภาพรวม

การรันเซิร์ฟเวอร์อีเมลด้วยตัวเองมีประโยชน์สำหรับงานอัตโนมัติอย่าง เมลลิงลิสต์, จดหมายข่าว, API สำหรับยืนยันอีเมล เป็นต้น
อย่างไรก็ตาม อุปสรรคสำคัญที่สุดในทางปฏิบัติคือ ความน่าเชื่อถือในการส่งอีเมล เพราะมีความเสี่ยงที่อีเมลจะไปไม่ถึงหรือรับไม่สำเร็จ
ผู้ดูแลยอมรับความเสี่ยงนี้และนำวิธีดังกล่าวไปใช้กับโปรเจกต์ส่วนตัว
ข้อดีของการดูแลเองคือแทบไม่มีค่าใช้จ่ายเพิ่ม เพราะ เพียงติดตั้งซอฟต์แวร์บนเว็บไซต์เดิม ก็ใช้งานได้ และยังใช้พื้นที่เก็บข้อมูลกับพลังงานน้อยมาก
เดิมทีคิดว่าการรันเซิร์ฟเวอร์อีเมลคงยากมาก แต่ในความเป็นจริงก็ไม่ได้ต่างจากการตั้งค่าบริการอีเมลแบบ SaaS มากนัก
เพื่อให้ตั้งค่าได้สะดวกและเรียบง่าย บทความนี้จึงละ เว็บเมลและสภาพแวดล้อมหลายผู้ใช้ ออกไปก่อน ทำให้ไม่ต้องตั้งค่าบัญชีผู้ใช้ ฐานข้อมูล หรือเว็บอินเทอร์เฟซ
การตั้งค่านี้เหมาะกับการใช้งานบัญชีเดียว และหากจำเป็นก็สามารถส่งและรับอีเมลผ่าน SSH รวมถึง mailx, sendmail, mutt ได้
ในอนาคตหากจำเป็นก็สามารถขยายระบบและเพิ่มเว็บเมลได้

Postfix

โดยพื้นฐานแล้ว หากเปิด พอร์ต 25 และติดตั้งพร้อมตั้งค่า Postfix กับ OpenDKIM ก็สามารถสร้างเซิร์ฟเวอร์ SMTP พื้นฐานได้
หากต้องการส่งอีเมลไปยังบริการส่วนใหญ่ เช่น Gmail ได้อย่างเสถียร จำเป็นต้องใช้ OpenDKIM (การยืนยันตัวตนอีเมล)
ผู้เขียนคงค่าเริ่มต้นของ master.cf ไว้ตามเดิม และในตัวอย่างการตั้งค่าหลัก (main.cf) จะแสดงเฉพาะค่าที่สำคัญอย่าง การเข้ารหัส TLS และการเชื่อมต่อ DKIM
ไม่ได้ตั้งค่า POP3/IMAP และเลือกทำให้เรียบง่าย โดยหากจำเป็นก็เชื่อมต่อเซิร์ฟเวอร์ผ่าน SSH โดยตรง แล้วใช้คำสั่งอย่าง mailx เพื่อส่งและรับอีเมลได้

TLS (การเข้ารหัสระหว่างการส่ง)

ใบรับรอง SSL จำเป็นสำหรับเข้ารหัสการส่งข้อมูลกับเซิร์ฟเวอร์ SMTP
ไม่จำเป็นต้องออกใบรับรองสำหรับทุกโดเมน เพราะมีใบรับรองเฉพาะโฮสต์เดียวที่ใช้เป็นเมลเซิร์ฟเวอร์ (สำหรับ MX record) ก็เพียงพอ
ตัวอย่างเช่น หาก MX record คือ mx.example.com ก็แค่ออกใบรับรองฟรีจาก Let’s Encrypt ให้โดเมนนั้นแล้วนำมาใช้
TLS จะเข้ารหัสเฉพาะช่วงการรับส่งระหว่างเซิร์ฟเวอร์ และเป็นคนละเรื่องกับการยืนยันชื่อโดเมนของผู้ส่งจริง
ดังนั้นในส่วนหัว From ของอีเมลจึงสามารถกำหนดค่าที่ต้องการได้อย่างอิสระ

DKIM, SPF, DMARC

DKIM ใช้พิสูจน์ว่าอีเมลถูกส่งมาจากโดเมนของตนจริง เพื่อเพิ่มความน่าเชื่อถือของอีเมล
สามารถใช้ OpenDKIM สร้างคู่กุญแจสำหรับแต่ละโดเมน แล้วลงทะเบียนกุญแจสาธารณะเป็น DNS TXT record
กุญแจเหล่านี้ไม่หมดอายุอัตโนมัติ แต่แนะนำให้หมุนเวียนเป็นระยะ
ควรเพิ่ม TXT record ของ SPF และ DMARC ใน DNS ด้วย เพื่อระบุว่าโฮสต์ใดมีสิทธิ์ส่งอีเมล และกำหนดนโยบาย DMARC (เช่น ปฏิเสธเมื่อยืนยันตัวตนไม่ผ่าน)
ในตัวอย่างไฟล์ตั้งค่า (opendkim.conf, KeyTable, SigningTable, TrustedHosts) สามารถดูวิธีตั้งค่าแต่ละรายการได้อย่างชัดเจน
ใน DNS เพียงเพิ่มเรคคอร์ดที่เกี่ยวข้องกับ MX, SPF, DKIM และ DMARC ก็เพียงพอ

reverse DNS (PTR)

เรคคอร์ด PTR (reverse DNS) ช่วยเพิ่มความน่าเชื่อถือของเมลเซิร์ฟเวอร์ และลดโอกาสที่อีเมลจะถูกบล็อกโดยบริการรายใหญ่อย่าง Gmail
จำเป็นต้องติดต่อ ISP เพื่อขอให้ตั้งค่า PTR record สำหรับเมลเซิร์ฟเวอร์
ในสภาพแวดล้อมที่ใช้งานจริง แม้ไม่มี PTR record ก็ยังรับอีเมลได้ตามปกติใน Gmail, GMX, Outlook และได้คะแนน 10/10 จาก mail-tester.com
แม้จะถูกหักคะแนนเพราะยังไม่ได้ตั้งค่า PTR แต่ก็ได้คะแนนเพิ่มจากการเป็น "trusted relay"
และยังไม่ถูกขึ้นบัญชีดำ ทำให้ความน่าเชื่อถือของ IP ที่ใช้ส่งอยู่ในระดับดี

ทดสอบการส่งไปยัง Gmail

ใช้คำสั่ง sendmail เพื่อส่งอีเมลทดสอบ (ข้อความ HTML) ไปยัง Gmail
อีเมลมาถึง Gmail ทันที และยืนยันได้ว่าใช้ การเข้ารหัส TLS
เมื่อดูต้นฉบับอีเมลผ่าน "Show original" จะเห็นว่า SPF, DKIM และ DMARC ผ่านการยืนยันทั้งหมด
สามารถใช้ mailx เพื่อตรวจสอบเนื้อหาอีเมลที่รับบนเครื่องโลคัล (เซิร์ฟเวอร์) ได้
หากมีปัญหาในการตั้งค่า ควรตรวจสอบ DNS, ใบรับรอง, สิทธิ์การเข้าถึงกุญแจ DKIM อีกครั้ง โดยเฉพาะไฟล์ตั้งค่าของ OpenDKIM ที่ไวต่อการพิมพ์ผิดมาก

ขั้นตอนถัดไป

ในบทความถัดไป ผู้เขียนจะอธิบายวิธีสร้าง แอปพลิเคชันอีเมลด้วย Python
หากมีคำถามหรือความเห็น สามารถติดต่อได้ที่ [e-mail]

[GN⁺]

ความคิดเห็นบน Hacker News

• รู้สึกภูมิใจที่โฮสต์อีเมลเองมานานกว่า 20 ปี และก็วางแผนจะทำต่อไป หน่วยงานรัฐหรือหน่วยงานที่เกี่ยวข้องกลับดูแลระบบอีเมลเองไม่ได้ มีเพียงหน่วยงานความมั่นคงของรัฐเท่านั้นที่โฮสต์เอง เท่าที่ผ่านมาอาจเพราะโชคดี ปัญหาเรื่องการส่งเมลแทบไม่มีเลย เคสล่าสุดที่จำได้คือ Microsoft กลืนเมลของผมไป ซึ่งเกิดจาก TLS authentication ที่ตีกันระหว่าง exim รุ่นเก่ากับฝั่ง outlook แก้โดยปรับ config จุดเดียวก็จบ งานดูแลรักษาเองก็ไม่ได้กินแรงมากนัก เลยใช้โอกาสทุกครั้งที่ต้องไปแตะระบบเพื่อเรียนรู้อะไรใหม่ ๆ ปีนี้ผมย้ายจาก Debian jessie ไป Arch Linux และย้ายงาน cron ไปเป็น systemd timer ทั้งหมด เวลาส่งเมลสำคัญก็จะเช็ก server log เสมอ ซึ่งผมคิดว่านี่ก็เป็นนิสัยที่ดีของการดู log เอง คำแนะนำของผมคือ ถ้ามองการโฮสต์เองเป็นงานอดิเรกและสนุกกับมันได้ จะดีขึ้นมาก สุดท้าย คนที่ออกแบบการตั้งค่า Exim บน Debian นี่ทำให้ผมเสียเวลาไปเยอะมาก ถ้าจะติดตั้ง Exim บน Debian ทางออกคือเปลี่ยนไปใช้ config ทางการของ upstream แล้วค่อยปรับแต่งให้เข้ากับตัวเอง

  • ทุกวันนี้ SNS ชอบอวดเรื่อง “decentralized” หรือ “open” แต่จริง ๆ แล้วเรามีเครื่องมือที่ทำให้พึ่งพาตัวเองได้อย่างอิสระครบถ้วนอยู่แล้ว หลายครั้งพอพูดว่าจะปรับปรุง UX ก็กลับมองข้ามไปว่าผู้ใช้กำลังสูญเสียอำนาจควบคุม สุดท้ายถ้าคนคุ้นชินกับระบบที่ถูกทำให้ง่ายเกินไป อนาคตอาจกลายเป็นโลกที่ใครสักคนในอีกที่หนึ่งไม่อนุญาต “ธุรกรรม” คุณก็จะติดตั้งแอปสักตัวไม่ได้ด้วยซ้ำ

  • ผมเริ่มใช้อีเมลครั้งแรกตอนเรียนมหาวิทยาลัย (ก่อนยุค WWW) ต่อมาก็ใช้บัญชีจาก ISP ที่มีพื้นที่จำกัดมากและรองรับแค่ POP เลยหันมารันเมลเซิร์ฟเวอร์เอง ตอนนั้นไม่ได้ต่ออินเทอร์เน็ตตลอดเวลา จึงรับเมลผ่าน relay และ dynamic DNS ปัจจุบันใช้ VPS เป็นตัวกลางแล้วให้เซิร์ฟเวอร์ที่บ้านรับและเก็บเมล ตลอดหลายปีที่ผ่านมาก็เคยต้องขอปลด IP หรือโดเมนกับผู้ให้บริการเมลรายใหญ่อย่าง Outlook บ้าง แต่ก็ไม่ได้เกิดบ่อย ผมไม่อยากอยู่ในโลกที่มีบริษัทแค่สองสามแห่งครองอีเมลทั้งโลก เลยคิดว่าการโฮสต์เองแบบนี้เป็นการต่อต้านเล็ก ๆ อย่างหนึ่ง

  • อยากให้ตัวเองยังมีแรงจูงใจแบบเมื่อ 20 ปีก่อนเหลืออยู่สัก 1% ทุกวันนี้มีงานประจำเต็มเวลาและมีครอบครัวแล้ว (ภรรยาและลูก) เลยไม่มีเวลาพอจะทำอะไรแบบนั้น

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

  • สำหรับผม อีเมลเป็นบริการที่สำคัญมาก เหตุผลที่เลิกโฮสต์เองหลังทำมา 15 ปีคือ 1) ทำเรื่อง backup/restore และ monitoring ตามรอบได้ไม่ดี 2) ไม่มีแผน disaster recovery เลยแพงกว่าบริการอื่น และ 3) ดูแลเรื่องความปลอดภัยได้ไม่สม่ำเสมอ เซิร์ฟเวอร์ของเพื่อนผมเคยโดน ransomware จนข้อมูลหายหมด แต่ของผมรอดเพราะเป็น FreeBSD (ไม่ใช่เป้าหมายโจมตี) โดยทั่วไปการดูแลไม่ได้ซับซ้อนมาก แต่ถ้าพังขึ้นมาจริง ๆ จะทรมานมาก และอาจถึงขั้นร้ายแรงได้

• เมื่อก่อนผมโฮสต์อีเมลเอง แต่ที่ยอมแพ้ไม่ใช่เพราะเรื่อง reputation หากเป็นเพราะเลี่ยงการต้อง online 100% ไม่ได้ จึงเสี่ยงต่อการทำเมลหายหรือถูก blacklist ตามทฤษฎีแล้วโปรโตคอลอีเมลทนต่อ downtime ได้ แต่ในทางปฏิบัติผู้ให้บริการอีเมลรายใหญ่หลายเจ้าพอเจอปัญหาครั้งเดียวก็ปฏิเสธเมลทันทีและไม่ retry อีก เมื่อก่อนแม้แต่ GitHub ถ้า bounce ครั้งเดียวก็จะมาร์กว่า “ส่งไม่ได้” แล้วไม่ส่งอีกเลย ตอนนี้ดีขึ้นแล้ว แต่ระบบอีเมลสมัยใหม่ตั้งอยู่บนสมมติฐานว่า “ต้อง online ตลอดเวลา”

  • เมลเซิร์ฟเวอร์ของผมใช้ฟังก์ชัน greylist ที่จงใจปฏิเสธเมลครั้งแรกที่เข้ามา ผมรับเมลมาจำนวนมากและไม่เคยมีกรณีที่เมลปกติส่งไม่ถึงเลย การส่งซ้ำเป็นส่วนหนึ่งของมาตรฐานอีเมลอยู่แล้ว ถ้ากังวลก็เพิ่ม backup inbound mail server แล้ว backhaul ด้วย LMTP ได้ ระบบอีเมลถูกออกแบบมาตั้งแต่ยุคที่ไม่ได้คาดว่าทุกอย่างจะเชื่อมต่ออยู่ตลอด 24 ชั่วโมง

  • เรื่องแบบนี้พูดเกินจริงไปหน่อย ในกรณีของผม ถ้าเมลไม่มา อีกไม่กี่ชั่วโมงหรือวันหนึ่งมันก็มาถึงเอง และปกติก็ไม่มีทางรู้ได้ชัดว่าปัญหาเกิดตรงไหน แค่ทำ authentication ให้ถูกต้อง (เช่น dkim, spf) การโฮสต์เองก็ทำให้มีโอกาสส่งถึงเกิน 99% ได้ ไม่ต้องกลัวความซับซ้อนมากนัก แถมยังใช้ caldav แบบส่วนตัวได้อีกด้วย

  • ผมสงสัยว่าทำไมเซิร์ฟเวอร์ล่มไม่กี่ชั่วโมงถึงต้องกังวลเรื่อง “เมลหาย” เซิร์ฟเวอร์ของผม uptime ต่อเนื่องมา 219 วันแล้ว เมื่อเทียบกับงานทั่วไปที่เราทำกัน การดูแลเมลเซิร์ฟเวอร์นี่ง่ายมากจริง ๆ

  • ทุกครั้งที่มองระบบอีเมลสมัยนี้ ผมรู้สึกเหมือน “พวกเขาทำอะไรกับลูกชายของฉัน”

• คำแนะนำสำหรับคนที่อยากเริ่มโฮสต์อีเมลเอง: ลองใช้อีเมลที่โฮสต์เองแค่สำหรับสมัครบัญชีก่อน ไม่จำเป็นต้องใช้ติดต่อส่วนตัวตั้งแต่แรก ใช้ “Mail-in-a-box” ก็ได้ https://mailinabox.email./ แค่ทำตามคู่มือติดตั้งก็สร้างเสร็จในไม่กี่ชั่วโมงและใช้งานได้ดี ลองใช้สัก 1-2 ปี พอคุ้นมือจริง ๆ แล้วค่อยย้ายการติดต่อส่วนตัวตามมา

  • ขอแนะนำ Stalwart https://github.com/stalwartlabs/stalwart เป็นบริการเมลแบบครบใน binary เดียว ไม่มี dependency ติดตั้ง/อัปเดตง่ายมาก ผมลองมาหลายโปรเจกต์แล้ว Stalwart สะดวกที่สุด และรันได้โดยไม่มีปัญหาเลย

  • ผมรัน MIAB บนคลาวด์มาหลายปีแล้ว ถ้า IP reputation สะอาด การส่งออกก็ไม่มีปัญหา แต่ถ้าอีเมลไปไม่ถึงฝั่ง Outlook ผมก็ส่งเมลหา Microsoft postmaster ตรง ๆ เพื่อแก้ไข มันเหมาะกับการเรียนรู้เรื่องการตั้งค่าอย่าง DKIM/SPF/DMARC เลยอยากแนะนำ อย่างไรก็ตาม การรับอีเมลสมัครสมาชิกนั้นลำบากจริง ๆ greylist ของ MIAB จะปฏิเสธผู้ส่งที่เพิ่งส่งมาครั้งแรกแล้วรอให้ retry แต่แม้แต่เว็บไซต์ปกติหลายแห่งก็ไม่ retry ทำให้อีเมลยืนยันตัวตนหรือรหัส 2FA มาช้ามาก และก็ไม่มีวิธีง่าย ๆ ในการปิดตัวกรองสแปมชั่วคราว

• ทุกวันนี้แม้แต่อีเมลจาก ISP หรือกระทั่ง Google Gmail เองก็ยังมีปัญหาเรื่อง spam filtering เป็นบางครั้ง เช่น ถ้าสั่งซื้อผ่าน Shopify อีเมลจาก Shopify ก็ยังโดน Gmail จัดเป็นสแปมอยู่เรื่อย ๆ ทั้งที่ DMARC, SPF, DKIM ผ่านหมดแล้วก็ยังไม่รู้ว่าทำไมถึงโดน การรับส่งอีเมลเองในเชิงเทคนิคไม่ได้ยากนัก และไม่ว่าคุณจะใช้บริการไหนก็ไม่มีทางสมบูรณ์แบบ 100% อยู่ดี ผู้ใช้ไม่หวังดี (สแปมเมอร์) มีมากเสียจนระบบนี้ยังทำงานได้ดีขนาดนี้ก็น่าทึ่งแล้ว

  • DMARC, SPF, DKIM และอย่างอื่นทำนองนี้เป็นแค่การตั้งค่าด้าน authentication ไม่ได้เกี่ยวกับว่าเป็นสแปมหรือไม่โดยตรง มีทั้งเมลขยะที่ยืนยันตัวตนถูกต้อง และเมลดี ๆ ที่ไม่ได้ยืนยันตัวตน

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

  • ผมโฮสต์อีเมลเองมาเกือบ 20 ปี ช่วง 10-15 ปีแรก forward เมลทั้งหมดไป Gmail แต่หลังจากเบื่อ spam filter ที่ทำให้แม้แต่เมลสำคัญก็หายไป ผมก็เริ่มรัน imapd เอง ถ้าตั้งค่า SPF และอย่างอื่นให้ถูกต้อง ผมรู้สึกว่าการโฮสต์เองดีกว่ามาก

  • นโยบายการกรองแบบนี้แหละคือตัวปัญหา ถ้าโฮสต์เองหรือใช้บริการอีเมลขนาดเล็ก โอกาสที่เมลจะโดนบล็อกกลับน้อยกว่ามาก โดยเฉพาะกับตัวกรองเข้ม ๆ ของ Gmail และบริการทำนองเดียวกัน ทั้งที่ Google เองก็มีผู้ใช้ Gmail ที่เป็นต้นตอของสแปมอยู่มากมาย แต่ก็ยังใช้นโยบายกรองหนักเหมือนเดิม

  • ช่วงนี้ spam filter ของ Gmail ไวต่อเมลการตลาดมากเกินไป เมื่อ 10 ปีก่อนปัญหากลับกัน แต่ตอนนี้กลับกรองลง spam เยอะจนรำคาญ จริง ๆ แล้วสแปมสมัยนี้จำนวนมากเป็น cold email จากที่อยู่อีเมลใหม่ขนาดเล็ก ฟีเจอร์ “unsubscribe” ของ Gmail ใช้ได้ดีกับเมลการตลาด แต่แทบไม่ช่วยอะไรกับ cold email แบบนี้

• ถ้าต้องการ IMAP server ที่ตั้งค่าได้ครบถ้วนและเชื่อมกับไคลเอนต์หลากหลายได้ดี คู่มือ https://workaround.org/ispmail-bookworm/ น่าจะเหมาะกว่า ผมเองรันแบบง่าย ๆ ด้วยไฟล์ข้อความธรรมดาแทนฐานข้อมูล ถ้ามีผู้ใช้แค่ผมคนเดียวก็ใช้แบบนี้ได้สบาย และคู่มือนี้ก็ขยายไปใช้ระดับองค์กรใหญ่ได้เช่นกัน

  • ผมก็ใช้คู่มือข้างต้นเหมือนกัน แต่เปลี่ยนฐานข้อมูลมาใช้ PostgreSQL หลังอัปเกรดเป็น Trixie ล่าสุด การตั้งค่า Dovecot เปลี่ยนไปมากจนเหนื่อยอยู่พักหนึ่ง แต่ตอนนี้ก็กลับมารันได้ปกติแล้ว

• โปรโมตตัวเองนิดหนึ่ง: เรากำลังเบตาเทสต์ Hyvor Relay https://github.com/hyvor/relay ซึ่งเป็นทางเลือกแบบ self-hosted เราโฟกัสที่การมองเห็นสถานะ เช่น monitoring ของ DKIM/SPF และการทำ DNS automation แค่ docker compose up ครั้งเดียวก็พร้อมใช้งานทันที https://relay.hyvor.com/hosting/deploy-easy

• ตลอด 10-15 ปีที่ผ่านมา ผมโฮสต์อีเมลเองบนกล่อง kimsufi ราคาถูกด้วย opensmtp, dovecot และ rspamd โดยรวมแทบไม่มีปัญหาอะไร มีครั้งหนึ่งเซิร์ฟเวอร์เคยถูกบล็อกโดย telekom.de แต่พออธิบายผ่านอีเมลทางการก็ถูก whitelist กลับทันที อาจเพราะผมถือ IP เดิมมานาน เลยไม่ค่อยเจอปัญหาแบบที่คนอื่นพูดถึงกัน อย่างไรก็ตาม เซิร์ฟเวอร์และ IP นั้นเป็นชื่อของผมเอง

• ผมแชร์บทความภาษาเยอรมันเกี่ยวกับการโฮสต์อีเมลเองบน Debian trixie ไว้ที่ https://krei.se/Doc ถ้าติดตั้งเองดี ๆ มันสนุกมาก ผมมีอัปเดตอัตโนมัติ รีบูตอัตโนมัติ และ systemd แบบปรับแต่งเองที่ส่งรายงานสถานะทางอีเมลให้ทุกวัน เป็นระบบที่เสถียรมากจน 2-3 ปี หรือถ้าเป็น trixie ก็อาจได้ถึง 5 ปีโดยแทบไม่ต้องแตะอะไรเลย ซอฟต์แวร์เมลเซิร์ฟเวอร์ทุกวันนี้สุกงอมมากแล้ว ผมแนะนำให้โฮสต์เองจริง ๆ อิสระ ความสงบ และการควบคุมด้วยตัวเองมีคุณค่ามาก

• ผมดูแลอีเมลเองมาเกิน 10 ปีแล้ว และเคยทิ้งลิงก์คอมเมนต์ HN เก่า ๆ ไว้ด้วยเป็นครั้งคราว (เช่น 39891262, 38471262) เพราะ IP ของ Digital Ocean ถูกมองว่าเป็นอันตราย ผมเลยเปลี่ยนการส่งออกไปใช้ Amazon SES และใช้ Gmail เป็นตัวฝึกสแปมฟรีสำหรับ feed เข้า filter ของตัวเอง (38843288) อย่างที่หลายคนพูด greylist ช่วยได้มาก เมลเซิร์ฟเวอร์ปกติจะ retry แน่นอน จึงแม้จะไม่สะดวกกับอีเมล 2FA แต่ในเชิงระบบยังเชื่อถือได้ หาก downtime เป็นวัน ๆ ก็ยังไม่ต้องกังวล และยังแยกเซิร์ฟเวอร์รับ/เก็บเมลเพื่อให้ง่ายต่อการแบ็กอัปได้ด้วย (38512732) เรื่องเมล 2FA ผมใช้ https://github.com/stevejenkins/postwhite ควบคู่ไปด้วย แต่จริง ๆ แล้วผมไม่อยากแนะนำให้ใช้อีเมลสำหรับ 2FA เท่าไร (ประเด็นนี้ควรคุยแยกอีกเรื่อง)

  • ไม่นานมานี้ผมไม่ได้รับอีเมลสำคัญที่ส่งจาก Amazon SES เพราะติดรายการบล็อกสแปม (bl.spamcop.net) Amazon พยายาม retry ผ่านหลาย IP แล้วก็ไปเจอ greylist สุดท้ายครั้งหนึ่งเลยถูกปฏิเสธ แม้การส่งระหว่างผู้ให้บริการรายใหญ่ (MX ถึง MX) อาจมีปัญหาน้อยกว่า แต่โครงสร้างแบบนี้ก็ไม่ใช่ทางออกที่สมบูรณ์ 100% เช่นกัน

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

• UUCP อยู่ไหน แล้วทำไมแอดเดรสไม่ใช่ bang path แล้ว sendmail.cf หายไปไหน นี่คือสิ่งที่ผมสงสัย

  • ใช่เลย ถ้าจะโฮสต์เองแบบสไตล์ปี 1984 (อีเมลยุคคลาสสิก) ก็จะกลายเป็น open relay ที่ส่งต่อเมลทุกอย่าง และเปิดช่องให้เจอช่องโหว่สารพัดจนเสี่ยงอันตราย

  • พอพูดถึงยุคนั้น ผมก็นึกถึงตอนอยู่ห้องแล็บมหาวิทยาลัยที่มี Unix workstation 6 เครื่อง แล้วอีเมลถูกย้ายจากเซิร์ฟเวอร์หนึ่งไปอีกเซิร์ฟเวอร์หนึ่ง จนได้ยินเสียงดิสก์ทำงานแล้วรู้สึกได้ว่าเมลกำลังวิ่งอยู่จริง ๆ

  • ผมก็เหมือนกัน เห็นชื่อเรื่องแล้วนึกถึง bang path กับแอดเดรส “killer!jolet!” ขึ้นมาทันที คิดถึงยุคนั้นมากจริง ๆ

  • เห็นด้วย ผมกดเข้ามาเพราะชื่อ ‘1984’ แต่สุดท้ายกลับเป็นเรื่อง ‘การตั้งค่า postfix’ เลยผิดหวังนิดหน่อย