แก้ไขปัญหาการส่งอีเมลขาออกของ Zimbra ที่ถูกเลื่อนออกไป: “การเชื่อมต่อหมดเวลา พอร์ต 25”

หาก Zimbra รายงานconnect to mx.example.net[203.0.113.25]:25: Connection timed outข้อความดังกล่าว แสดงว่าข้อความนั้นได้เข้าสู่คิวอีเมลของ Zimbra แล้ว แต่เซิร์ฟเวอร์ยังไม่ได้สร้างการเชื่อมต่อ TCP กับตัวแลกเปลี่ยนอีเมลของโดเมนผู้รับ เริ่มต้นด้วยการตรวจสอบคิว DNS และเส้นทางเครือข่ายขาออก อย่าเปลี่ยนค่าหมดเวลาของ Postfix หรือล้างคิวซ้ำๆ จนกว่าคุณจะทราบว่าจุดใดที่ขัดขวางการเชื่อมต่อ

การหมดเวลา (Timeout) แตกต่างจากการปฏิเสธ SMTP การปฏิเสธ เช่น “550” หมายความว่าเซิร์ฟเวอร์ระยะไกลตอบกลับและปฏิเสธข้อความ ในขณะที่ “Connection timed out” หมายความว่าความพยายามในการเชื่อมต่อไม่ได้รับการตอบสนองอย่างทันท่วงที สาเหตุอาจเกิดจากไฟร์วอลล์ในเครื่อง นโยบายอีเมลขาออกของผู้ให้บริการคลาวด์หรือโฮสติ้ง การกำหนดเส้นทาง ปลายทางที่ไม่สามารถเข้าถึงได้ หรือในกรณีที่พบได้น้อยคือปัญหาเกี่ยวกับ DNS/ตระกูลที่อยู่

ข้อความ “Connection timed out port 25” ใน Zimbra หมายความว่าอย่างไร?

Zimbra ใช้ MTA (Mail Exchange Agent) ในการกำหนดเส้นทางการส่งข้อความขาออก เมื่อผู้รับอยู่นอกองค์กรของคุณ MTA จะค้นหา Mail Exchanger ของโดเมนนั้นและเชื่อมต่อโดยใช้ SMTP คู่มือผู้ดูแลระบบ Daffodil ฉบับปัจจุบันของ Zimbra อธิบายว่าข้อความที่ไม่สามารถส่งได้จะเข้าสู่คิวรอส่ง (Deferred Queue) ซึ่งจะมีการลองส่งใหม่อีกครั้ง รายการในคิวและบันทึกอีเมลจะระบุปลายทางและข้อผิดพลาด ดังนั้นจึงเป็นหลักฐานเริ่มต้นที่ดีที่สุด

ในการรับส่งอีเมลทั่วไป เซิร์ฟเวอร์อีเมลสาธารณะจะแลกเปลี่ยนอีเมลกันผ่านพอร์ต TCP 25 ส่วนพอร์ต 587 นั้นมักใช้โดยไคลเอนต์อีเมลที่ได้รับการรับรองความถูกต้องเพื่อส่งข้อความไปยังรีเลย์ขาออก การเปลี่ยนเส้นทางรีเลย์ของ Zimbra ไปยังพอร์ต 587 เป็นเพียงตัวเลือกเมื่อคุณได้กำหนดค่าบริการรีเลย์ที่ได้รับอนุญาตสำหรับวัตถุประสงค์นั้นแล้ว ไม่ใช่การทดแทนโดยทั่วไปสำหรับการรับอีเมลทางอินเทอร์เน็ตบนพอร์ต 25

1. ปัญหาดังกล่าวส่งผลกระทบต่อผู้รับทุกคนหรือเฉพาะโดเมนเดียว?

ตรวจสอบคิวที่รอการดำเนินการก่อนทำการเปลี่ยนแปลงใดๆ บนโฮสต์ Zimbra MTA ให้เรียกใช้คำสั่งผู้ดูแลระบบโดยใช้zimbraบัญชีดังกล่าว:

su - zimbra
postqueue -p

สังเกตข้อความหมดเวลาซ้ำๆ และจดบันทึกโดเมนผู้รับ โฮสต์เนม MX เป้าหมาย และที่อยู่ IP ที่แปลงแล้ว ในคอนโซลการจัดการ Zimbra ให้เปิดMonitor → Mail Queuesและตรวจสอบคิว Deferred โดยดูจากประเภทข้อผิดพลาดและโดเมนผู้รับ ป้ายชื่อเมนูอาจแตกต่างกันไปตามรุ่นและเวอร์ชันของ Zimbra

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

2. ระบบ DNS สามารถแปลงโดเมนของผู้รับเป็นเซิร์ฟเวอร์อีเมลที่สามารถเข้าถึงได้หรือไม่?

ตรวจสอบระเบียน MX ของโดเมนผู้รับจากเซิร์ฟเวอร์ Zimbra แทนที่example.netด้วยโดเมนที่มีปัญหา:

dig MX example.net +short

ใช้ชื่อโฮสต์ MX ที่ได้มาเพื่อค้นหาที่อยู่ของมัน:

dig A mx.example.net +short
dig AAAA mx.example.net +short

โดเมนอาจมี MX host หลายตัว ทดสอบชื่อ host จริงที่แสดงโดย DNS แทนที่จะสันนิษฐานว่าเซิร์ฟเวอร์เว็บไซต์ของผู้รับยอมรับอีเมล หาก DNS ไม่พบ MX record ที่ใช้งานได้ ให้ตรวจสอบการกำหนดค่า DNS หลักสำหรับโดเมนของผู้รับนั้น อย่าเพิ่ม MX record ที่สร้างขึ้นเองบนเซิร์ฟเวอร์ Zimbra ของคุณ

ขั้นตอนต่อไปคือทดสอบการเชื่อมต่อ TCP หากncติดตั้งแล้ว ให้ใช้คำสั่ง:

nc -vz -w 10 mx.example.net 25

หรือใช้telnet mx.example.net 25หากมีให้ใช้งาน การเชื่อมต่อ TCP ที่สำเร็จควรแสดงข้อความแจ้งว่าการเชื่อมต่อสำเร็จ จากนั้นเซิร์ฟเวอร์ SMTP อาจแสดงข้อความทักทาย การหมดเวลาบ่งชี้ว่าการจับมือ TCP ไม่เสร็จสมบูรณ์ ผลลัพธ์ "การเชื่อมต่อถูกปฏิเสธ" นั้นแตกต่างออกไป: โฮสต์ระยะไกลตอบกลับมา แต่ไม่ยอมรับการเชื่อมต่อบนที่อยู่และพอร์ตนั้น

ทำการทดสอบซ้ำกับเป้าหมาย MX แต่ละรายการ และหากทำได้ ให้ทดสอบทั้งเส้นทาง IPv4 และ IPv6 หากชื่อโฮสต์แปลงเป็นที่อยู่ IPv6 ได้ แต่เซิร์ฟเวอร์ไม่มีเส้นทาง IPv6 ที่ใช้งานได้ การพยายามเข้าถึง IPv6 อาจล้มเหลวในขณะที่ IPv4 ทำงานได้ ตรวจสอบเส้นทางและบันทึกก่อนเปลี่ยนการตั้งค่าตระกูลที่อยู่ของ Postfix การเปลี่ยนแปลงใดๆ ควรเป็นไปตามเวอร์ชันและการใช้งานเฉพาะ

3. ไฟร์วอลล์หรือผู้ให้บริการโฮสติ้งปิดกั้นการส่งข้อมูล SMTP ขาออกหรือไม่?

ตรวจสอบนโยบายไฟร์วอลล์ของเซิร์ฟเวอร์โดยไม่ต้องเปลี่ยนแปลงก่อน สำหรับระบบที่ใช้ UFW:

sudo ufw status verbose

UFW สามารถจัดการทั้งทราฟฟิกขาออกและขาเข้าได้ หากนโยบายขาออกเข้มงวด ให้ตรวจสอบกฎที่มีหมายเลขกำกับและยืนยันว่าการเชื่อมต่อ TCP ไปยังพอร์ต 25 ระยะไกลถูกปฏิเสธหรือไม่ เพิ่มกฎอนุญาตขาออกที่มีขอบเขตแคบเฉพาะในกรณีที่ตรงกับนโยบายความปลอดภัยของคุณและเซิร์ฟเวอร์ได้รับอนุญาตให้ส่งอีเมลโดยตรงเท่านั้น

ไฟร์วอลล์ของโฮสต์อาจอนุญาตการเชื่อมต่อ ในขณะที่ไฟร์วอลล์ต้นทาง การควบคุมความปลอดภัยบนคลาวด์ ACL เครือข่าย หรือนโยบายของผู้ให้บริการโฮสติ้งอาจบล็อกไว้ สอบถามผู้ให้บริการว่าอนุญาตให้ใช้ TCP/25 ขาออกสำหรับกรณีนี้หรือไม่ มีข้อจำกัดระดับบัญชีหรือไม่ และมีกระบวนการอนุมัติหรือตรวจสอบหรือไม่ นโยบายจะแตกต่างกันไปตามผู้ให้บริการ บัญชี ภูมิภาค และผลิตภัณฑ์ ดังนั้นการตรวจสอบไฟร์วอลล์ในเครื่องที่สำเร็จไม่ได้หมายความว่าเส้นทางอินเทอร์เน็ตเปิดอยู่เสมอไป

หากคุณควบคุมไฟร์วอลล์เครือข่าย ให้ตรวจสอบกฎขาออกและบันทึกต่างๆ เพื่อหา IP ต้นทางของเซิร์ฟเวอร์ Zimbra, IP ปลายทาง MX, โปรโตคอล TCP และพอร์ตปลายทาง 25 การดักจับแพ็กเก็ตจะช่วยให้ผู้ดูแลระบบที่มีประสบการณ์สามารถแยกแยะแพ็กเก็ต SYN ที่ไม่ได้รับการตอบกลับออกจากแพ็กเก็ตที่ถูกบล็อกในเส้นทางส่งกลับได้ แต่ให้ดักจับเฉพาะส่วนหัวที่เกี่ยวข้องและปกป้องข้อมูลการทำงานใดๆ อย่าเปิดพอร์ตขาเข้า 25 เพื่อแก้ไขปัญหาการหมดเวลาขาออก เนื่องจากเป็นทิศทางการรับส่งข้อมูลที่แยกจากกัน

4. คุณควรทำอย่างไรหากไม่สามารถจัดส่งสินค้าโดยตรงผ่านพอร์ต 25 ได้?

หากผู้ให้บริการไม่อนุญาตให้ส่งอีเมลออกโดยตรงผ่าน SMTP ให้ใช้ smarthost ที่ได้รับอนุญาตหรือรีเลย์ขาออก ขอชื่อโฮสต์รีเลย์ พอร์ต ข้อกำหนด TLS วิธีการตรวจสอบสิทธิ์ โดเมนผู้ส่งที่อนุญาต และข้อกำหนดการอนุญาต IP ใดๆ จากผู้ให้บริการรีเลย์ กำหนดค่ารีเลย์ผ่านวิธีการบริหารจัดการ Zimbra ที่รองรับสำหรับเวอร์ชันของคุณ หรือปฏิบัติตามกระบวนการเปลี่ยนแปลง Zimbra ขององค์กรของคุณ คู่มือผู้ดูแลระบบของ Zimbra ระบุว่าต้องกำหนดค่าโฮสต์รีเลย์เมื่อไม่ได้เปิดใช้งานการส่งอีเมลผ่าน DNS

ผู้ให้บริการหลายรายเสนอการส่งอีเมลแบบยืนยันตัวตนผ่านพอร์ต 587 โดยใช้ STARTTLS แต่เอกสารของรีเลย์นั้นถือเป็นข้อมูลที่เชื่อถือได้ รีเลย์อาจต้องการพอร์ต 465 การอนุญาต IP หรือตัวเชื่อมต่อเฉพาะของผู้ให้บริการแทน อย่าคิดว่าพอร์ต 587 เปิดอยู่เสมอ หรือว่าเซิร์ฟเวอร์ SMTP สาธารณะใดๆ ก็สามารถใช้เป็นรีเลย์ได้ เก็บข้อมูลประจำตัวไว้ในไฟล์การกำหนดค่าที่ได้รับการป้องกัน จำกัดผู้ที่สามารถอ่านได้ และอย่าใส่รหัสผ่านรีเลย์ไว้ในตั๋วสนับสนุนหรือประวัติการใช้งานเชลล์เด็ดขาด

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

คุณควรลองเข้าคิวที่ถูกเลื่อนออกไปอีกครั้งเมื่อใด?

เมื่อแก้ไขสาเหตุหลักแล้ว และการทดสอบโดยตรงไปยังปลายทางหรือรีเลย์สำเร็จ ให้ขอให้ลองส่งข้อความในคิวอีกครั้ง จากบัญชี Zimbra postqueue -fให้ขอให้ Postfix พยายามส่งข้อความที่อยู่ในคิวอีกครั้ง:

su - zimbra
postqueue -f

การดำเนินการนี้อาจทำให้เกิดการพยายามส่งข้อความจำนวนมาก ดังนั้นควรหลีกเลี่ยงการเรียกใช้ซ้ำๆ ในระหว่างที่ระบบขัดข้อง นอกจากนี้ คุณยังสามารถใช้การควบคุมคิวในคอนโซลการดูแลระบบได้หากมีให้ใช้งาน เอกสารของ Zimbra ระบุว่าการล้างคิวจะทำให้เกิดการพยายามส่งข้อความในคิวที่รอการส่ง คิวขาเข้า และคิวที่ใช้งานอยู่ ตรวจสอบข้อความบางส่วนหลังจากนั้นและตรวจสอบว่าจำนวนข้อความที่รอการส่งลดลง และบันทึกแสดงการส่งสำเร็จหรือการตอบกลับ SMTP ใหม่ที่สามารถดำเนินการได้

คู่มือการตัดสินใจฉบับย่อ

คุณจะยืนยันการแก้ไขปัญหาได้อย่างไร?

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

อย่า “แก้ไข” การหมดเวลาโดยการเพิ่มเวลาหมดเวลาการเชื่อมต่อของ Postfix smtp_connect_timeoutการตั้งค่าของ Postfix ควบคุมระยะเวลาที่ไคลเอนต์ SMTP รอเพื่อทำการเชื่อมต่อ TCP ให้เสร็จสมบูรณ์ การขยายเวลาหมดเวลาไม่สามารถทำให้เส้นทางที่ถูกบล็อกใช้งานได้ และอาจทำให้การพยายามส่งรอเป็นเวลานานขึ้น นอกจากนี้ ควรหลีกเลี่ยงการลบข้อความที่อยู่ในคิวหรือการเปลี่ยนแปลงอายุการใช้งานของคิวเพื่อซ่อนอาการ หากข้อความใกล้ถึงอายุการใช้งานที่กำหนดไว้ ให้แจ้งผู้ใช้ที่ได้รับผลกระทบว่าการส่งล่าช้า และเก็บหลักฐานของคิวไว้ในขณะที่กู้คืนเส้นทาง

เอกสารอ้างอิงอย่างเป็นทางการ

• คู่มือผู้ดูแลระบบ Zimbra Daffodil (เวอร์ชัน 10): การไหลของอีเมลและคิว
• คู่มือการติดตั้ง Zimbra Daffodil (v10) สำหรับเซิร์ฟเวอร์เดี่ยว: การแมปพอร์ต
• Postfix postconf(5): smtp_connect_timeout
• เอกสารประกอบการใช้งาน Ubuntu Server: ไฟร์วอลล์และสถานะ UFW