ค้นหาเว็บไซต์

สถาปัตยกรรม Exchange และการตั้งค่า TLS เชิงฉวยโอกาสเริ่มต้น | ตอนที่ 3#12

ในบทความต่อไปนี้ เราจะตรวจสอบรายละเอียดเพิ่มเติมว่าการใช้งาน TLS ที่ฉวยโอกาส บนสภาพแวดล้อมที่ใช้ Exchange on-Premises และในสภาพแวดล้อมที่ใช้ Exchange Online

ตามที่กล่าวไว้ ในสภาพแวดล้อมแบบ Exchange ตัวเชื่อมต่ออีเมล Exchange ได้รับการกำหนดค่าโดยอัตโนมัติให้ใช้ตัวเลือกของ TLS ที่ฉวยโอกาส .

การกำหนดค่าของ TLS ที่ฉวยโอกาส ได้รับการกำหนดค่าโดยอัตโนมัติในตัวเชื่อมต่อเมลขาเข้าเริ่มต้นและในค่าเริ่มต้นขาออก ตัวเชื่อมต่อเมล

โครงสร้างพื้นฐาน Exchange ภายในองค์กร | การตั้งค่า TLS ที่ฉวยโอกาส

ในส่วนต่อไปนี้ เราจะตรวจสอบการตั้งค่าเริ่มต้นของ TLS ที่ฉวยโอกาสในเซิร์ฟเวอร์ Exchange on-Premises สิ่งแวดล้อม.

การตั้งค่า TLS ที่ฉวยโอกาส ได้รับการกำหนดค่าโดยอัตโนมัติใน ส่งตัวเชื่อมต่อ และ รับตัวเชื่อมต่อ .

หมายเหตุ: ในส่วนปัจจุบัน เราจะสาธิตการตั้งค่า TLS เชิงฉวยโอกาสใน Exchange 2010 on-Premises แต่แนวคิดและการตั้งค่า เกือบจะเหมือนกับ Exchange 2013 on-Premises

แลกเปลี่ยนในสถานที่ | ส่งตัวเชื่อมต่อ | การตั้งค่า TLS ที่ฉวยโอกาส

ใน Exchange 2010 และ Exchange 2013 ข้อมูลเกี่ยวกับการตั้งค่าเริ่มต้นของ TLS ที่ฉวยโอกาส ที่ใช้ โดย ส่งตัวเชื่อมต่อ สามารถแสดงได้โดยใช้ PowerShell เท่านั้น

เพื่อให้สามารถรับข้อมูลเกี่ยวกับการตั้งค่า ส่งตัวเชื่อมต่อ เราสามารถใช้คำสั่ง PowerShell ต่อไปนี้:

Get-SendConnector -Identity "<name of the send connector>" |FL

พารามิเตอร์ที่เกี่ยวข้องกับการตั้งค่าของ TLS ที่ฉวยโอกาส ซึ่งอธิบายว่า IgnoreSTARTTLS

ในภาพหน้าจอต่อไปนี้ เราพบว่าค่าของ IgnoreSTARTTLS เป็นเท็จ

ความหมายก็คือ ตามค่าเริ่มต้น ตัวเชื่อมต่อการส่ง ของ Exchange on-Premises จะสนับสนุนตัวเลือกของ TLS ที่ฉวยโอกาส

ปิดการใช้งานตัวเลือกของ TLS ที่ฉวยโอกาส

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

Set-SendConnector -Identity "<name>" -IgnoreSTARTTLS $true

แลกเปลี่ยนในสถานที่ | รับตัวเชื่อมต่อ | การตั้งค่า TLS ที่ฉวยโอกาส

ในเวอร์ชันเซิร์ฟเวอร์ Exchange 2010 และ Exchange 2013 ข้อมูลบางส่วนเกี่ยวกับการตั้งค่าเริ่มต้นของ Receive Connector ที่อ้างถึงตัวเลือกของ TLS ที่ฉวยโอกาส สามารถแสดงในอินเทอร์เฟซแบบกราฟิกและบางส่วน ข้อมูลสามารถแสดงได้โดยใช้ PowerShell เท่านั้น

การดูการตั้งค่าตัวเชื่อมต่อการรับ Exchange on-Premises โดยใช้ PowerShell

เพื่อให้สามารถรับข้อมูลเกี่ยวกับการตั้งค่า รับตัวเชื่อมต่อ เราสามารถใช้คำสั่ง PowerShell ต่อไปนี้:

Get-ReceiveConnector -Identity "<name of the receive connector>" |FL

ข้อมูลเกี่ยวกับ “การตั้งค่า TLS ” ของ ตัวเชื่อมต่อการรับ จะปรากฏใต้ส่วนชื่อ - AuthMechanism

พารามิเตอร์ AuthMechanism สามารถมีค่าได้หลายค่า ซึ่งหมายความว่า ตัวเชื่อมต่อการรับ ของ Exchange สามารถรองรับโปรโตคอลการตรวจสอบสิทธิ์ได้หลายประเภท

ในภาพหน้าจอต่อไปนี้ เราจะเห็นตัวอย่างการตั้งค่าของเซิร์ฟเวอร์ Exchange on-Premises มาตรฐาน ตัวเชื่อมต่อการรับ

เราจะเห็นว่าค่าของ AuthMechanism มีโปรโตคอลการตรวจสอบความถูกต้องหลายประเภท

การตั้งค่า AuthMechanism

เราจะเห็นว่า Exchange ตัวเชื่อมต่อการรับ รองรับโปรโตคอลการตรวจสอบสิทธิ์ประเภทต่างๆ

เกี่ยวกับเรื่องของ TLS เราจะเห็นพารามิเตอร์ที่เกี่ยวข้องสองตัว

1. กรุณา

นี่คือพารามิเตอร์ที่ “เปิดใช้งาน ” ตัวเลือกของ TLS ที่ฉวยโอกาส

ความหมายก็คือ ในสถานการณ์ที่เซิร์ฟเวอร์อีเมลอื่นพยายามสื่อสารกับเซิร์ฟเวอร์ Exchange เซิร์ฟเวอร์ Exchange จะเสนอให้ใช้ TLS
หาก “เซิร์ฟเวอร์อีเมลอื่น ” ไม่ รองรับ TLS โดยเซิร์ฟเวอร์ Exchange จะ "ตกลง" ให้ใช้โปรโตคอล SMTP แทน

หมายเหตุ: ความคิดเห็นของฉันคือคำจำกัดความของ TLS ที่ฉวยโอกาสภายใต้ส่วนของ AuthMechanism นั้นคลาดเคลื่อนเล็กน้อย เนื่องจากในทางเทคนิคแล้ว โปรโตคอล TLS ไม่ได้กำหนดความจำเป็นในการตรวจสอบสิทธิ์ที่จำเป็น

<แข็งแกร่ง>2. BasicAuthRequireTLS

ตัวเลือกนี้มีความเกี่ยวข้อง โดยหลักแล้วสำหรับสถานการณ์ที่โปรแกรมรับส่งเมล (เช่น โปรแกรมรับส่งเมล POP3 หรือ IMAP4) ระบุที่อยู่ Exchange ภายในองค์กร โดยขอ "เรียกข้อมูล" รายการเมล

ในกรณีนี้ เมลไคลเอ็นต์จะต้องระบุโดยระบุข้อมูลรับรองผู้ใช้

เมลไคลเอ็นต์ส่วนใหญ่จะ "ส่งมอบ" ข้อมูลรับรองผู้ใช้โดยใช้การรับรองความถูกต้องพื้นฐาน (BasicAuth) ซึ่งข้อมูลรับรองผู้ใช้จะไม่ถูกเข้ารหัส

ตัวเลือกของ - BasicAuthRequireTLS สั่งให้ไคลเอ็นต์เมลส่งข้อมูลประจำตัวผู้ใช้ผ่านช่องทางการสื่อสารที่ปลอดภัย (TLS) และไม่ใช้ช่องทางการสื่อสารมาตรฐาน (ช่องทางการสื่อสารที่ไม่ได้เข้ารหัส)

<แข็งแกร่ง>3. ต้องใช้ TLS

พารามิเตอร์ที่สองใน Exchange on-Premises ตัวเชื่อมต่อการรับ มีพารามิเตอร์เพิ่มเติมที่เกี่ยวข้องกับการกำหนดค่าของชื่อ Force TLS - ต้องใช้ TLS

เราจะพูดถึงตัวเลือกนี้โดยย่อในบทความ

การดูการตั้งค่าตัวเชื่อมต่อรับ Exchange on-Premises โดยใช้อินเทอร์เฟซ Exchange Graphic

เมื่อเราใช้อินเทอร์เฟซ Exchange Graphic สำหรับการดูการตั้งค่าที่เกี่ยวข้องกับตัวเลือกของ TLS ที่ฉวยโอกาส สิ่งสำคัญคือต้องเน้นย้ำว่ามีเพียงพารามิเตอร์เดียวเท่านั้นที่เกี่ยวข้องโดยตรงกับ TLS ที่ฉวยโอกาส

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าเราสามารถเลือกตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้:

1. ความปลอดภัยของเลเยอร์การขนส่ง (TLS)

การเลือกตัวเลือกนี้จะ “เปิดใช้งาน” ตัวเลือกของ TLS ที่ฉวยโอกาส ใน Exchange on-Premises รับตัวเชื่อมต่อ

นี่เป็นตัวเลือกเดียวที่เกี่ยวข้องกับเรื่องของการสื่อสาร “เซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ ” และคุณลักษณะของ TLS ที่ฉวยโอกาส .

<แข็งแกร่ง>2. เปิดใช้งานการรักษาความปลอดภัยของโดเมน (MutualAuth TLS)

ตัวเลือกนี้เกี่ยวข้องกับการกำหนดค่าเฉพาะที่มีชื่อว่า - ความปลอดภัยของโดเมน

เท่าที่ฉันเข้าใจ ตัวเลือกการรักษาความปลอดภัยของโดเมนจะเกี่ยวข้องเฉพาะกับสถานการณ์ที่ทั้งสองฝ่ายที่เกี่ยวข้องเป็นเซิร์ฟเวอร์ที่ใช้ Exchange ภายในองค์กรเท่านั้น

<แข็งแกร่ง>3. การรับรองความถูกต้องขั้นพื้นฐาน

ตัวเลือกของ - เสนอการรับรองความถูกต้องขั้นพื้นฐานเฉพาะหลังจากเริ่มต้น TLS มีความเกี่ยวข้องกับสถานการณ์ "ไคลเอ็นต์ถึงเซิร์ฟเวอร์" ซึ่งในไคลเอ็นต์อีเมลที่ใช้ POP3/IMAP4 จำเป็นต้องเชื่อมต่อ Exchange บน - เซิร์ฟเวอร์ในสถานที่โดยใช้โปรโตคอล TLS ข้อมูลรับรองผู้ใช้ที่ต้อง "ส่ง" ไปยังเซิร์ฟเวอร์อีเมล (Exchange on-Premises ในสถานการณ์ของเรา) จะถูกถ่ายโอนผ่านสายการสื่อสารที่ปลอดภัยของ TLS

ฉันจะรู้ได้อย่างไรว่า Exchange on-Premises ของฉันรองรับ TLS ที่ฉวยโอกาส

ในกรณีที่เราต้องการตรวจสอบว่าเมลเซิร์ฟเวอร์เฉพาะรองรับตัวเลือกการสื่อสารโดยใช้โปรโตคอล TLS หรือไม่ เราสามารถ Telnet เซิร์ฟเวอร์เฉพาะ และใช้คำสั่ง EHLO เพื่อ รับรายการตัวเลือกที่รองรับซึ่งมีอยู่ใน "เซิร์ฟเวอร์ปลายทาง"

ตัวอย่างเช่น เราจะ telnet เมลเซิร์ฟเวอร์ที่แสดงถึงชื่อโดเมน - o365info.com โดยใช้ไวยากรณ์ Telnet ต่อไปนี้:

ในภาพหน้าจอต่อไปนี้ เราจะเห็นผลลัพธ์:

คำสั่งหนึ่งที่ปรากฏในรายการคือ - 250-STARTTLS

หากมีการระบุ “250-STARTTLS ” ไว้ในการตอบกลับ แสดงว่ามีการเสนอ TLS ที่ฉวยโอกาส

แลกเปลี่ยนออนไลน์ | ตัวเชื่อมต่อจดหมายขาออกและขาเข้า

ในส่วนปัจจุบันและในส่วนถัดไป เราจะตรวจสอบหัวข้อของ TLS ที่ฉวยโอกาส ใน Exchange สภาพแวดล้อมแบบออนไลน์

ตามที่กล่าวไว้ ในสภาพแวดล้อมที่ใช้ Exchange Online เราใช้คำศัพท์ที่แตกต่างกันในการอธิบายตัวเชื่อมต่อเมล

  • ตัวเชื่อมต่อเมลขาออกเรียกว่า - ตัวเชื่อมต่อขาออก
  • ตัวเชื่อมต่อเมลขาเข้าเรียกว่า - ตัวเชื่อมต่อขาเข้า

เอาล่ะ มาถึงข้อเท็จจริงที่น่าสนใจ โดยค่าเริ่มต้น Exchange Online ไม่มีตัวเชื่อมต่อเมลเริ่มต้นใดๆ ที่ปรากฏในอินเทอร์เฟซการจัดการผู้ดูแลระบบ Exchange Online!

สภาพแวดล้อม Exchange Online ถือเป็น SaaS (ซอฟต์แวร์เป็นบริการ)

ในสภาพแวดล้อม Office 365 และ Exchange Online จะไม่มีเมลเซิร์ฟเวอร์ "เฉพาะ" สำหรับผู้เช่า Office 365 รายใดรายหนึ่ง แต่เป็นอาร์เรย์ของเมลเซิร์ฟเวอร์ที่ให้บริการและเป็นตัวแทนของผู้เช่า Office 365 ทั้งหมดแทน

ตัวเชื่อมต่อขาเข้าของ Exchange Online

Exchange Online ใช้ “เฉพาะ” ตัวเชื่อมต่อขาเข้าสำหรับผู้เช่าโดเมน Office 365 แต่ละรายที่เป็น ลงทะเบียนที่ Office 365 และกำหนดค่าสำหรับการใช้เมล แต่การตั้งค่าของตัวเชื่อมต่อขาเข้านี้ไม่ปรากฏในอินเทอร์เฟซการจัดการผู้ดูแลระบบ Exchange Online

ตัวเชื่อมต่อขาออกแบบออนไลน์ของ Exchange

สิ่งที่เรารู้ก็คือเกี่ยวกับโครงสร้างพื้นฐานเมลขาออก Exchange Online ใช้ EOP (Exchange Online Protection) เป็นโครงสร้างพื้นฐานสำหรับเมลขาออก + เมลขาเข้า

เมล “ขาออก” สำหรับผู้เช่า Office 365 ทั้งหมดจะถูกส่งผ่านอาร์เรย์เซิร์ฟเวอร์ EOP (Exchange Online Protection)

คำถามที่ชัดเจนที่อาจเกิดขึ้นคือ:

คำถาม: ฉันสามารถสร้าง ตัวเชื่อมต่อขาออก + ที่กำหนดเองได้หรือไม่ ตัวเชื่อมต่อขาเข้าrในสภาพแวดล้อม Exchange Online สำหรับผู้เช่าของฉันหรือไม่

ตอบ: คำตอบคือ “ใช่ ” เราสามารถสร้าง ตัวเชื่อมต่อขาออก< แบบกำหนดเองได้ /span> + ตัวเชื่อมต่อขาเข้าที่จะให้บริการสำหรับ - การใช้งานสถานการณ์การกำหนดเส้นทางเฉพาะ สถานการณ์การตรวจสอบสิทธิ์เฉพาะ หรือสำหรับการกำหนดค่าช่องทางการสื่อสารที่ปลอดภัยโดยใช้ TLS

ต่อไปในบทความ xx เราจะตรวจสอบหัวข้อของการสร้างและกำหนดค่าตัวเชื่อมต่อขาออกที่กำหนดเอง + ตัวเชื่อมต่อขาเข้าในสภาพแวดล้อมที่ใช้ Exchange Online

โครงสร้างพื้นฐานการแลกเปลี่ยนออนไลน์ | ตัวเชื่อมต่อเมลขาเข้า | สองเอนทิตีของ TLS ที่ฉวยโอกาสและแรง TLS

ในส่วนก่อนหน้านี้ เราประกาศว่าตามค่าเริ่มต้น Exchange Online จะไม่มีตัวเชื่อมต่อใดๆ ที่ปรากฏในอินเทอร์เฟซการจัดการผู้ดูแลระบบ Exchange Online แต่ Exchange Online จะรวม:

  1. ตัวเชื่อมต่อขาเข้าที่ “แนบมา” กับชื่อโดเมนผู้เช่า Office 365 ที่ระบุ
  2. “ตัวเชื่อมต่อขาเข้าทั่วไป ” ที่ไม่ได้แนบกับชื่อโดเมนเฉพาะ ตัวเชื่อมต่อขาเข้าทั่วไปนี้ “แนบ” กับชื่อโฮสต์สาธารณะ - office365.com

ในทางเทคนิคแล้ว เซิร์ฟเวอร์จดหมายภายนอกที่ต้องการที่อยู่เซิร์ฟเวอร์ Exchange Online ที่แสดงถึงชื่อโดเมนเฉพาะ (ผู้เช่า Office 365 ที่ลงทะเบียนชื่อโดเมนสาธารณะของเขาที่ Office 365) สามารถจัดการโครงสร้างพื้นฐานของ Exchange Online ได้โดยใช้สองวิธี:

  1. ระบุชื่อโฮสต์ที่ปรากฏในระเบียน MX
  2. กล่าวถึง “ชื่อโฮสต์ทั่วไป” - smtp.office365.com

ความแตกต่างหลักระหว่าง “เอนทิตี” ของ Exchange Online ทั้งสองรายการคือการตั้งค่า TLS

  • เอนทิตี Exchange Online ที่ปรากฏในระเบียน MX ได้รับการกำหนดค่าให้ใช้ TLS ที่ฉวยโอกาส
  • เอนทิตี Exchange Online ที่แสดงโดยชื่อโฮสต์ - office365.com ได้รับการกำหนดค่าให้ใช้ตัวเลือกของ <บังคับ TLS

กล่าวอีกนัยหนึ่ง เมื่อเซิร์ฟเวอร์อีเมลระบุชื่อโฮสต์ - smtp.office365.com Exchange Online “ต้องการ” ว่าการสื่อสารจะถูกนำไปใช้เป็นช่องทางการสื่อสารที่ปลอดภัยโดยใช้ โปรโตคอล TLS

ระบุ Exchange Online โดยใช้ชื่อโฮสต์ที่ปรากฏในระเบียน MX

“การสื่อสารเมลมาตรฐาน” ซึ่งเซิร์ฟเวอร์เมลภายนอกพยายามระบุเซิร์ฟเวอร์ Exchange Online ที่เป็นตัวแทนของโดเมนเฉพาะ จะถูกนำไปใช้โดยการค้นหาระเบียน MX ที่แสดงถึงโดเมนเฉพาะ

ในสภาพแวดล้อม Office 365 และ Exchange Online เราจะเผยแพร่ระเบียน MX โดยใช้ชื่อโฮสต์ซึ่งแสดงโดยโครงสร้างพื้นฐาน Exchange Online

ตัวอย่างเช่น ชื่อโดเมน o365pilot.com ได้รับการจดทะเบียนกับ Office 365 และโครงสร้างพื้นฐานของอีเมลโฮสต์อยู่ที่ Exchange Online

ชื่อโฮสต์ที่ปรากฏในระเบียน MX ที่ "ชี้ให้เห็น" เซิร์ฟเวอร์อีเมลที่แสดงถึงโดเมนนี้จะขึ้นอยู่กับหลักการตั้งชื่อต่อไปนี้

ในสถานการณ์เฉพาะของเรา ชื่อโฮสต์จะเป็น - o365pilot-com.mail.protection.outlook.com

ชื่อโฮสต์ Exchange Online ที่ปรากฏในระเบียน MX นั้น “ผูกไว้ ” กับ Exchange Receive connector ที่รองรับ ตัวเลือกของ TLS ที่ฉวยโอกาส

ในสถานการณ์ที่เซิร์ฟเวอร์จดหมายภายนอกระบุชื่อโฮสต์ Exchange Online ที่บัญชีสำหรับผู้เช่า Office 365 เฉพาะโดยใช้โปรโตคอล SMTP Exchange Online จะพยายามเสนอการใช้โปรโตคอล TLS แทน

  • ในกรณีที่เซิร์ฟเวอร์เมลภายนอก (เซิร์ฟเวอร์ต้นทาง) รองรับตัวเลือกของ TLS ด้วย ช่องทางการสื่อสารจะถูกนำมาใช้โดยใช้ TLS
  • ในกรณีที่เซิร์ฟเวอร์เมลภายนอก (เซิร์ฟเวอร์ต้นทาง) ไม่รองรับ ตัวเลือกของ TLS ช่องทางการสื่อสารจะถูกนำมาใช้โดยใช้ SMTP

ในไดอะแกรมต่อไปนี้ เราจะดูตัวอย่างสถานการณ์การรับส่งจดหมายซึ่งมีเซิร์ฟเวอร์จดหมายภายนอกที่อยู่เซิร์ฟเวอร์ Exchange Online โดยใช้ชื่อโฮสต์ที่ปรากฏในระเบียน MX

เมลเซิร์ฟเวอร์ภายนอกสามารถ “เลือก” ระหว่างการใช้โปรโตคอลเมลที่ไม่เข้ารหัส - SMTP หรือโปรโตคอลเมลเข้ารหัส - TLS

ถาม: ฉันจะรู้ได้อย่างไรว่าชื่อโฮสต์ Exchange Online ที่แสดงถึงโดเมนของฉันรองรับ TLS ที่ฉวยโอกาส?

ก: เราจะพยายามสร้างเซสชันเทลเน็ต SMTP ด้วยชื่อโฮสต์ Exchange Online ที่เป็นตัวแทนของผู้เช่า Office 365

ในตัวอย่างของเรา ชื่อโดเมนสาธารณะของฉันที่ลงทะเบียนที่ Office 365 คือ - o365info.com

ชื่อโฮสต์ที่ปรากฏในระเบียน MX สำหรับชื่อโดเมน - o365info.com คือ:
o365info-com.mail Protection.outlook.com

เมื่อใดจะพยายามเทลเน็ตชื่อโฮสต์นี้โดยใช้คำสั่ง

Telnet o365info-com.mail.protection.outlook.com 25

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าหลังจากที่เราพิมพ์คำสั่ง EHLO เซิร์ฟเวอร์ Exchange Online จะตอบกลับพร้อมรายการ “ตัวเลือกที่รองรับ” หนึ่งในตัวเลือกนี้คือคำสั่ง - 250-STARTTLS

ในขั้นตอนนี้ เราไม่สามารถแน่ใจได้ว่าโฮสต์รองรับ บังคับ TLS หรือ TLS ที่ฉวยโอกาส

เพื่อให้สามารถตรวจสอบได้ว่าเซิร์ฟเวอร์ (Exchange Online) รองรับเซสชัน “Standard SMTP ” หรือไม่ เราจะพยายามสร้างเซสชัน SMTP มาตรฐานโดยใช้คำสั่งต่อไปนี้:

จดหมายจาก: <ชื่อผู้รับ>

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าเซิร์ฟเวอร์ Exchange Online ตอบกลับด้วย “answer ”: 250 2.1.0 Sender OK

ความหมายก็คือเราสามารถใช้เซสชัน “มาตรฐาน SMTP ” ได้

ระบุ Exchange Online โดยใช้ชื่อโฮสต์ smtp.office365.com

เอนทิตี Exchange Online เพิ่มเติมแสดงโดยชื่อโฮสต์ smtp.office365.com

ในทางเทคนิคแล้ว “smtp.office365.com เอนทิตี Exchange Online ” สามารถเป็นตัวแทนหลัก Office 365 ทั้งหมดที่โฮสต์ที่โครงสร้างพื้นฐาน Exchange Online

กล่าวอีกนัยหนึ่ง ในกรณีที่เซิร์ฟเวอร์อีเมลจำเป็นต้องระบุที่อยู่เซิร์ฟเวอร์อีเมล Exchange Online ที่แสดงถึงผู้เช่า Office 365 เฉพาะ (ชื่อโดเมนสาธารณะเฉพาะ) เซิร์ฟเวอร์อีเมลภายนอกสามารถระบุที่อยู่โฮสต์ smtp.office365 .com แทนที่จะค้นหาระเบียน MX ที่แสดงถึงโดเมน Office 365 เฉพาะ

วัตถุประสงค์หลักของเอนทิตี “Exchange Online smtp.office365.com ” คือการเปิดใช้งานการสื่อสารทางเมลที่ปลอดภัยเท่านั้น ซึ่งหมายถึง บังคับ TLS

กล่าวอีกนัยหนึ่ง วิธีเดียวที่จะจัดการกับเอนทิตี smtp.office365.com ของ Exchange Online คือการใช้ TLS

ตัวอย่างของสถานการณ์ที่เราจำเป็นต้องจัดการกับเอนทิตี smtp.office365.com ของ Exchange Online คือ สถานการณ์จำลอง โดยที่เรามีแอพพลิเคชั่นที่เปิดใช้งานเมลหรืออุปกรณ์ที่เปิดใช้งานเมลซึ่งจำเป็นต้อง “ใช้” เซิร์ฟเวอร์ Exchange Online ในการส่งอีเมล

ในอดีต วิธีเดียวที่เป็นไปได้ในการใช้สถานการณ์ประเภทนี้คือการกำหนดค่าอุปกรณ์ที่เปิดใช้งานอีเมล\แอปพลิเคชันเพื่อระบุชื่อโฮสต์ -
smtp.office365.com

อุปสรรคที่ใหญ่ที่สุดของข้อกำหนดนี้คืออุปกรณ์ที่เปิดใช้งานเมลส่วนใหญ่ไม่รองรับ TLS

ในปัจจุบัน วิธีแก้ปัญหานั้นง่ายกว่า เนื่องจากเราสามารถกำหนดค่าอุปกรณ์ที่เปิดใช้งานเมลให้ใช้ชื่อโฮสต์ Exchange Online “มาตรฐาน” โดยไม่จำเป็นต้องมีข้อกำหนดบังคับในการใช้ TLS

หมายเหตุ: หากต้องการเปิดใช้งานอุปกรณ์ที่เปิดใช้งานเมล\แอปพลิเคชันเพื่อที่อยู่เซิร์ฟเวอร์ Exchange Online โดยใช้ SMTP และส่งอีเมลไปยังผู้รับภายใน + ภายนอก เราจะต้องสร้างตัวเชื่อมต่อขาเข้าด้วยตนเองซึ่งจะระบุไคลเอ็นต์อีเมลนี้ ตามที่อยู่ IP สาธารณะของพวกเขา

ในไดอะแกรมต่อไปนี้ เราจะเห็นตัวอย่างของการรับส่งอีเมลที่มักจะนำไปใช้เมื่ออุปกรณ์หรือแอปพลิเคชันที่เปิดใช้งานเมลระบุเซิร์ฟเวอร์ Exchange Online โดยใช้ชื่อโฮสต์ที่กำหนดไว้ล่วงหน้า smtp.office365.com

คำถาม: ฉันจะรู้ได้อย่างไรว่าชื่อโฮสต์ Exchange Online smtp.office365.com รองรับเฉพาะ บังคับ TLS?

A: เราจะพยายามสร้างเซสชัน telnet SMTP ด้วยชื่อโฮสต์ Exchange Online smtp.office365.com

เมื่อใดจะพยายามเทลเน็ตชื่อโฮสต์นี้โดยใช้คำสั่ง

Telnet smtp.office365.com 25

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าหลังจากที่เราพิมพ์คำสั่ง EHLO เซิร์ฟเวอร์ Exchange Online จะตอบกลับพร้อมรายการ “ตัวเลือกที่รองรับ” หนึ่งในตัวเลือกนี้คือคำสั่ง - 250-STARTTLS

ในขั้นตอนนี้ เราไม่สามารถแน่ใจได้ว่าโฮสต์รองรับ บังคับ TLS หรือ TLS ที่ฉวยโอกาส

เพื่อให้สามารถตรวจสอบได้ว่าเซิร์ฟเวอร์ (Exchange Online) รองรับเซสชัน “Standard SMTP ” หรือไม่ เราจะใช้คำสั่ง:

จดหมายจาก: <ชื่อผู้รับ>

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าเซิร์ฟเวอร์ Exchange Online ตอบกลับด้วย “answer”:

530 5.7.57 SMTP; ลูกค้าไม่ได้รับการรับรองความถูกต้องให้ส่งจดหมายที่ไม่ระบุชื่อระหว่าง MAIL FROM

ความหมายก็คือเรา ไม่สามารถ ใช้เซสชัน "SMTP มาตรฐาน "

หมายเหตุ: ไคลเอ็นต์เทลเน็ต cmd มาตรฐานไม่สนับสนุนตัวเลือกในการใช้โปรโตคอล TLS

บทความถัดไป

บทความถัดไป (การกำหนดค่าตัวเลือกของ Force TLS ในสภาพแวดล้อม Exchange on-Premises | ตอนที่ 4#12) ในชุดบทความ TLS มีไว้เพื่อหัวข้อ - การกำหนดค่าตัวเลือกของ Force TLS ในสภาพแวดล้อม Exchange on-Premises

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