หน้าที่หลักประการสำคัญของ Exchange Server ก็คือการรับ/ส่ง Email นั่นเองครับ ซึ่งนี่แหละที่ช่วยให้ Email สามารถเดินทางจากผู้ส่งไปยังผู้รับ ได้อย่างถูกต้องและมีประสิทธิภาพ ไม่สูญหายไประหว่างทาง (ในทางทฤษฏีนะครับ) ดังนั้นในภาคนี้จะกล่าวให้เห็นภาพการทำงานของ Mail Flow และ Transport Pipeline ใน Exchange Server 2016 เสียก่อนครับ
(ปล. จริงๆ ในภาคที่แล้ววางแผนไว้ว่าจะพาไป Config mail Flow เลย แต่คิดไปคิดมาแล้วขอมาอธิบาย Mail Flow เสียก่อนดีกว่า เวลาไป Config จะได้เข้าใจภาพการทำงานได้อย่างละเอียดครับ)
- Mail Flow
(ในหัวข้อนี้จะยังไม่ลงรายละเอียดนะครับ ว่า Email Server เนี่ยเป็น Software ตัวไหน เพราะทุก Software ใช้หลักการเดียวหมดไม่ว่าจะเป็น Exchange Server, Domino หรือ Email Software ใดๆ ก็ตามครับ)
Mail Flow (หรือว่าการไหลของ e-mail) จริงๆ ผมว่าไม่แปลจะดีกว่ามั้งเนี่ย 55555 ในระบบของ e-mail Server นั้นสามารถแบ่งออกได้เป็น 2 ทิศทางหลักๆ (โดยพิจารณาที่ตัวระบบ e-Mail server ของเราเป็นหลัก) คือ
- Email ขาเข้าองค์กร (หมายถึงว่ามีคนใดๆ จาก internet ส่งเมล์มาให้ใครสักคนในบริษัทของเรา)
E-Mail ขาเข้าองค์กรนั้น จะมี Server ที่เกี่ยวข้องด้วยกัน 3 ส่วนหลักๆ ก็คือ Email Server ต้นทาง, Public DNS และ Email Server ของผู้รับดังรูป ซึ่งประกอบด้วยกันทำงาน 4 ขั้นตอนด้วยกัน
ขั้นตอน 0
อันนี้เป็นขั้นตอนเริ่มต้น โดยผู้ดูแลระบบจะต้องไปกำหนดข้อมูลที่เรียกว่า “MX Record“
ไว้ใน DNS Server ภายนอก (ซึ่งก็คือ DNS Server ที่เราไปจดทะเบียนโดเมนของบริษัทไว้นั่นแหละครับ) เจ้าตัว DNS Server ตัวนี้ผมจะเรียกว่า Public DNS รูปต่อไปนี้แสดงตัวอย่างข้อมูลทีเกี่ยวข้องในการทำงานของ MX Record ใน Public DNS ของโดเมนสมมุติที่ชื่อว่า demo.com
จากรูปจะเห็นได้ว่าเรามี E-mail Server จำนวน 2 เครื่อง คือ mail.demo.com และ mail2.demo.com โดยเรามีการกำหนดให้ mail.demo.com ชี้ไปที่หมายเลข IP Address 100.100.100.103 และ mail2.demo.com ชี้ไปที่ IP Address 200.200.200.200 นอกจากนี้เรายังมีการกำหนด MX Record ให้ด้วย โดยมี MX Record (ตัวเลขใน [] หมายถึง Priority) ซึ่งมี Priority 10 ชี้ไปยัง mail.demo.com และ Priority 20 ชี้ไปยัง mail2.demo.com ไอ้เจ้า Priority นี่แหละที่จะบอก E-Mail Server ของผู้ส่ง Email ว่าให้ทำการส่ง Email ไปยัง MX Record ที่มี Priority น้อยที่สุด ก็คือเจ้า Priority 10 นั่นเอง ดังนั้น Email ทุกฉบับจาก internet ก็จะไปยัง mail.demo.com ที่หมายเลข IP 100.100.100.103
อ้าว !!! แล้วจะมี MX ที่มี Priority อื่นๆไว้ทำไมหล่ะ ก็เอาไว้ตอนที่ Priority น้อยที่สุดเกิดล่ม เจ้าตัว E-Mail Server ต้นทางก็จะพยายามส่ง E-Mail ไปยัง E-mail Server ของเราตัวที่มี Priority สูงขึ้น เช่น mail2.demo.com นั่นเอง ดังนั้นเราอาจจะกล่าวได้ว่าเรามีระบบ Backup Email นั่นเองครับ
ขั้นตอน 1 Email Server ต้นทางจะทำการส่งคำถามไปยัง Public DNS ของบริษัทของเรา
ขั้นตอน 2 Public DNS ของบริษัทของเราจะส่งข้อมูล MX Record ไปให้ Email Server ต้นทาง
ขั้นตอน 3
Email Server ต้นทาง จะทำการส่ง Email ไปยัง Email Server ปลายทาง โดยอาศัยข้อมูลจาก MX Record ในขั้นตอน 2 ซึ่งในขั้นตอนนี้สิ่งที่จะมีปัจจัยสำคัญอีกประการหนึ่งก็คือเจ้า Firewall ครับที่จะต้อง Config ให้ตัว Firewall ทำการ forward การเชื่อมต่อไปยัง Email Server ให้ถูกต้อง ซึ่งโดยส่วนใหญ่แล้วการเชื่อมต่อตรงนี้จะใช้ Port TCP หมายเลข 25
ครับ
- Email ขาออกจากองค์กร (หมายถึงว่าคนในองค์กร เกิดมีการส่ง Email ไปหาบุคคลภายนอก)
สำหรับ Email ขาออกจากองค์กรนั้นก็ไม่ได้แตกต่างจาก Email ขาเข้าดังที่กล่าวไปแล้ว เพียงแต่เราสลับการทำงานกันระหว่าง Email Server ต้นทางและปลายทางเท่านั้นเองครับ เพียงแต่ว่าในปัจจุบันนี้ระบบ Email ได้มีการพัฒนาปรับปรุงทางด้านการรักษาความปลอดภัยมากขึ้น และสิ่งหนึ่งที่ควรจะทำก็คือการประกาศ Sender ID ครับ
เนื่องจากในระบบการส่ง email นั้นไม่มีกระบวนการในเรื่องของการ Authentication ว่า Email ที่ส่งนั้นมาจากผู้ส่งจริงๆ หรือไม่ ดังนั้นจึงทำให้เป็นที่มาของพวก Email ที่ไม่มีตัวผู้ส่งอยู่จริง หรืออาจจะมีผู้ไม่หวังดีแอบเอา Email Address ของบริษัทเราไปใช้ก็ได้ การประกาศ Sender ID เป็นการช่วยให้ Email Server สามารถตรวจสอบได้ว่าเป็น Email ที่มาจากบริษัทเจ้าของโดเมนจริงๆ โดยมีกระบวนการในการทำงานดังนี้
จากรูปแสดงการทำงานในเพิ่มจากการรับ/ส่ง Email โดยในรูป Email Server ต้นทางได้รับการ Config ให้ตรวจสอบ Sender ID ด้วย ซึ่งจะมีขั้นตอนดังนี้
ขั้นตอน 0
อันนี้เป็นขั้นตอนเริ่มต้น โดยผู้ดูแลระบบจะต้องไปกำหนดข้อมูลที่เรียกว่า “SPF (Sender Policy Framework)“
ไว้ใน DNS Server ภายนอก (โดย SPF Record นั้นจะมี Record Type เป็น “TXT”)
สำหรับวิธีการสร้างข้อมูลที่เป็น SPF นั้นสามารถใช้ตัวช่วยได้ง่ายๆ จากเว็บไซต์ต่างๆ เช่น http://www.spfwizard.net/ เป็นต้น
โดยตัวอย่างนี้มีการกำหนด SPF เป็น v=spf1 mx ip4:100.100.100.103 a:200.200.200.200 ~all มีความหมายโดยสรุปดังต่อไปนี้
- V=spf1 หมายถึงใช้ SPF Version 1
- MX หมายถึงอนุญาติให้เครื่องที่มีรายการปรากฎอยู่ใน MX Record ถือว่าเป็นเครื่อง Email Server ที่สามารถส่ง Email ออกได้สำหรับ โดเมนเนม demo.com
- Ip4:100.100.100.103 หมายถึงอนุญาติให้เครื่อง Email Server ที่มีหมายเลขไอพี 100.100.100.103 สามารถส่ง Email ออกได้สำหรับ โดเมนเนม demo.com
- Ip4:200.200.200.200 หมายถึงอนุญาติให้เครื่อง Email Server ที่มีหมายเลขไอพี 200.200.200.200 สามารถส่ง Email ออกได้สำหรับ โดเมนเนม demo.com
- ~all หมายถึง ให้ Email Server ปลายทางตรวจสอบว่าหมายเลขไอพีของผู้ส่ง Email เป็นไปตามที่กำหนดดังกล่าว หรือไม่ โดย ~all จะอนุญาติให้ Email Server สามารถรับ Email เข้ามาไว้ได้ แต่ให้ทำการเพิ่ม Header พิเศษ ไว้ว่า Email ฉบับนั้นมาจาก Email Server ที่ไม่เป็นตามข้อกำหนด
ขั้นตอน 1 Email Server ปลายทางจะทำการส่งคำถามไปยัง Public DNS ของบริษัทของเรา เพื่อค้นหาข้อมูลที่บรรจุอยู่ใน SPF
ขั้นตอน 2 Public DNS ของบริษัทของเราจะส่งข้อมูล SPF ไปให้ Email Server ปลายทาง
ขั้นตอน 3
Email Server ปลายทางจะทำการเปรียบเทียบ IP Address ของ Email Server ต้นทาง กับข้อมูลใน SPF ว่าตรงกันหรือไม่ หากตรงกันก็แสดงว่าผู้ส่ง Email นั้นเป็นผู้ส่งจาก Domain Name อย่างแท้จริง
ซึ่งเจ้า SPF นี้จะช่วยป้องกันการ Spoofing Email ได้บ้างครับ ดังนั้นจึงแนะนำให้เปิดไว้ครับ ซึ่งปัจจุบันผู้ให้บริการ email หลายๆ รายอาทิเช่น Hotmail, Gmail ก็มีการเปิดใช้งานการทำงานในส่วนนี้ด้วยครับ
-
Transport Pipeline (https://technet.microsoft.com/en-us/library/aa996349(v=exchg.160).aspx)
ก่อนทีจะลงรายละเอียดของ Transport Pipeline นั้นผมขออธิบายความหมายของ Transport Pipeline เสียก่อนสักนิดนะครับ
Transport Pipeline
หมายถึง ชุดของบริการ (Services), การเชื่อมต่อ (Connections), องค์ประกอบ (Components) และคิว (Queue) ที่ทำงานร่วมกันในการจัดส่ง Email เพื่อให้ไปประมวลผลในระบบของ Exchange Server 2016 ซึ่ง Transport Pipeline ของ Exchange Server 2016 ประกอบด้วย Service ต่างๆ จำนวน 4 Service คือ
- Front End Transport Service
เป็น service ที่มีหน้าที่รับการเชื่อมต่อไม่ว่าจะเป็นการเชื่อมต่อขาเข้า (In Bound) หรือการเชื่อมต่อขาออก (Out Bound) โดยจะไม่มีการแก้ไขข้อมูลใดๆ ในขั้นตอนนี้ และไม่มีการเก็บข้อมูลใดๆ ของ Email ไว้ที่ Front End Transport Service สำหรับ Front End Transport Service นั้น ใน Exchange 2013 จะอยู่ที่เครื่อง Client Access Server แต่ใน Exchange 2016 ได้ยุบรวมมาไว้ที่ Mailbox Server Role - Transport Service On Mailbox Server การทำงานของ Service นี้สามารถเทียบได้กับ Hub Transport Service ใน Exchange Server 2010 โดย Transport Service On Mailbox Server จะรับผิดชอบการทำงานของ SMTP (Simple Mail Transfer Protocol) ทั้งหมดภายในระบบของ Exchange Server หน้าที่หลักของ Transport Service On Mailbox Server คือการจำแนกประเภทของ Email และการตรวจสอบเนื้อหาภายในของ Email ต่างๆ
-
Mailbox Transport Service On Mailbox Server เป็นบริการเพียงส่วนเดียวที่สามารถทำการเชื่อมต่อกับ Mailbox Database ได้โดยใช้โพรโทคอล RPC (Remote Procedure Call)
Mailbox Transport Service On Mailbox Server แบ่งออกเป็น 2 ส่วนย่อยคือ
- Mailbox Transport Submission Service มีหน้าที่นำเอา Email ที่ผู้ใช้งานมีการส่งออก (ซึ่งเก็บไว้ใน mailbox ของตัวผู้ใช้งาน) มาทำการส่งออกไปให้ Email นั้นสามารถเดินทางไปถึงผู้รับ Email
- Mailbox Transport Delivery Service มีหน้าที่นำ Email ที่รับมายังผู้ใช้งานของระบบ Exchange และนำไปเก็บไว้ใน Mailbox Database
- Mailbox Transport Submission Service มีหน้าที่นำเอา Email ที่ผู้ใช้งานมีการส่งออก (ซึ่งเก็บไว้ใน mailbox ของตัวผู้ใช้งาน) มาทำการส่งออกไปให้ Email นั้นสามารถเดินทางไปถึงผู้รับ Email
- Transport Service On Edge Transport Server มีหน้าที่เหมือนกับ Transport Service On Mailbox Server แต่จะติดตั้งไว้ใน perimeter network (หรือนิยมเรียกว่า DMZ network) เพื่อให้เกิดความปลอดภัยมากขึ้น
หมายเหตุ: Front End Transport Service นั้นจะไม่สามารถเชื่อมต่อกับ Mailbox Transport Service On Mailbox Server ได้ โดยตรง ต้องเชื่อมต่อผ่านมาทาง Transport Service On mailbox Server เท่านั้น
ซึ่งหากลองตรวจสอบดูใน Services.msc ของ Windows จะพบว่ามี Service ดังกล่าวติดตั้งอยู่ดังรูป
ทั้งนี้การเชื่อมต่อระหว่าง Service ต่างๆ สามารถแสดงให้เห็นได้ โดยใช้แผนภาพข้างล่างนี้
เอาละครับตอนนี้ก็น่าจะพอเห็นภาพคร่าวๆ แล้วนะครับว่ามีขั้นตอนอะไรบ้าง ซึ่งหลังจากนี้ไปผมจะขอกล่าวถึงการทำงานที่แสดงไว้ในรูป ดังนี้ครับ (จาก MOC วิชา 20341 – Exchange 2013 Core Solutions)
- SMTP Send
เป็นส่วนที่ทำหน้าที่ในการสร้างการเชื่อมต่อโดยใช้โพรโทคอล SMTP เพื่อทำการส่ง Email ฉบับนั้นๆ ไปยังองค์ประกอบอื่นๆ ต่อไป โดยทำการส่ง email ต่อไปยัง SMTP Receive ขององค์ประกอบที่เกี่ยวข้องต่อไป - SMTP Receive
มีหน้าที่รับ email จากองค์ประกอบอื่นๆ เข้ามาสู่การประมวลผลของ Service นั้นๆ รวมทั้งรับ Email จากอินเทอร์เน็ตด้วย ในระบบของ Exchange Server 2016 นั้นจะมีการทำงานของ SMTP Receive อยู่หลายที่ด้วยกัน ซึ่งแต่ละที่จะมีการทำงาน Port Number ที่แตกต่างกัน แต่ SMTP Receive ที่ใช้งานในการรับ Email จากอินเทอร์เน็ต จะทำงานที่ Port หมายเลข TCP/25 เมื่อ SMTP Receive รับ email มาแล้วจะนำไปประมวลผลต่อโดยใช้ Protocol Agent ต่างๆ เช่น Transport Rules หรือ Anti-Malware, Anti-Spam เพื่อประมวลผล Email ต่างๆ เหล่านี้ หากได้รับอนุญาติให้ผ่านเข้าสู่ระบบ SMTP Receive จะนำ Email ฉบับนั้นไปเก็บไว้ใน Submission Queue เพื่อรอการประมวลผลต่อไป - Categorizer มีหน้าที่รับ Email ที่เก็บไว้ใน Submission Queue ตลอดจน Pickup and Replay Directory เพื่อนำมาทำการประมวลผลในลำดับต่อไป เช่นการระบุความถูกต้องของผู้รับ Email, การประมวลผล Distribution List, การค้นหาเส้นทาง (Routing path), การสร้าง NDR (Non-Delivery Report), การปรับเปลี่ยน (convert) MIME Type ต่างๆ หรือแม้กระทั่งการทำงานของ Message Policy ตามนโยบายขององค์กร
- Pickup and Replay Directory ในส่วนนี้ไม่นิยมใช้งานกันมากนัก เป็นการนำเอา Email ที่มีการจัดรูปแบบในรูปแบบของ SMTP ไว้แล้ว มาวางไว้ใน Folder ที่กำหนด จากนั้น Store Driver จะทำการอ่าน Email ใน Folder นี้เข้าไปสู่ Submission Queue เพื่อประมวลผลต่อไป โดยมาก Pickup and Replay Directory จะใช้ในการกรณีที่มีการ Recover Email กลับมาจากระบบที่เสียหาย หรือใช้ร่วมกับการทำงานของ Legacy Application ในการส่ง Email
ตัวอย่าง Email ใน Pickup Directory | ตัวอย่าง Email ใน Replay Directory |
To: [email protected] From: [email protected] Subject: Message subject This is the body of the message. |
X-Receiver: <[email protected]> NOTIFY=NEVER [email protected] X-Sender: <[email protected]> BODY=7bit ENVID=12345AB auth=<someAuth> Subject: Optional message subject This is the body of the message. |
ซึ่งโดยปกติแล้ว ค่า Default ของ Pickup Directory และ Replay Directory จะอยู่ที่ Folder ดังนี้
-
Store Driver เป็นส่วนหนึ่งของ Software Component ในส่วนของ Mailbox Transport Service ประกอบด้วย 2 ส่วนด้วยกันคือ
- Store Driver Submit มีหน้าที่อ่าน Email ที่ผู้ใช้งานมีการส่งออก ซึ่งจะอยู่ใน Folder “Outbox”
ใน mailbox ของผู้ใช้งาน (การทำงานในส่วนนี้จะใช้โพรโทคอลที่ชื่อว่า RPC – Remote Procedure Call) จากนั้นจึงนำ Email ที่อ่านได้นั้นส่งไปให้กับ Hub Selector เพื่อทำงานต่อไป
และเมื่อ Email นั้นได้รับการประมวลผลจนสามารถเข้าไปสู่ใน Submission Queue เป็นที่เรียบร้อยแล้ว Store Driver Submit จะทำหน้าที่ย้าย Email จาก Outbox ไปไว้ใน Sent Item นอกจากนี้ Store Driver Submit ยังมีหน้าที่ในการ Convert ข้อมูลให้อยู่ในรูปแบบที่เหมาะสมกับการทำงานของ Submission Queue เช่นการแปลงรูปแบบของ Attachment File เป็นต้น - Store Driver Deliver มีหน้าที่นำเอา Email ที่ส่งมาถึงผู้รับ ไปเก็บไว้ใน Mailbox ของผู้ใช้งาน บน Mailbox Database ที่เหมาะสมบนเครื่อง Exchange Server โดยการทำงานนี้จะใช้โพรโทคอลที่ชื่อว่า RPC เช่นเดียวกับ Store Driver Submit
- Store Driver Submit มีหน้าที่อ่าน Email ที่ผู้ใช้งานมีการส่งออก ซึ่งจะอยู่ใน Folder “Outbox”
- Delivery Queue เป็นที่เก็บ Email ที่รอการส่งออกจาก Transport Service On Mailbox Server โดย Email ที่เก็บไว้ในจะทยอยส่งไปยัง SMTP Send เพื่อทำการส่ง Email ต่อไป ซึ่ง SMTP Send อาจจะทำการส่ง Email นี้ไปยัง Mailbox Server เครื่องอื่นๆ ในระบบของ Exchange Server หรืออาจจะทำการส่งออกไปยังอินเทอร์เน็ตก็ได้ (ทั้งนี้หากมีการ configure ให้ส่ง Email โดย Proxy ผ่านไปยัง Front End Transport Service ก็สามารถทำได้เช่นกัน ดังแสดงด้วยลูกศรเส้นประในรูป)
เอาล่ะครับ หลังจากอธิบายถึง Transport Pipeline และการทำงานขององค์ประกอบต่างๆ ไปแล้ว ทีนี้เราลองมาดูตัวอย่างกันเลยว่าเวลา Exchange Server รับ Email มา 1 ฉบับนั้นจะเกิดการทำงานอะไรขึ้นบ้าง โดยแบ่งออกเป็น 2 กรณีหลักๆ คือ
- การรับ Email (Inbound)
จากรูปสมมุติว่ามี email เข้ามา 1 ฉบับมาหา [email protected] เข้ามาทาง Exchange ซึ่งเป็น Mailbox Server 1 ซึ่งจะรับ Email ฉบับนี้ โดย SMTP Receive และผ่านกระบวนการ Hub Selector เพื่อเลือกว่าจะส่งไปให้กับ Mailbox เครื่องใดประมวลผลต่อ (สมมุติว่าเลือกให้ Mailbox Server 2 ประมวลผลต่อ) ก็จะส่งไปยัง SMTP Send ของตน และส่งไปยัง SMTP Receive ในส่วนของ Transport service บนเครื่อง Mailbox Server 2
จากนั้น SMTP Receive ที่ Transport Service บนเครื่อง Exchange Server 2 ก็จะประมวลผลต่อไป ผ่านทาง Protocol Agent เพื่อตรวจสอบส่วนที่เกี่ยวข้องกับ Transport Rules, Anti-Malware, Anti-Spam และผ่านไปที่ Submission Queue, Categorizer, Deliver Queue ตามลำดับ จบท้ายที่ SMTP Send เพื่อส่งต่อการทำงานไปยั Mailbox Transport Service
SMTP Receive ที่ Mailbox Transport Service ก็จะทำการส่ง Email นี้ไปที่ Store Driver Deliver เพื่อนำ Email ไปเก็บไว้ใน Mailbox ของผู้ใช้รับเป็นลำดับสุดท้าย
สำหรับองค์กรที่มีการติดตั้ง Edge Transport Server นั้นก็จะมีการรับ Email เข้ามาที่ Edge Transport Server เพื่อประมวลผลในส่วนของ Edge Transport ต่างๆ เช่น Transport Rules รวมถึง Anti-Virus, Anti-Spam ก่อนที่จะส่ง Email ที่ผ่านการตรวจสอบแล้วไปยัง Front End Transport Service ที่ Mailbox Server ดังรูป
-
การส่ง Email (Outbound)
สำหรับการส่ง Email หรือที่นิยมเรียกว่า Outbound Email นั้น จะมีการทำงานที่ซับซ้อนกว่าการรับ Email พอสมควร ซึ่งสามารถแบ่ง Outbound Email ออกได้เป็น 2 กรณีคือ
-
กรณีที่ผู้รับอยู่ภายในองค์กร
กรณีนี้เริ่มจากการที่ผู้ส่ง ([email protected]) ทำการส่ง Email ไปหาผู้รับ ([email protected]) สมมุติว่าผู้ใช้ใช้ Microsoft Outlook ซึ่ง Microsoft Outlook จะมีการนำ Email ฉบับที่ต้องการจะส่งไปเก็บไว้ใน Folder Outbox ของผู้ส่งเสียก่อน
สมมุติว่าผู้ส่งอยู่ Mailbox Database ในเครื่อง Exchange Server#1 Store Driver Submit จะทำการอ่าน Outlook ของ [email protected] เพื่อนำ Email ที่ต้องการส่งไปใส่ไว้ใน submission Queue และย้าย Email จาก Outbox ไปไว้ยัง Sent Item
เมื่อ Email ไปอยู่ใน Submission Queue ก็จะถูกประมวลผลตามขั้นตอนต่างๆ โดยเฉพาะ Routing Agent ที่จะคอยค้นหาว่า user ผู้รับคือ [email protected] นั้นอยู่ที่ mailbox database ไหน ก็จะทำการส่ง Email ฉบับนั้นไปยัง Exchange Server ที่มี mailbox ของผู้รับอยู่ในที่นี้คือ Exchange Server#2
ทีเครื่อง Exchange Server#2
Email ก็จะถูกประมวลผลโดยลำดับ และผ่านจาก Transport Service on Mailbox Server ไปยัง Mailbox Transport Service โดยไปที่ Store Driver Deliver เพื่อนำ Email ฉบับนั้นไปเก็บใน mailbox ของ [email protected] ซึ่งเป็นผู้รับ Email -
กรณีที่ผู้รับอยู่ภายนอกองค์กร
แต่หากผู้รับนั้นอยู่ภายนอกนอกองค์กร
ก็จะเกิดการประมวลผลในทำนองเดียวกันคือเริ่มจากการที่ผู้ส่ง ([email protected]) ทำการส่ง Email ไปหาผู้รับ ([email protected]) สมมุติว่าผู้ใช้ใช้ Microsoft Outlook ซึ่ง Microsoft Outlook จะมีการนำ Email ฉบับที่ต้องการจะส่งไปเก็บไว้ใน Folder Outbox ของผู้ส่งเสียก่อน
สมมุติว่าผู้ส่งอยู่ Mailbox Database ในเครื่อง Exchange Server#1 Store Driver Submit จะทำการอ่าน Outlook ของ [email protected] เพื่อนำ Email ที่ต้องการส่งไปใส่ไว้ใน submission Queue และย้าย Email จาก Outbox ไปไว้ยัง Sent Item
เมื่อ Email ไปอยู่ใน Submission Queue ก็จะถูกประมวลผลตามขั้นตอนต่างๆ และเมื่อถึงขั้นตอนของ Routing Agent ที่ Exchange Server#1 ก็ไม่จำเป็นต้องส่งต่อ Email ไปยัง Exchange Server#2
(เพราะผู้รับอยู่ภายนอกองค์กร) Transport Service on Mailbox Server ก็สามารถที่จะส่ง email นั้น ให้ Proxy ผ่าน Front End Transport Service เพื่อทำการส่ง Email ออกจากระบบของ Exchange Server ไปหาผู้รับได้ทันที
นอกจากนี้หากมี Edge Transport Server ก็จะมีขั้นตอนที่เพิ่มเติมขึ้นมา คือ Frontend Transport Service จะส่งต่อ Email ผ่านไปให้กับ Edge Transport Server เพื่อส่ง Email ต่อไปยังอินเทอร์เน็ตภายนอกนั่นเอง แต่หากเป็นการส่งเมล์ภายในองค์กร ก็ไม่จำเป็นต้องใช้งาน Edge Transport Server
เอาละครับ หลังจากได้กล่าวถึงการทำงานของ Mail Flow และ Transport Pipeline ของ Exchange 2016 กันไปแล้ว เดี๋ยวภาคถัดไปจะพาไป configure การรับ/ส่ง Email ใน Exchange 2016 กันแบบจริงๆ จังๆ แล้วนะครับ ตอนนี้ก็ไปเตรียม joking รอกันก่อนนะครับ 55555 ฮ่า ฮ่า ฮ่า ฮ่า
Blog Post ที่เกี่ยวข้อง
ภาค 1 – สถาปัตยกรรม และความสามารถใหม่
ภาค 2 – เริ่มต้นติดตั้ง Exchange Server 2016 Mailbox Server Role
ภาค 3 – Exchange Server 2016 Management Tools