การตรวจสอบสิทธิ์ SMTP
การตรวจสอบสิทธิ์ SMTPซึ่งมักย่อว่าSMTP AUTHเป็นส่วนขยายของSimple Mail Transfer Protocol (SMTP) โดยที่ไคลเอ็นต์สามารถเข้าสู่ระบบโดยใช้กลไกการตรวจสอบสิทธิ์ใด ๆ ที่เซิร์ฟเวอร์รองรับ ส่วนใหญ่จะใช้โดย เซิร์ฟเวอร์ ส่งข้อมูลซึ่งการตรวจสอบสิทธิ์เป็นสิ่งจำเป็น[ 1 ]
ประวัติศาสตร์
SMTP ตามที่ Jon Postelกำหนดไว้ในทศวรรษ 1970 ไม่ได้รองรับการใช้รหัสผ่านสำหรับการส่งข้อความอีเมล เซิร์ฟเวอร์แต่ละตัวได้รับการออกแบบให้เป็นรีเลย์อีเมลแบบเปิด ส่งผลให้สแปมและเวิร์มแม้ว่าในตอนแรกจะไม่ใช่ปัญหา แต่ก็กลายเป็นปัญหาใหญ่ในช่วงปลายทศวรรษ 1990 [ 2 ]ก่อน SMTP AUTH ไคลเอนต์รีเลย์ต้องระบุด้วยที่อยู่ IP ซึ่งทำได้เฉพาะกับบริการอีเมลที่ให้บริการโดย ผู้ให้บริการอินเทอร์เน็ต (ISP) เดียวกันกับที่ให้การเชื่อมต่อ หรือใช้เทคนิคเฉพาะ เช่นPOP ก่อน SMTP
John Gardiner Myers ได้เผยแพร่ร่างแรกของ SMTP AUTH ในปี 1995 [ 3 ]และได้รับการพัฒนาและอภิปรายอย่างต่อเนื่องในIETFพร้อมกับโปรโตคอลการส่งอีเมล Extended SMTP (ESMTP) และSimple Authentication and Security Layer (SASL) กลไก SASL รุ่นเก่าสำหรับการตรวจสอบสิทธิ์ ESMTP (ESMTPA) คือCRAM-MD5และการใช้ อัลกอริธึม MD5ในHMACs (รหัสตรวจสอบความถูกต้องของข้อความแบบแฮช) ยังคงถือว่าถูกต้อง[ 4 ]
สมาคมอินเทอร์เน็ตเมล (IMC) รายงานว่าเซิร์ฟเวอร์อีเมล 55% เป็นรีเลย์แบบเปิดในปี 1998 [ 5 ]แต่น้อยกว่า 1% ในปี 2002 [ 6 ]
บทบาทในระบบขนส่งไปรษณีย์
การใช้เอเจนต์การส่งอีเมล (MSA) ซึ่งโดยทั่วไปอยู่ที่พอร์ต 587 หมายถึงการตรวจสอบสิทธิ์ SMTP การใช้งาน MSA ได้รับการสนับสนุนจากซอฟต์แวร์ส่วนใหญ่[ 7 ]และแนะนำให้ใช้ โดยเฉพาะอย่างยิ่งเพื่อรองรับผู้ใช้ที่เคลื่อนที่ไปมา เนื่องจากฮับเครือข่ายหลายแห่งบล็อกพอร์ต 25 หรือใช้พร็อกซี SMTP MSA มีหน้าที่รับผิดชอบในการตรวจสอบให้แน่ใจว่าซองจดหมายข้อความมีที่อยู่ที่ดี และอาจบังคับใช้นโยบายท้องถิ่นสำหรับFromฟิลด์ส่วนหัว การตรวจสอบว่าผู้ส่งซองจดหมาย (หรือที่รู้จักกันในชื่อReturn-Path) ที่ใช้สำหรับSPFและที่ อยู่ Fromตรงกับรหัสผู้ใช้ที่ ได้รับการตรวจสอบสิทธิ์นั้นมีความสำคัญอย่างยิ่งสำหรับโดเมนที่ลงนามข้อความ โดยใช้DKIM
คำหลักที่ลงท้ายด้วย "A" เช่นESMTPAและESMTPSAจะถูกจัดเตรียมไว้สำหรับwithข้อความของReceivedฟิลด์ส่วนหัว เมื่อได้รับข้อความด้วย SMTP AUTH [ 8 ] "คำหลักเหล่านี้มีไว้สำหรับวัตถุประสงค์ทางสถิติหรือการวินิจฉัย" ( RFC 3848) โดยมีการตรวจสอบโดยไคลเอ็นต์บางตัว เช่นSpamassassin
รายละเอียด
เช่นเดียวกับส่วนขยาย SMTP ทั้งหมด SMTP AUTH จะถูกแจ้งให้ทราบในคำตอบ EHLO พร้อมกับรายการวิธีการตรวจสอบสิทธิ์ที่รองรับ วิธีการเหล่านี้อาจเปลี่ยนแปลงได้หลังจากออกคำสั่ง STARTTLSโดยทั่วไปแล้วจะอนุญาตให้ใช้รหัสผ่านแบบข้อความธรรมดาได้เฉพาะในกรณีหลังเท่านั้น RFC 4954 ให้ตัวอย่างดังต่อไปนี้ ("C:" และ "S:" ไม่ใช่ส่วนหนึ่งของโปรโตคอล แต่แสดงถึงบรรทัดที่ส่งโดยไคลเอ็นต์และเซิร์ฟเวอร์ตามลำดับ):
S: 220 smtp.example.com เซิร์ฟเวอร์ ESMTP C: EHLO client.example.com S: 250-smtp.example.com สวัสดี client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 พร้อมที่จะเริ่มต้น TLS ... การเจรจา TLS ดำเนินต่อไปคำสั่งเพิ่มเติมได้รับการปกป้องโดยเลเยอร์ TLS ... C: EHLO client.example.com S: 250-smtp.example.com สวัสดี client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE= S: 235 2.7.0 การตรวจสอบสิทธิ์สำเร็จ
SMTP AUTH สามารถใช้งานได้บนพอร์ต 25 เช่นกัน โดยปกติแล้ว เซิร์ฟเวอร์จะปฏิเสธคำสั่ง RCPT TO ที่หมายถึงการส่งต่อเว้นแต่จะยอมรับข้อมูลประจำตัวการตรวจสอบสิทธิ์แล้ว ข้อกำหนดแนะนำให้เซิร์ฟเวอร์ออก คำสั่ง 530 5.7.0 Authentication requiredในการตอบสนองต่อคำสั่งส่วนใหญ่ในกรณีที่เซิร์ฟเวอร์ถูกกำหนดค่าให้ต้องมีการตรวจสอบสิทธิ์และไคลเอนต์ยังไม่ได้ดำเนินการ เซิร์ฟเวอร์ที่รับฟังบนพอร์ต 587 หรือเซิร์ฟเวอร์ส่วนตัวเท่านั้นที่ควรได้รับการกำหนดค่าในลักษณะนั้น ไม่ใช่ Message eXchange (MX) อย่างไรก็ตาม คุณลักษณะทางประวัติศาสตร์ที่ว่า SMTP ไม่ได้รับการตรวจสอบสิทธิ์โดยค่าเริ่มต้นส่งผลให้มีพฤติกรรมที่แตกต่างกันเกี่ยวกับโปรโตคอลการเข้าถึงในบางกรณี ตัวอย่างเช่น เมื่อใช้ AUTH EXTERNAL หลังจาก STARTTLS [ 9 ]
นอกจาก คำสั่ง AUTHแล้ว ส่วนขยายนี้ยังเพิ่ม พารามิเตอร์ AUTH ให้ กับ คำสั่ง MAIL FROMเพื่อให้สามารถแยกแยะระหว่างการตรวจสอบสิทธิ์และการอนุญาตได้ ด้วยวิธีนี้ ผู้ส่งสามารถระบุตัวตนและส่งข้อความหลายข้อความในเซสชันเดียวกันได้ แม้ว่าการตรวจสอบสิทธิ์ไม่จำเป็นต้องเปลี่ยนแปลง แต่เมื่อสร้างการตรวจสอบสิทธิ์แล้ว ข้อความต่างๆ อาจถูกส่งตามข้อตกลงที่แตกต่างกัน และดังนั้นจึงต้องการการอนุญาตที่แตกต่างกัน ตัวอย่างเช่น ข้อความอาจถูกส่งต่อในนามของผู้ใช้ที่แตกต่างกัน การใช้พารามิเตอร์นี้ได้รับความนิยมน้อยกว่าการใช้คำสั่งเพื่อให้สิทธิ์การส่งต่อ
การตรวจสอบสิทธิ์ SMTP เป็น "ส่วนขยาย" ในแง่ของ SMTP ดังนั้นจึงต้องใช้เซิร์ฟเวอร์และไคลเอ็นต์ในการใช้คำกริยา EHLO สำหรับการทักทายเพื่อระบุการสนับสนุนส่วนขยาย แทนที่จะใช้การทักทาย HELO ที่ล้าสมัย[ 10 ]เพื่อความเข้ากันได้กับเวอร์ชันก่อนหน้า อาจยอมรับการทักทาย HELO เมื่อไม่ได้ใช้ส่วนขยาย
ข้อความที่เป็นตัวพิมพ์ใหญ่หลัง คำสั่ง AUTHคือรายการประเภทการอนุญาตที่เซิร์ฟเวอร์ SMTP จะยอมรับ
ตัวอย่างของโปรโตคอลการอนุญาต ได้แก่:
- แบบธรรมดา (ใช้การเข้ารหัส Base64)
- LOGIN (ใช้การเข้ารหัส Base64) [ 11 ] (เลิกใช้แล้วและหันมาใช้ PLAIN แทน)
- GSSAPI ( Generic Security Services Application Program Interface )
- DIGEST-MD5 ( การตรวจสอบสิทธิ์การเข้าถึงด้วยค่าแฮช )
- เอ็มดี5
- CRAM-MD5
- OAUTH10A ( โทเค็น OAuth 1.0a HMAC-SHA1 ตามที่กำหนดไว้ใน RFC 5849)
- OAUTHBEARER ( โทเค็น Bearer ของ OAuth 2.0 ตามที่กำหนดไว้ใน RFC 6750)
- XOAUTH2 [ 12 ]
มาตรฐาน
- RFC 3207 , ส่วนขยายบริการ SMTP สำหรับ SMTP ที่ปลอดภัยผ่านการรักษาความปลอดภัยระดับชั้นการขนส่ง , Paul Hoffman, กุมภาพันธ์ 2002
- RFC 3848 , การลงทะเบียนประเภทการส่งข้อมูล ESMTP และ LMTP , คริส นิวแมน, กรกฎาคม 2547
- RFC 6409 , การส่งข้อความสำหรับอีเมล , Randall Gellens และJohn C. Klensin , พฤศจิกายน 2011 (ยกเลิก RFC 4409 จากปี 2006 ซึ่งแทนที่ RFC 2476 จากเดือนธันวาคม 1998)
- RFC 4422 , Simple Authentication and Security Layer (SASL) , Alexey Melnikov และ Kurt D. Zeilenga, มิถุนายน 2549
- RFC 4616กลไกPLAIN SASL บรรณาธิการโดย K. Zeilenga สิงหาคม 2549
- RFC 4954 , ส่วนขยายบริการ SMTP สำหรับการตรวจสอบสิทธิ์ , Robert Siemborski และ Alexey Melnikov, กรกฎาคม 2550
- RFC 7628 , ชุดกลไกการตรวจสอบสิทธิ์และการรักษาความปลอดภัยแบบง่าย (SASL) สำหรับ OAuth , W. Mills, T. Showalter และ H. Tschofenig, สิงหาคม 2015
อื่น
- เออร์วิน ฮอฟฟ์มันน์, การตรวจสอบสิทธิ์ SMTP [บทช่วยสอน] , แก้ไขล่าสุด 10 มกราคม 2017