แก้ไขปัญหาการค้างของคิวอีเมลใน Zimbra: ล้างแคช Postfix อย่างปลอดภัยและตรวจสอบการส่งถึงปลายทาง

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

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

1. ตรวจสอบว่าปริมาณงานค้างมีมากแค่ไหน

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

sudo /opt/zimbra/libexec/zmqstat

ขึ้นอยู่กับการตั้งค่า sudo ให้รันคำสั่งจากบัญชี Zimbra หรือใช้วิธีการให้สิทธิ์ที่กำหนดไว้สำหรับเซิร์ฟเวอร์ของคุณ ตัวอย่างสรุปอาจแสดงdeferred=240และactive=3นี่คือจำนวนนับ ไม่ใช่หลักฐานว่าข้อความ 240 ข้อความค้างอยู่ถาวร เปรียบเทียบอีกครั้งหลังจากผ่านไปสองสามนาทีและสังเกตว่าหมวดหมู่ใดเปลี่ยนแปลง

ถัดไป ให้ตรวจสอบรายการคิวแต่ละรายการ การติดตั้งในปัจจุบันส่วนใหญ่ใช้common/sbinพาธนี้ ส่วนการติดตั้งเวอร์ชันเก่าอาจใช้พา ธอื่น postfix/sbinให้ใช้พาธที่ตรงกับที่มีอยู่จริงบนเซิร์ฟเวอร์ของคุณ

/opt/zimbra/common/sbin/postqueue -p

หากไม่มีเส้นทางดังกล่าว ให้ตรวจสอบว่าการติดตั้งของคุณมีหรือ/opt/zimbra/postfix/sbin/postqueueไม่ จากนั้นแทนที่เส้นทางแบบเต็มในคำสั่งด้านล่าง เอกสารของ Zimbra อธิบายทั้งสรุปคิวและpostqueue -pรายการโดยละเอียด รหัสคิวอาจมีเครื่องหมายดอกจันต่อท้ายสำหรับการพยายามส่งที่ใช้งานอยู่ หรือเครื่องหมายอัศเจรีย์สำหรับข้อความที่ถูกพักไว้ดูข้อมูลอ้างอิงคิว Postfix ของ Zimbra

2. ค้นหาสาเหตุที่ข้อความค้างอยู่

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

grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50

ตีความข้อความเหล่านั้นในบริบท การหมดเวลาการเชื่อมต่อซ้ำๆ ไปยังปลายทางเดียวบ่งชี้ถึงปัญหาการเชื่อมต่อหรือเซิร์ฟเวอร์ระยะไกล ข้อผิดพลาดในการแก้ไขชื่อชี้ไปที่ DNS การปฏิเสธชั่วคราวจากระยะไกลหรือข้อจำกัดอัตราอาจต้องรอหรือติดต่อผู้ให้บริการผู้รับ ข้อผิดพลาดในการตรวจสอบสิทธิ์หรือ TLS อาจบ่งชี้ถึงปัญหาการกำหนดค่าในเครื่องstatus=sentรายการที่ขึ้นว่า "มี" หมายความว่าจุดส่งต่อถัดไปรับข้อความแล้ว ไม่ได้หมายความว่าผู้รับได้อ่านข้อความนั้นหรือข้อความนั้นไปถึงกล่องจดหมายเข้าแล้ว

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

3. แก้ไขสาเหตุของปัญหาเสียก่อนที่จะขอให้ Postfix ลองใหม่อีกครั้ง

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

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

เอกสารการแก้ไขปัญหาของ Zimbra ระบุ/var/log/zimbra.logว่าจุดหลักที่ควรตรวจสอบปัญหา MTA คือที่นี่ และแสดงรายการยูทิลิตี้คิว เช่น และpostqueueโครงสร้างzmqstatบริการและตำแหน่งของไฟล์ปฏิบัติการจะขึ้นอยู่กับเวอร์ชัน ดังนั้นโปรดตรวจสอบเอกสารประกอบของเวอร์ชันที่ติดตั้งก่อนที่จะรีสตาร์ทบริการหรือแก้ไขการกำหนดค่าดูเครื่องมือแก้ไขปัญหา MTA ของ Zimbra

4. ล้างคิว Postfix

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

/opt/zimbra/common/sbin/postqueue -f

สำหรับการติดตั้งโดยใช้เส้นทางแบบเก่า ให้ใช้/opt/zimbra/postfix/sbin/postqueue -fแทน เอกสารอ้างอิงคิวของ Zimbra postqueue -fระบุว่าเป็นคำสั่ง flush คำขอจะแจ้งให้ Postfix ลองส่งอีเมลที่อยู่ในคิว ไม่ใช่การลบอีเมล อาจส่งคืนผลลัพธ์โดยไม่มีข้อความแสดงความสำเร็จที่ชัดเจน ดังนั้นให้พิจารณาผลลัพธ์จากจำนวนคิวและบันทึกการส่งในภายหลัง แทนที่จะพิจารณาจากผลลัพธ์สั้นๆ ของคำสั่ง

การล้างแคช (flush) เป็นสิ่งที่เหมาะสมหลังจากเครือข่ายขัดข้องชั่วคราว หรือหลังจากแก้ไขปัญหาการตั้งค่าชั่วคราวแล้ว แต่ไม่น่าจะช่วยได้หาก DNS, การกำหนดเส้นทาง (routing), การส่งต่อข้อมูล (relay), TLS หรือเซิร์ฟเวอร์รับข้อมูลระยะไกลยังคงใช้งานไม่ได้ การทำซ้ำคำสั่งอย่างรวดเร็วอาจทำให้เกิดสัญญาณรบกวนและเพิ่มปริมาณการรับส่งข้อมูลโดยไม่ได้แก้ไขปัญหา

5. ตรวจสอบผลลัพธ์และเลือกขั้นตอนต่อไป

หลังจากเว้นช่วงเวลาสั้นๆ เพื่อรอการลองส่งอีกครั้ง ให้ทำการสรุปคิวอีกครั้งและตรวจสอบรายการบันทึกที่เพิ่งผ่านเข้ามา:

sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.log

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

• หากจำนวนงานค้างลดลงและบันทึกการส่งมอบแสดงว่าได้รับการยอมรับแล้ว ให้ติดตามต่อไปจนกว่างานค้างจะกลับสู่ระดับปกติ
• หากข้อความเดิมปรากฏขึ้นอีกครั้ง:ให้ปฏิบัติตามข้อความแสดงข้อผิดพลาดที่ปรากฏซ้ำ และแก้ไขปัญหาที่เกี่ยวข้องกับ DNS, เครือข่าย, TLS, รีเลย์ หรือฝั่งผู้รับ
• หากจำนวนอีเมลยังคงเพิ่มขึ้นเรื่อยๆให้ตรวจสอบว่ามีการส่งอีเมลวนซ้ำ ส่งอีเมลจำนวนมาก หรือบัญชีถูกบุกรุกหรือไม่ และทำการบล็อกอีเมลที่ไม่พึงประสงค์ก่อนที่จะลองส่งใหม่อีกครั้ง
• หากยังคงมีการนับจำนวนที่ถูกระงับหรือผิดพลาดอยู่ให้ตรวจสอบข้อความเหล่านั้นแยกต่างหาก การล้างแคชทั่วไปไม่ใช่การดำเนินการเพื่อล้างข้อมูลในหมวดหมู่เหล่านั้น

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

การล้างระบบที่ประสบความสำเร็จสามารถบอกอะไรคุณได้บ้าง และบอกอะไรคุณไม่ได้บ้าง

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

ณ วันที่ 6 ตุลาคม 2569 เอกสารใน Zimbra Tech Center ที่อ้างถึงได้บันทึกคำสั่งคิวและคำสั่งแก้ไขปัญหาที่ใช้ในที่นี้ แต่ไม่ได้ให้แนวทางที่รับประกันได้ว่าจะใช้ได้กับ Zimbra ทุกเวอร์ชัน โปรดตรวจสอบตำแหน่งของไฟล์ไบนารีและพฤติกรรมของสิทธิ์บนเซิร์ฟเวอร์ของคุณเองก่อนที่จะเรียกใช้คำสั่ง โดยเฉพาะอย่างยิ่งในระบบเก่าหรือระบบที่ปรับแต่งเอง