วางแผนเก็บและจัดเก็บอีเมลย้อนหลังขององค์กร

องค์กรจำนวนมากไม่มีนโยบายเรื่องอีเมลย้อนหลังที่ชัดเจน จนกระทั่งเกิดเหตุการณ์ที่ต้องใช้ เช่น ข้อพิพาททางธุรกิจที่ต้องยืนยันว่าเคยตกลงอะไรไว้ หรือพนักงานลาออกแล้วอีเมลของลูกค้าที่เขาดูแลหายไปทั้งหมด

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

ความต่างที่ต้องเข้าใจก่อน

การสำรองข้อมูล

มีไว้กู้คืนเมื่อระบบเสียหาย ตอบคำถามว่า "ทำอย่างไรให้ระบบกลับมาเหมือนเมื่อวาน" เก็บระยะสั้น เช่น 30 วัน และไม่ได้ออกแบบมาให้ค้นหารายฉบับ

การจัดเก็บ

มีไว้ค้นหาย้อนหลังและตอบข้อกำหนด ตอบคำถามว่า "อีเมลที่คุยกับลูกค้ารายนี้เมื่อสามปีก่อนว่าอย่างไร" เก็บระยะยาว เช่น 5-10 ปี และต้องค้นหาได้

ข้อมูลสำรองใช้แทนการจัดเก็บไม่ได้ เพราะเมื่อผู้ใช้ลบอีเมลแล้ว รอบสำรองถัดไปก็ไม่มีอีเมลนั้นอีก การจัดเก็บที่ถูกต้องต้องเก็บตั้งแต่ตอนที่อีเมลผ่านระบบ ก่อนที่ผู้ใช้จะมีโอกาสลบ

ขั้นตอนที่ 1: กำหนดนโยบายก่อนลงมือทางเทคนิค

ตอบคำถามเหล่านี้ร่วมกับฝ่ายกฎหมายและผู้บริหาร

• ต้องเก็บนานแค่ไหน แยกตามประเภทหรือไม่
• ใครมีสิทธิ์ค้นหาย้อนหลัง และต้องผ่านการอนุมัติจากใคร
• จะจัดการกับข้อมูลส่วนบุคคลใน อีเมลอย่างไรให้สอดคล้องกับ PDPA
• เมื่อพ้นระยะเวลาแล้วจะลบหรือเก็บต่อ

ข้อควรระวังด้าน PDPA การเก็บอีเมลไว้นานกว่าที่จำเป็นโดยไม่มีฐานทางกฎหมายรองรับเป็นความเสี่ยงในตัวมันเอง นโยบายที่ดีต้องระบุทั้งระยะเวลาเก็บและการลบเมื่อพ้นกำหนด

ระยะเวลาที่ใช้กันทั่วไปในองค์กรไทย

• อีเมลทั่วไป 3-5 ปี
• อีเมลที่เกี่ยวกับสัญญาและการเงิน 10 ปี ตามอายุความ
• อีเมลของฝ่ายบุคคล ตามกฎหมายแรงงานที่เกี่ยวข้อง

ปรึกษาที่ปรึกษากฎหมายขององค์กรเพื่อกำหนดตัวเลขที่เหมาะกับธุรกิจของคุณ

ขั้นตอนที่ 2: ตั้งการเก็บสำเนาทุกฉบับที่ผ่านระบบ

วิธีที่ถูกต้องคือทำสำเนาตั้งแต่ตอนที่อีเมลเข้าและออกจากเซิร์ฟเวอร์ ซึ่งเรียกว่า journaling

บน Postfix ตั้งด้วย always_bcc

sudo postconf -e 'always_bcc = [email protected]'
sudo systemctl reload postfix
sudo postconf always_bcc

อีเมลทุกฉบับทั้งขาเข้าและขาออกจะถูกสำเนาไปยังบัญชีนั้น

ข้อควรระวังสำคัญ บัญชีปลายทางต้องอยู่คนละโดเมนหรือตั้งค่าไม่ให้ always_bcc ทำงานซ้ำกับตัวเอง ไม่เช่นนั้นจะเกิดการวนซ้ำไม่รู้จบ

ต้องแจ้งพนักงานให้ทราบว่ามีการเก็บสำเนา ซึ่งเป็นทั้งข้อกำหนดทางกฎหมายและเรื่องความโปร่งใส

ขั้นตอนที่ 3: แยกที่เก็บออกจากระบบอีเมลหลัก

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

#!/bin/bash
# ย้ายอีเมลจากบัญชีรวมไปเก็บแบบแยกตามเดือน
set -euo pipefail

[email protected]
DEST=/srv/mail-archive
MONTH=$(date -d 'last month' +%Y-%m)

mkdir -p "$DEST/$MONTH"

doveadm fetch -u "$SRC" text \
  mailbox INBOX savedbefore "$(date -d 'last month' +%Y-%m-01)" \
  > "$DEST/$MONTH/archive.mbox"

gzip -9 "$DEST/$MONTH/archive.mbox"

# ตั้งสิทธิ์อ่านอย่างเดียว
chmod 440 "$DEST/$MONTH/archive.mbox.gz"
chown root:archive "$DEST/$MONTH/archive.mbox.gz"

# ลบออกจากบัญชีรวมหลังย้ายแล้ว
doveadm expunge -u "$SRC" mailbox INBOX savedbefore "$(date -d 'last month' +%Y-%m-01)"

echo "จัดเก็บเดือน $MONTH เสร็จ ขนาด $(du -h "$DEST/$MONTH/archive.mbox.gz" | cut -f1)"

ส่งสำเนาออกไปเก็บนอกสถานที่ด้วย เพื่อให้รอดแม้ศูนย์ข้อมูลเสียหาย

restic backup /srv/mail-archive --tag mail-archive

ขั้นตอนที่ 4: ทำให้ค้นหาได้

ไฟล์ mbox ที่บีบอัดไว้ค้นหายาก สำหรับองค์กรที่ต้องค้นบ่อย ควรมีระบบดัชนี

ทางเลือกที่ทำได้จริง

• เก็บไว้ในบัญชี IMAP เฉพาะ แล้วใช้ความสามารถค้นหาของ Dovecot ซึ่งง่ายที่สุดและใช้ได้ทันที
• ใช้ระบบจัดเก็บอีเมลโดยเฉพาะ เช่น MailPiler ซึ่งมีหน้าจอค้นหาและควบคุมสิทธิ์ในตัว
• ส่งเข้า OpenSearch สำหรับองค์กรที่มีระบบค้นหาอยู่แล้ว

ค้นหาด้วย doveadm สำหรับกรณีที่เก็บไว้ในบัญชี IMAP

# ค้นหาตามผู้ส่ง
sudo doveadm search -u [email protected] FROM '[email protected]'

# ค้นหาตามคำในหัวข้อและช่วงเวลา
sudo doveadm search -u [email protected] \
  SUBJECT 'สัญญา' SINCE 2024-01-01 BEFORE 2025-01-01

# ดึงอีเมลที่พบออกมา
sudo doveadm fetch -u [email protected] 'hdr.subject hdr.from hdr.date' \
  FROM '[email protected]' | head -40

ขั้นตอนที่ 5: จัดการเมื่อพนักงานลาออก

นี่คือกรณีที่เกิดบ่อยที่สุดและมักจัดการไม่ดี ขั้นตอนที่ควรทำ

1. อย่าลบบัญชีทันที ให้ระงับการล็อกอินแทน
2. ตั้งการส่งต่ออีเมลไปยังผู้รับช่วงงาน
3. ตั้งข้อความตอบกลับอัตโนมัติแจ้งผู้ติดต่อ
4. ส่งออกกล่องจดหมายเก็บไว้ตามนโยบาย
5. เมื่อครบระยะเวลาที่กำหนด เช่น 6-12 เดือน จึงลบบัญชี

# ระงับการล็อกอินแต่ยังรับอีเมลได้
sudo doveadm user [email protected]
# ตั้งใน DirectAdmin หรือ Plesk ที่หน้าจัดการอีเมล

# ส่งออกกล่องจดหมายทั้งหมด
sudo doveadm fetch -u [email protected] text mailbox '*' \
  | gzip > /srv/mail-archive/staff/leaving-$(date +%F).mbox.gz

# ตั้งส่งต่อ
echo '[email protected]: [email protected]' >> /etc/postfix/virtual
sudo postmap /etc/postfix/virtual && sudo systemctl reload postfix

ขั้นตอนที่ 6: ควบคุมสิทธิ์การเข้าถึง

ข้อมูลที่จัดเก็บไว้มีอีเมลของทุกคนในองค์กร จึงต้องควบคุมเข้มกว่าระบบอีเมลปกติ

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

# บันทึกการเข้าถึง
sudo nano /etc/rsyslog.d/50-archive-access.conf

:programname, isequal, "doveadm" /var/log/archive-access.log
& stop

ขั้นตอนที่ 7: ลบเมื่อพ้นกำหนด

การเก็บตลอดไปไม่ใช่นโยบายที่ดี ทั้งเรื่องต้นทุนและความเสี่ยงทางกฎหมาย

#!/bin/bash
# ลบข้อมูลที่เก็บเกินกำหนด
YEARS=5
DEST=/srv/mail-archive
CUTOFF=$(date -d "$YEARS years ago" +%Y-%m)

find "$DEST" -maxdepth 1 -type d -name '20*' | while read -r d; do
  m=$(basename "$d")
  if [[ "$m" < "$CUTOFF" ]]; then
    echo "จะลบ $d (เก่ากว่า $CUTOFF)"
    # ลบจริงเมื่อยืนยันแล้ว
    # rm -rf "$d"
  fi
done

ทำการลบเป็นกระบวนการที่มีการอนุมัติ ไม่ใช่สคริปต์ที่รันเองโดยไม่มีใครตรวจ และบันทึกไว้เป็นหลักฐานว่าลบอะไรไปเมื่อไร

ขั้นตอนที่ 8: ทดสอบว่าระบบใช้งานได้จริง

ทดสอบทุกไตรมาสด้วยสถานการณ์จำลอง

• ค้นหาอีเมลจากลูกค้ารายหนึ่งในช่วงเวลาที่กำหนด
• กู้กล่องจดหมายของพนักงานที่ลาออกไปแล้ว
• ตรวจว่าข้อมูลที่ควรถูกลบตามนโยบายถูกลบจริง

จับเวลาและบันทึกผล ระบบจัดเก็บที่ค้นหาไม่ได้ในเวลาที่ยอมรับได้เท่ากับไม่มีระบบ

ปัญหาที่พบบ่อย

พื้นที่จัดเก็บโตเร็วเกินคาด

ไฟล์แนบคือส่วนใหญ่ของขนาด พิจารณาแยกเก็บไฟล์แนบและเก็บเฉพาะตัวอ้างอิงในอีเมล หรือบีบอัดข้อมูลเก่าด้วยอัตราสูงขึ้น

du -sh /srv/mail-archive/* | sort -h | tail

always_bcc ทำให้เกิดการวนซ้ำ

บัญชีปลายทางอยู่ในโดเมนที่ถูก bcc เอง แยกไปคนละโดเมนหรือใช้ sender_bcc_maps กับ recipient_bcc_maps ที่ควบคุมได้ละเอียดกว่า

ค้นหาช้ามากเมื่อข้อมูลเยอะ

เปิดการทำดัชนีข้อความเต็มของ Dovecot หรือย้ายไปใช้ระบบจัดเก็บที่มีดัชนีโดยเฉพาะ

ไม่แน่ใจว่านโยบายถูกต้องตามกฎหมายหรือไม่

เอกสารนี้อธิบายวิธีทางเทคนิค ไม่ใช่คำแนะนำทางกฎหมาย ให้ที่ปรึกษากฎหมายขององค์กรตรวจสอบนโยบายก่อนนำไปใช้จริง

ต้องการวางระบบจัดเก็บอีเมลขององค์กรบนคลาวด์ในประเทศไทย ติดต่อ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/