คำศัพท์ · พอร์ต smtp

แอปพลิเคชันควรใช้พอร์ต SMTP ใดสำหรับอีเมล

แอปพลิเคชันส่วนใหญ่ควรใช้ endpoint และ port สำหรับการส่งที่ผู้ให้บริการอีเมลจัดทำเอกสารไว้ Port 587 คือ port มาตรฐานสำหรับส่งข้อความ และมักเริ่มด้วย SMTP แบบ plain ก่อนอัปเกรด STARTTLS Port 465 คือการส่งข้อความด้วย TLS แบบ implicit ดังนั้น TLS handshake จึงเริ่มทันที Port 25 ใช้หลัก ๆ สำหรับ SMTP relay ระหว่างเซิร์ฟเวอร์ ไม่ใช่การส่งจากแอปพลิเคชันที่ยืนยันตัวตนตามปกติ การกำหนดค่าที่ทำงานได้ต้องให้สี่สิ่งตรงกัน ได้แก่ hostname, port, โหมด TLS และวิธีการยืนยันตัวตน

พอร์ต SMTP กำหนดบทบาทของโปรโตคอลและโหมดการเชื่อมต่อ

หมายเลขพอร์ตไม่ใช่เพียงประตูที่สลับกันได้เข้าสู่บริการเดียวกัน แต่ช่วยระบุว่าเซิร์ฟเวอร์เสนอบทบาท SMTP ใด และการเชื่อมต่อเริ่มต้นอย่างไร การส่งข้อความ (submission) คือการส่งต่อครั้งแรกจากแอปพลิเคชันหรือ user agent ไปยังบริการรับส่ง ส่วน relay คือการถ่ายโอนเมลระหว่างเมลเซิร์ฟเวอร์ มาตรฐานแยกสองงานนี้ออกจากกัน เพราะ submission อาจต้องมีการยืนยันตัวตน การอนุญาตผู้ส่ง และการตรวจสอบนโยบายข้อความ ซึ่งไม่ได้ใช้แบบเดียวกันกับรีเลย์เมลสาธารณะ พอร์ตยังบ่งบอกได้ว่าไคลเอนต์เริ่มด้วยคำสั่ง SMTP แล้วอัปเกรดด้วย STARTTLS ภายหลัง หรือเริ่มด้วย TLS handshake ทันที ให้ถือว่าชื่อโฮสต์ พอร์ต โหมด TLS และคำแนะนำการยืนยันตัวตนของผู้ให้บริการเป็นชุดการตั้งค่าเดียวกัน การคัดลอกพอร์ตจากผู้ให้บริการที่ไม่เกี่ยวข้อง หรือเปลี่ยนเฉพาะพอร์ตหลังเกิดข้อผิดพลาด อาจเปลี่ยนปัญหาเครือข่ายให้เป็นความล้มเหลวของ TLS หรือการยืนยันตัวตนโดยไม่แก้สาเหตุเดิม

พอร์ต 25 ใช้สำหรับรีเลย์ของเมลเซิร์ฟเวอร์เป็นหลัก

พอร์ต 25 เป็นพอร์ตรีเลย์ SMTP ตามธรรมเนียมที่ใช้เมื่อ Message Transfer Agent ตัวหนึ่งส่งต่อเมลให้อีกตัวหนึ่ง RFC 6409 คงรีเลย์ไว้ที่พอร์ต 25 ขณะแยกการส่งข้อความใหม่ไปที่พอร์ต 587 ดังนั้นแอปพลิเคชันจึงไม่ควรสมมติว่าการเชื่อมต่อตรงไปยังเมลเซิร์ฟเวอร์ของผู้รับที่พอร์ต 25 เป็นวิธีปกติในการส่งอีเมลของผลิตภัณฑ์ การรีเลย์โดยตรงต้องมีการเข้าคิว การกำหนดเส้นทางผ่าน DNS การจัดการอีเมลตีกลับ การควบคุมการละเมิด การจัดการชื่อเสียง และพฤติกรรมการลองใหม่ที่เป็นไปตามมาตรฐาน เครือข่ายและผู้ให้บริการโฮสติ้งอาจจำกัดพอร์ต 25 ขาออกด้วย ตัวอย่างเช่น AWS ระบุว่ามีการ throttle ทราฟฟิกอีเมลของ Amazon EC2 บนพอร์ต 25 โดยค่าเริ่มต้น พอร์ต 25 ยังอาจเป็นตัวเลือกที่มีเอกสารรองรับที่ผู้ให้บริการหรือในโครงสร้างพื้นฐานที่ควบคุมได้ แต่การใช้งานได้ไม่ได้ทำให้เป็นตัวเลือกที่แนะนำสำหรับ submission ใช้เฉพาะเมื่อบริการที่รับผิดชอบระบุ endpoint โหมดความปลอดภัย และโมเดลการปฏิบัติงานไว้อย่างชัดเจน

พอร์ต 587 เป็นพอร์ตส่งข้อความมาตรฐาน

RFC 6409 สงวนพอร์ต 587 สำหรับการส่งข้อความ และอธิบายบริการ submission ที่ปฏิเสธเมลที่ไม่ได้รับอนุญาต กำหนดให้ยืนยันตัวตน และบังคับใช้นโยบายก่อนรับข้อความใหม่ได้ เซสชันพอร์ต 587 ทั่วไปเริ่มเป็น SMTP ประกาศส่วนขยาย STARTTLS หลัง `EHLO` อัปเกรดการเชื่อมต่อเป็น TLS ทำ `EHLO` ซ้ำ ยืนยันตัวตน แล้วจึงส่งข้อความ คำว่าทั่วไปมีความสำคัญ เพราะกลไกการยืนยันตัวตนและข้อกำหนดที่แน่นอนมาจากเอกสารปัจจุบันของผู้ให้บริการและความสามารถของเซิร์ฟเวอร์ ไคลเอนต์ที่ปลอดภัยควรกำหนดให้ต้องอัปเกรด TLS ตามที่คาดไว้และตรวจสอบใบรับรองเซิร์ฟเวอร์ แทนการดำเนินต่อแบบ cleartext เมื่อการเจรจาล้มเหลว อย่าสับสนระหว่างการทักทายโปรโตคอลแบบไม่เข้ารหัสในตอนแรกกับเซสชันที่ยืนยันตัวตนแล้วซึ่งไม่ได้รับการปกป้อง STARTTLS ออกแบบมาเพื่ออัปเกรดการเชื่อมต่อนั้นก่อนส่งข้อมูลรับรองและข้อมูลข้อความ พอร์ต 587 ระบุบริการ submission ส่วนการบังคับใช้ TLS ให้สำเร็จขึ้นกับนโยบายไคลเอนต์ที่ถูกต้อง

พอร์ต 465 ใช้ implicit TLS สำหรับ submission

พอร์ต 465 ลงทะเบียนไว้สำหรับการส่งข้อความผ่าน implicit TLS ด้วย implicit TLS ไคลเอนต์ทำ TLS handshake ทันทีที่การเชื่อมต่อ TCP เปิด และส่งคำสั่ง SMTP เฉพาะภายในช่องทางที่ได้รับการปกป้อง ซึ่งต่างจากพอร์ต 587 กับ STARTTLS ที่ไคลเอนต์ได้รับการทักทาย SMTP ก่อนแล้วจึงขออัปเกรด RFC 8314 แนะนำ implicit TLS สำหรับ submission และอธิบายช่วงเปลี่ยนผ่านที่ผู้ให้บริการและไคลเอนต์รองรับได้ทั้งพอร์ต 465 กับ implicit TLS และพอร์ต 587 กับ STARTTLS RFC ระบุว่าไคลเอนต์และเซิร์ฟเวอร์ที่พัฒนาอย่างถูกต้องให้ความปลอดภัยเทียบเท่ากันอย่างมีนัยสำคัญได้ทั้งสองโหมดเมื่อ TLS เป็นข้อบังคับ หลักปฏิบัติจึงไม่ใช่การประกาศว่าพอร์ตใดถูกต้องสำหรับทุกกรณี ให้ใช้ endpoint และโหมดที่ผู้ให้บริการรองรับอย่างตรงตัว การตั้งค่า STARTTLS กับ listener แบบ implicit TLS หรือ implicit TLS กับ listener แบบ STARTTLS มักล้มเหลวก่อนการยืนยันตัวตน

พอร์ตสำรองเฉพาะผู้ให้บริการเป็นสัญญาที่ระบุชัดเจน

ผู้ให้บริการบางรายมีพอร์ตสำรองเพื่อหลีกเลี่ยงข้อจำกัดของเครือข่าย แต่หมายเลขเหล่านั้นไม่ใช่มาตรฐาน SMTP สากลสำหรับทุกบริการ ปัจจุบัน Amazon SES ระบุ STARTTLS บนพอร์ต 25, 587 และ 2587 และ TLS Wrapper ซึ่งเป็นคำของ SES สำหรับ implicit TLS บนพอร์ต 465 และ 2465 SES กำหนดให้ใช้การเชื่อมต่อที่เข้ารหัสและเผยแพร่ SMTP endpoint เฉพาะ region ซึ่งแสดงว่าทำไมต้องนำพอร์ตจากเอกสารของผู้ให้บริการที่เลือก ไม่ใช่รายการทั่วไป พอร์ต 2587 ไม่ได้หมายถึง STARTTLS ในทุกที่ และพอร์ต 2465 ไม่ได้ระบุบริการ implicit TLS บนโฮสต์ใดก็ได้ พอร์ตสำรองก็ไม่ได้ข้ามการยืนยันผู้ส่ง ขอบเขตข้อมูลรับรอง โควตา หรือนโยบายของผู้ให้บริการ ให้บันทึก URL แหล่งที่มาและวันที่ยืนยันไว้กับการตั้งค่าระบบจริง เพื่อให้ผู้ปฏิบัติงานแยกออกว่าเป็นการตั้งค่าของผู้ให้บริการที่ตั้งใจ หรือตัวเลขลึกลับที่ไม่มีคำอธิบายซึ่งคัดลอกไปใส่ตัวแปรสภาพแวดล้อมเมื่อหลายปีก่อน

ตั้งค่าชื่อโฮสต์ พอร์ต TLS และการยืนยันตัวตนไปพร้อมกัน

การตั้งค่า SMTP ที่แข็งแกร่งคือชุดที่ประกอบด้วย ชื่อโฮสต์ของผู้ให้บริการ พอร์ต โหมดความปลอดภัยของ transport นโยบายการตรวจสอบใบรับรอง กลไกการยืนยันตัวตน ชื่อผู้ใช้ ความลับ timeout ของการเชื่อมต่อ และตัวตนผู้ส่ง ชื่อโฮสต์สำคัญเพราะใบรับรอง TLS ถูกตรวจสอบกับชื่อนั้น และผู้ให้บริการอาจมี endpoint ตาม region ที่ต่างกัน พอร์ตและโหมด TLS ต้องสอดคล้องกัน การยืนยันตัวตนควรเกิดขึ้นหลังจากมีช่องทางที่ป้องกันตามที่ตั้งใจแล้วเท่านั้น และความลับควรอยู่ใน secret manager ไม่ใช่ซอร์สโค้ด bundle ของเบราว์เซอร์ บันทึก หรือเอาต์พุตวินิจฉัย แยกข้อมูลรับรองและการตั้งค่าตามสภาพแวดล้อม เพื่อไม่ให้การทดสอบในเครื่องส่งผ่านระบบจริงโดยไม่ตั้งใจ ตั้ง timeout ของการเชื่อมต่อและคำสั่งแบบจำกัด แต่ให้คิวของแอปพลิเคชันที่คงทนควบคุมการลองใหม่ของข้อความ ตัวเลือกชื่อ `secure` อาจหมายถึง implicit TLS ใน SDK หนึ่ง และเพียงกำหนดให้ต้องใช้ STARTTLS ในอีก SDK หนึ่ง จึงควรตรวจสอบนิยามของไลบรารีและทดสอบพฤติกรรมที่เจรจาได้จริง แทนการพึ่งพาชื่อตัวเลือก

ทดสอบการเชื่อมต่อเป็นชั้น ๆ โดยไม่เปิดเผยความลับ

เริ่มจากการ resolve DNS และการเข้าถึง TCP จากเครือข่ายรันไทม์เดียวกับแอปพลิเคชัน การหมดเวลาก่อนเชื่อมต่อชี้ไปที่การกำหนดเส้นทาง ไฟร์วอลล์ นโยบาย egress ของผู้ให้บริการ ชื่อโฮสต์ที่ผิด หรือพอร์ตที่ปิดอยู่ จากนั้นทดสอบโหมด TLS ที่คาดไว้ สำหรับ implicit TLS ไคลเอนต์ TLS ควรได้รับใบรับรองแล้วจึงได้รับการทักทาย SMTP สำหรับ STARTTLS ไคลเอนต์ที่เข้าใจ SMTP ควรได้รับการทักทาย ส่ง `EHLO` เห็น STARTTLS ที่ประกาศ ขออัปเกรด ตรวจสอบใบรับรอง และส่ง `EHLO` อีกครั้งหลัง TLS RFC 3207 กำหนดให้ไคลเอนต์และเซิร์ฟเวอร์ละทิ้งความรู้ที่ได้รับก่อน handshake ซึ่งเป็นเหตุผลที่ `EHLO` ครั้งที่สองสำคัญ แล้วจึงทดสอบการยืนยันตัวตนด้วยบัญชีที่ควบคุมได้ ปกปิดชื่อผู้ใช้ โทเค็น ที่อยู่ผู้รับ บันทึกการสนทนาของเซิร์ฟเวอร์ทั้งหมด และเนื้อหาข้อความก่อนแชร์บันทึก การตรวจสอบการเชื่อมต่อไม่จำเป็นต้องส่งในระบบจริงหรือใช้ที่อยู่ลูกค้าจริง

จัดประเภทความล้มเหลวตามขั้นตอนที่ล้มเหลวจริง

connection refused หมายถึงปลายทาง TCP ปฏิเสธการเชื่อมต่ออย่างชัดเจน ส่วน timeout หมายถึงไม่มีการตอบกลับที่ใช้ได้ภายในขีดจำกัด ข้อผิดพลาด TLS handshake ชี้ไปที่โหมดไม่ตรงกัน ปัญหาใบรับรอง โปรโตคอลเข้ากันไม่ได้ การดักฟัง หรือ endpoint ผิด ข้อผิดพลาดการยืนยันตัวตนเกิดในขั้นหลังและควรสืบสวนเป็นการตั้งค่าข้อมูลรับรอง กลไก บัญชี หรือการอนุญาต ไม่ใช่แก้ด้วยการเปลี่ยนพอร์ตแบบสุ่ม รหัสตอบกลับ SMTP ระหว่าง `MAIL FROM`, `RCPT TO` หรือ `DATA` อธิบายการตัดสินใจด้านนโยบายและข้อความในขั้นถัดไป ให้เก็บขั้นตอน เวลา endpoint จำนวนครั้งที่พยายาม รหัสตอบกลับตัวเลข และการตอบกลับที่กรองข้อมูลส่วนบุคคลแล้ว การตอบกลับ SMTP 4xx โดยปกติเป็นชั่วคราว และ 5xx โดยปกติเป็นถาวรสำหรับคำสั่งที่พยายาม แต่การลองใหม่ต้องมีขอบเขตและคำนึงถึงผู้รับ หากผู้ให้บริการยอมรับข้อมูลข้อความแล้ว อย่าส่งซ้ำแบบไม่ดูสถานการณ์เพียงเพราะคำขอของแอปพลิเคชันภายหลังหมดเวลา ให้กระทบยอดด้วยตัวระบุของผู้ให้บริการและประวัติอีเวนต์

พอร์ตทำงานสำเร็จไม่เท่ากับการส่งถึงหรือการเข้ากล่องจดหมาย

การเชื่อมต่อ TCP ที่สำเร็จพิสูจน์เพียงว่ามี listener ตอบกลับ TLS handshake ที่สำเร็จพิสูจน์ว่ามีการเชื่อมต่อที่ป้องกันไปยัง endpoint ที่ผ่านการยืนยันตัวตนเมื่อการตรวจสอบใบรับรองสำเร็จ การยืนยันตัวตนพิสูจน์ว่าเซิร์ฟเวอร์ยอมรับตัวตนไคลเอนต์ที่แสดงสำหรับเซสชันนั้น การตอบกลับ SMTP `250` หลังข้อมูลข้อความหมายความว่าเซิร์ฟเวอร์ที่ตอบกลับยอมรับความรับผิดชอบตามโปรโตคอล ไม่ใช่ว่ามีคนได้รับหรืออ่านข้อความ การรีเลย์ภายหลังยังอาจล้มเหลว และระบบปลายทางอาจยอมรับเมลแต่จัดหมวดหมู่ไว้นอกกล่องจดหมายหลัก ให้แยกสถานะเหล่านี้ออกจากกันในเรคคอร์ดของแอปพลิเคชันและการเฝ้าติดตาม ความพร้อมของเครือข่าย การเจรจา TLS การยืนยันตัวตน การยอมรับของผู้ให้บริการ การยอมรับของเซิร์ฟเวอร์ปลายทาง อีเมลตีกลับ การร้องเรียน และการมีส่วนร่วม เป็นการสังเกตที่ต่างกัน การแยกนี้ป้องกันไม่ให้รายงานการตรวจสอบพอร์ตเป็นการทดสอบการส่งถึงผิด ๆ และป้องกันไม่ให้ลองส่งข้อความที่ยอมรับแล้วซ้ำเพียงเพราะพิสูจน์การเข้ากล่องจดหมายไม่ได้

เลือก SMTP submission หรือ email API อย่างตั้งใจ

ใช้การส่ง SMTP เมื่อระบบมีไคลเอ็นต์ SMTP ที่สมบูรณ์อยู่แล้ว เมื่อแพลตฟอร์มที่จำเป็นเปิดเผย SMTP เป็นการเชื่อมต่อที่รองรับ หรือเมื่อต้องการการควบคุมระดับ protocol โดยเฉพาะ HTTPS Email API อาจเป็นขอบเขตแอปพลิเคชันที่ดีกว่าเมื่อ request ที่มีโครงสร้าง โทเค็นที่จำกัดขอบเขต idempotency resource แบบ batch และบันทึกอีเวนต์ที่เครื่องอ่านได้เหมาะกับงาน ผู้ให้บริการยังใช้ SMTP ปลายทางเพื่อไปถึงระบบอีเมลของผู้รับได้ ดังนั้น API ไม่ได้ยกเลิกการขนส่งอีเมล แต่ย้ายความรับผิดชอบเรื่อง port, TLS การยืนยันตัวตน และการลองใหม่สำหรับ handoff ที่หันสู่ผู้ให้บริการ ออกจากการกำหนดค่า SMTP ของแอปพลิเคชัน

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

แอปพลิเคชันของฉันควรใช้ SMTP พอร์ต 587 หรือ 465

ใช้พอร์ตและโหมด TLS ที่ผู้ให้บริการระบุไว้ พอร์ต 587 โดยปกติใช้ STARTTLS ส่วนพอร์ต 465 ใช้ implicit TLS ทั้งสองแบบปกป้อง submission ได้เมื่อพัฒนาอย่างถูกต้องและบังคับใช้ การตั้งค่าไคลเอนต์ต้องตรงกับ listener ของเซิร์ฟเวอร์

ทำไมพอร์ต SMTP 25 จึงถูกบล็อกหรือหมดเวลา

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

สลับจากพอร์ต 587 เป็น 465 ได้โดยไม่เปลี่ยนอย่างอื่นหรือไม่

โดยปกติไม่ได้ พอร์ต 587 มักเริ่มด้วย SMTP แล้วอัปเกรดผ่าน STARTTLS ส่วนพอร์ต 465 เริ่มด้วย TLS handshake ทันที ให้เปลี่ยนพอร์ตและโหมด TLS ของไคลเอนต์พร้อมกัน ตามเอกสารของผู้ให้บริการและไลบรารี

พอร์ต 587 เข้ารหัสโดยค่าเริ่มต้นหรือไม่

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

SMTP connection refused หมายความว่าอะไร

หมายความว่าปลายทาง TCP ปฏิเสธการเชื่อมต่อก่อนการเจรจา SMTP สาเหตุที่พบบ่อยได้แก่ โฮสต์หรือพอร์ตผิด บริการไม่ได้ listen ไฟร์วอลล์ปฏิเสธ หรือ endpoint ของผู้ให้บริการเข้าถึงจากเครือข่ายนั้นไม่ได้

การทดสอบพอร์ต SMTP ที่สำเร็จพิสูจน์การส่งถึงหรือไม่

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