คำศัพท์ · โปรโตคอลอีเมล SMTP

โปรโตคอลอีเมล SMTP คืออะไร และส่งผลต่ออีเมลของแอปพลิเคชันอย่างไร

SMTP หรือ Simple Mail Transfer Protocol คือโปรโตคอลตามมาตรฐานที่ระบบอีเมลใช้ส่ง รีเลย์ และส่งต่ออีเมลขาออก โดยปกติแอปพลิเคชันจะส่งข้อความที่เสร็จสมบูรณ์ให้บริการส่งที่ยืนยันตัวตนแล้ว จากนั้นเซิร์ฟเวอร์อีเมลใช้คำสั่ง SMTP และการกำหนดเส้นทางผ่าน DNS เพื่อเคลื่อนย้ายข้อความไปยังผู้รับแต่ละราย การตอบกลับของ SMTP บอกว่าฮ็อปหนึ่งยอมรับหรือปฏิเสธผู้รับรายหนึ่ง แต่การยอมรับไม่เท่ากับการเข้ากล่องจดหมาย แอปพลิเคชันยังต้องมีคิวที่คงทน การลองใหม่ที่ปลอดภัย ตัวระบุข้อความ การยืนยันตัวตน และการประมวลผลอีเมลตีกลับ

SMTP ถ่ายโอนอีเมลระหว่างระบบที่รับผิดชอบ

SMTP เป็นโปรโตคอลถ่ายโอนแบบ store-and-forward ไคลเอนต์เปิดเซสชันกับเซิร์ฟเวอร์ ระบุตัวตน ส่งผู้ส่งใน envelope เสนอผู้รับใน envelope หนึ่งรายหรือมากกว่า และส่งเนื้อหาข้อความหลังจากเซิร์ฟเวอร์ตกลงรับ เซิร์ฟเวอร์อาจยอมรับผู้รับบางรายและปฏิเสธบางราย สถานะจึงเป็นของผู้รับและธุรกรรม ไม่ใช่ของข้อความโดยรวมเท่านั้น เมื่อเซิร์ฟเวอร์ยอมรับความรับผิดชอบแล้ว อาจส่งภายในเครื่องหรือรีเลย์ข้อความไปยังระบบอื่นที่เลือกผ่านเรคคอร์ด Mail Exchanger ของ DNS การออกแบบแบบทีละฮ็อปนี้คือเหตุผลที่แอปพลิเคชันไม่ควรลดสถานะอีเมลเหลือค่า boolean เดียวว่าส่งแล้ว แอปพลิเคชัน บริการส่ง รีเลย์ เซิร์ฟเวอร์ผู้รับ และระบบกรองกล่องจดหมายต่างรู้ส่วนต่างกันของผลลัพธ์ SMTP เคลื่อนย้ายข้อความระหว่างระบบ ขณะที่บันทึกระดับผลิตภัณฑ์และอีเวนต์ของผู้ให้บริการทำให้ผู้ใช้และผู้ดูแลเข้าใจการเคลื่อนย้ายนั้น

การส่ง (submission) และการรีเลย์เป็นบทบาทของโปรโตคอลที่ต่างกัน

RFC 6409 แยกการส่งข้อความ (submission) ออกจากการรีเลย์ข้อความ Submission คือการส่งต่อครั้งแรกจากผู้ใช้หรือแอปพลิเคชันที่ได้รับอนุญาตไปยัง Message Submission Agent โดยปกติใช้พอร์ต 587 ส่วนการรีเลย์คือการถ่ายโอนระหว่าง Message Transfer Agent และตามธรรมเนียมใช้พอร์ต 25 บริการ submission บังคับให้ยืนยันตัวตน ตรวจสอบหรือเติมฟิลด์ข้อความ และบังคับใช้นโยบายผู้ส่งได้ เพราะรู้ว่าใครเป็นผู้นำอีเมลใหม่เข้าระบบ เซิร์ฟเวอร์รีเลย์สาธารณะต้องทำงานร่วมกับโดเมนอื่นและใช้กฎความเชื่อถือที่ต่างออกไป โค้ดของแอปพลิเคชันจึงควรเชื่อมต่อกับ endpoint submission ที่ผู้ให้บริการระบุ หรือใช้ HTTP API ของผู้ให้บริการ ไม่ใช่เปิดการเชื่อมต่อพอร์ต 25 ไปยังเซิร์ฟเวอร์ปลายทางตามใจ การแบ่งนี้ยังทำให้เห็นชัดเรื่องข้อมูลรับรอง ชื่อผู้ใช้หรือโทเค็น SMTP อนุญาตให้ส่งไปยังบริการเฉพาะ ไม่ได้ให้อำนาจเหนือโดเมนปลายทาง เก็บข้อมูลรับรอง submission ไว้ฝั่งเซิร์ฟเวอร์ จำกัดขอบเขตให้กับปริมาณงานที่ส่งเมื่อผู้ให้บริการรองรับ และหมุนเวียนโดยไม่ฝังไว้ในเนื้อหาข้อความหรือซอฟต์แวร์ฝั่งไคลเอนต์

envelope ของ SMTP ต่างจากเฮดเดอร์ข้อความที่มองเห็น

ธุรกรรม SMTP นำ envelope ที่มีคำสั่ง `MAIL FROM` และ `RCPT TO` หนึ่งคำสั่งขึ้นไป เนื้อหาที่ถ่ายโอนเป็นไปตาม Internet Message Format ที่ RFC 5322 กำหนดแยกต่างหาก โดยมีฟิลด์ เช่น From, To, Date, Subject และ Message-ID พร้อม body มาตรฐาน MIME ขยายเนื้อหานั้นสำหรับ HTML ส่วนทางเลือก ไฟล์แนบ และข้อมูลที่ไม่ใช่ ASCII ผู้ส่งใน envelope คือที่อยู่ที่ใช้สำหรับความล้มเหลวของการขนส่งและอาจต่างจากผู้เขียนใน From ที่มองเห็น ผู้รับใน envelope ก็อาจต่างจากฟิลด์ To และ Cc ที่มองเห็น เช่น Bcc อย่าสร้างโครงสร้างเหล่านี้ด้วยการต่อสตริงที่ไม่น่าเชื่อถือ ใช้ไลบรารีข้อความที่ยังมีการดูแล ตรวจสอบที่อยู่ บล็อกการแทรกบรรทัดใหม่ลงในฟิลด์เฮดเดอร์ และคง Message-ID ที่คงที่ เมื่อแก้ปัญหา ให้ตรวจทั้งสองชั้น ฟิลด์ From ที่มองเห็นถูกต้องไม่สามารถแก้ตัวตนใน envelope ที่ไม่ได้รับอนุญาตได้ และ envelope ที่ถูกต้องไม่ได้ทำให้ MIME ที่ผิดรูปแบบแสดงผลถูกต้อง

อ่านธุรกรรมเป็น state machine

เซสชัน Extended SMTP พื้นฐานเริ่มด้วยการทักทายจากเซิร์ฟเวอร์ แล้วตามด้วย `EHLO` เพื่อให้เซิร์ฟเวอร์ประกาศส่วนขยาย ไคลเอนต์อาจเจรจา TLS และการยืนยันตัวตนสำหรับ submission จากนั้นธุรกรรมอีเมลใช้ `MAIL FROM` หนึ่ง `RCPT TO` ต่อปลายทาง `DATA` ข้อความสมบูรณ์ที่จบตามการจัดกรอบของ SMTP และ `QUIT` อย่าถือตัวอย่างนี้เป็นเหตุผลให้พัฒนาโปรโตคอลระดับสายด้วยตนเอง ไลบรารี SMTP ที่พัฒนาเต็มที่จัดการตัวจบบรรทัด dot transparency การเจรจาความสามารถ การยืนยันตัวตน และสถานะ TLS ได้ปลอดภัยกว่า ติดตั้งการวัดผลในไลบรารีที่ระดับหมวดคำสั่งและรหัสตอบกลับ โดยไม่บันทึกข้อมูลรับรองหรือ body ข้อความทั้งหมด บันทึกว่าผู้รับรายใดล้มเหลวที่ขั้นใด และเซิร์ฟเวอร์รับผิดชอบแล้วหลังข้อมูลข้อความหรือไม่ ขอบเขตนั้นกำหนดว่าการลองใหม่เหมาะสมหรือไม่ เป็นไปได้ที่จะซ้ำหรือไม่ และความล้มเหลวจะมาพร้อม delivery-status notification ภายหลังแทนการตอบกลับทันทีหรือไม่

จัดประเภทรหัสตอบกลับก่อนตัดสินใจลองใหม่

คลาสการตอบกลับของ SMTP สื่อถึงการดำเนินการ การตอบกลับ 2xx หมายถึงคำสั่งนั้นเสร็จสมบูรณ์ การตอบกลับ 4xx เป็นการปิดงานเชิงลบแบบชั่วคราว ผู้ส่งที่มีคิวจึงลองใหม่หลังหน่วงเวลาได้ การตอบกลับ 5xx เป็นการปิดงานเชิงลบแบบถาวรสำหรับคำสั่งที่พยายาม และโดยปกติต้องแก้ไข ระงับการส่ง หรือให้มนุษย์ตรวจสอบ แทนการลองใหม่ซ้ำ ๆ รหัสสถานะแบบขยายเพิ่มการวินิจฉัยแบบมีโครงสร้าง `X.Y.Z` สำหรับเงื่อนไขของที่อยู่ กล่องจดหมาย ระบบ การกำหนดเส้นทาง โปรโตคอล เนื้อหา หรือความปลอดภัยและนโยบาย เก็บทั้งรหัสตัวเลขและข้อความของเซิร์ฟเวอร์ เพราะอย่างใดอย่างหนึ่งเพิ่มคุณค่าด้านการวินิจฉัยได้ แต่อย่าเปิดเผยการตอบกลับดิบที่มีข้อมูลผู้รับอย่างกว้าง ใช้ exponential backoff พร้อม jitter และอายุคิวสูงสุดกับความล้มเหลวชั่วคราว อย่าลองใหม่ก้าวร้าวจนปัญหาปลายทางชั่วคราวกลายเป็นทราฟฟิกที่ล่วงละเมิด สำหรับความล้มเหลวถาวรของที่อยู่ ให้หยุดการส่งอัตโนมัติไปยังปลายทางนั้นและอัปเดตสถานะการระงับการส่ง สำหรับความล้มเหลวด้านนโยบายหรือการยืนยันตัวตน ให้แก้ตัวตน DNS ข้อมูลรับรอง หรือเนื้อหาก่อนพยายามอีกครั้ง

ใช้ submission ที่เข้ารหัสและยืนยันตัวตน

SMTP เริ่มต้นเป็นโปรโตคอลขนส่งข้ามเครือข่ายที่มีสมมติฐานด้านความเชื่อถือต่างกัน ดังนั้น submission ที่ปลอดภัยจึงขึ้นกับส่วนขยายและนโยบายการติดตั้งใช้งาน STARTTLS อัปเกรดการเชื่อมต่อ SMTP เป็น TLS หลังจากนั้นไคลเอนต์ต้องทิ้งความสามารถที่เรียนรู้ก่อน handshake และออก `EHLO` อีกครั้ง RFC 8314 ปรับปรุงแนวทาง submission โดยถือว่าการเข้าถึงและการส่งแบบ cleartext ล้าสมัย และอธิบาย implicit TLS สำหรับ submission SMTP AUTH ที่มาตรฐานใน RFC 4954 ให้เซิร์ฟเวอร์ submission ยืนยันตัวตนไคลเอนต์ผ่านกลไกที่ประกาศไว้ ใช้ชื่อโฮสต์ พอร์ต โหมด TLS และคำแนะนำการยืนยันตัวตนปัจจุบันของผู้ให้บริการ แทนการเดาชุดค่า ตรวจสอบใบรับรองของเซิร์ฟเวอร์ และอย่าถอยกลับไปใช้ cleartext โดยไม่แจ้งเมื่อปริมาณงานต้องการ submission ที่ได้รับการปกป้อง เก็บรหัสผ่านหรือโทเค็นไว้ใน secret manager ใช้ข้อมูลรับรองแยกตามสภาพแวดล้อม และปิดกลไกการยืนยันตัวตนที่ล้าสมัย TLS ปกป้องการเชื่อมต่อหนึ่งฮ็อป ไม่ได้ยืนยันตัวตนผู้เขียนข้อความต่อผู้รับปลายทางทุกราย หรือทดแทน alignment ของตัวตนตาม SPF, DKIM และ DMARC

วินิจฉัยความล้มเหลวของอีเมลแอปพลิเคชันทีละฮ็อป

เริ่มจากบันทึกขาออกที่คงทนของแอปพลิเคชัน อีเวนต์ของผลิตภัณฑ์ได้รับอนุญาตหรือไม่ และมีเพียงงานเดียวในคิวที่อ้างสิทธิ์หรือไม่ จากนั้นตรวจ submission ได้แก่ การแก้ DNS การเชื่อมต่อ TCP การเจรจา TLS การตรวจสอบใบรับรอง การยืนยันตัวตน การอนุญาตผู้ส่งใน envelope การตอบกลับต่อผู้รับ และการตอบกลับ DATA สุดท้าย หากบริการ submission ยอมรับข้อความแล้ว ให้หยุดส่งคำขอซ้ำแบบสุ่มสี่สุ่มห้า และติดตามตัวระบุข้อความและสตรีมอีเวนต์ของบริการนั้น แยกสถานะที่ผู้ให้บริการประมวลผลออกจากการยอมรับโดยเซิร์ฟเวอร์ผู้รับ อีเมลตีกลับภายหลังยังรายงานความล้มเหลวถาวรได้หลังการยอมรับครั้งแรก หากเซิร์ฟเวอร์ผู้รับยอมรับข้อความแล้ว ให้ตรวจสอบผลการยืนยันตัวตน ชื่อเสียง นโยบายผู้รับ เนื้อหา และการจัดประเภทกล่องจดหมาย แทนการเรียกว่าความล้มเหลวของการขนส่ง SMTP ตรวจทั้งตัวตนใน envelope และเฮดเดอร์ และเก็บ timestamp รหัสตอบกลับ จำนวนความพยายามในคิว และตัวระบุของผู้ให้บริการ ใช้ผู้รับที่ควบคุมได้สำหรับการทดสอบ ห้ามวางข้อมูลรับรอง SMTP ในระบบจริงหรือข้อความลูกค้าทั้งฉบับลงในตั๋ว พรอมต์ ประวัติเทอร์มินัล หรือเครื่องมือวินิจฉัยสาธารณะ

แยกการยอมรับ การส่งถึง และการเข้ากล่องจดหมาย

ความแม่นยำของโปรโตคอลสำคัญในอินเทอร์เฟซผลิตภัณฑ์ การยอมรับโดยแอปพลิเคชันหมายถึงระบบภายในบันทึกคำขอ การยอมรับ submission หมายถึงบริการอีเมลแรกรับผิดชอบในการประมวลผล การส่งถึงเซิร์ฟเวอร์ผู้รับหมายถึงเซิร์ฟเวอร์ SMTP ปลายทางตอบสำเร็จสำหรับการส่งต่อ การเข้ากล่องจดหมายเป็นการตัดสินใจด้านนโยบายและการจัดประเภทที่ตามมาภายในสภาพแวดล้อมของผู้รับ ข้อความอาจผ่านสถานะหนึ่งและล้มเหลวหรือถูกจัดประเภทต่างกันในสถานะถัดไป SMTP ให้หลักฐานโดยตรงเกี่ยวกับธุรกรรมปัจจุบันและอาจสร้าง delivery-status notification ภายหลัง แต่ไม่เปิดเผยโฟลเดอร์สุดท้ายของผู้รับ เก็บสถานะเหล่านี้แยกอิสระ แทนการติดป้ายทุกการตอบกลับ 250 ว่าเป็นการส่งเข้ากล่องจดหมาย อีเวนต์ของผู้ให้บริการที่รวมการตอบกลับสำเร็จของ SMTP ปลายทางรองรับสถานะส่งถึงเซิร์ฟเวอร์ได้ อีเมลตีกลับรองรับการจัดการความล้มเหลวหรือการระงับการส่ง ทั้งสองอย่างไม่รองรับคำสัญญาเรื่องการมองเห็น การอ่าน หรือการมีส่วนร่วม โมเดลนี้ทำให้สถานะเป็นจริงและป้องกันการลองใหม่ที่ไม่ปลอดภัยหลังโอนความรับผิดชอบแล้ว

ใช้ API ที่ SendHQ จัดทำเอกสารไว้

แอปพลิเคชันสื่อสาร SMTP ผ่าน library ของผู้ให้บริการได้ หรือเรียก HTTP Email API ที่ผู้ให้บริการจัดการการขนส่งอีเมลอินเทอร์เน็ตภายใต้อินเทอร์เฟซนั้น SendHQ มี Email API ระดับเวิร์กสเปซพร้อมการตรวจสอบโดเมนที่ยืนยันแล้ว resource ข้อความขาออกและขาเข้า อีเวนต์ การระงับการส่ง กล่องจดหมาย และขอบเขต resource ของเวิร์กสเปซ HTTP API ของ SendHQ ให้ request ที่มีโครงสร้าง ตัวระบุ และอีเวนต์ควบคู่กับการส่ง SMTP โดยตรงได้ ไม่ได้เปลี่ยนพฤติกรรมเซิร์ฟเวอร์ปลายทาง หรือสร้างการยอมรับ SMTP การเข้ากล่องจดหมาย หรือ engagement ของผู้รับ

คำถามที่พบบ่อย

SMTP ย่อมาจากอะไร

SMTP ย่อมาจาก Simple Mail Transfer Protocol กำหนดวิธีที่ไคลเอนต์และเซิร์ฟเวอร์อีเมลส่งและถ่ายโอนข้อความขาออกผ่านคำสั่ง การตอบกลับ envelope ข้อมูลข้อความ และส่วนขยายสำหรับความสามารถ เช่น การยืนยันตัวตนและ TLS

SMTP ใช้อ่านอีเมลจากกล่องจดหมายหรือไม่

ไม่ SMTP ใช้หลัก ๆ สำหรับส่งและถ่ายโอนอีเมลขาออก การเข้าถึงกล่องจดหมายใช้อินเทอร์เฟซอื่น เช่น IMAP, POP, API กล่องจดหมายเฉพาะของผู้ให้บริการ หรือ Email API ของแอปพลิเคชันที่เปิดเผยข้อความขาเข้าที่จัดเก็บไว้

พอร์ต 25, 587 และ 465 ต่างกันอย่างไร

พอร์ต 25 ตามธรรมเนียมใช้สำหรับการรีเลย์ระหว่างเซิร์ฟเวอร์ พอร์ต 587 คือบริการส่งข้อความ (message submission) มาตรฐานและมักเจรจา TLS ส่วนพอร์ต 465 ลงทะเบียนไว้สำหรับการส่งผ่าน implicit TLS ให้ทำตาม endpoint และโหมดความปลอดภัยที่ผู้ให้บริการระบุ แทนการสลับพอร์ตแบบทดลอง

SMTP สำเร็จพิสูจน์ได้หรือไม่ว่าอีเมลเข้ากล่องจดหมาย

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

แอปพลิเคชันควรลองใหม่ทุกการตอบกลับ SMTP แบบ 4xx หรือไม่

รหัส 4xx บ่งชี้ผลเชิงลบแบบชั่วคราว แต่การลองใหม่ควรใช้คิวที่คงทน exponential backoff พร้อม jitter อายุที่จำกัด และขีดจำกัดความพยายามที่คำนึงถึงผู้รับ ตรวจสอบความล้มเหลวชั่วคราวที่เกิดซ้ำ แทนการลองใหม่ไม่รู้จบ

HTTP Email API แทนที่ SMTP ได้หรือไม่

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

แหล่งอ้างอิง

เรียนรู้ต่อ

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