Trong điều kiện bị ảnh hưởng, kẻ tấn công từ Internet có thể gửi SMTP request được tạo đặc biệt và khiến máy chủ thực thi lệnh hệ điều hành dưới quyền user zimbra mà không cần tài khoản đăng nhập Zimbra hợp lệ.

Theo thông tin công bố, các máy chủ sử dụng phiên bản Zimbra trước 10.1.20, có cài đặt zimbra-snmp và bật SNMP notification cần được ưu tiên kiểm tra.

Zimbra đã phát hành bản vá trong phiên bản ZCS 10.1.20.

CVE-2026-73570 cũng đã được đưa vào danh mục Known Exploited Vulnerabilities – KEV của CISA, cho thấy lỗ hổng đã được ghi nhận khai thác thực tế.

Lưu ý: Bài viết tập trung vào việc kiểm tra, phát hiện dấu hiệu compromise và xử lý phòng thủ. Không bao gồm mã khai thác hoặc payload tấn công.

1. CVE-2026-73570 là gì?

CVE-2026-73570 thuộc nhóm lỗi:

CWE-78 – OS Command Injection

Lỗ hổng liên quan đến quá trình xử lý SNMP notification của Zimbra.

Dữ liệu không tin cậy có thể được xử lý không an toàn trước khi được chuyển tới cơ chế thực thi command, từ đó dẫn tới khả năng OS Command Injection.

Có thể hình dung chuỗi tấn công như sau:

Internet
    ↓
SMTP request được tạo đặc biệt
    ↓
Zimbra SMTP
    ↓
SNMP Notification
    ↓
OS Command Injection
    ↓
Thực thi command dưới user zimbra
    ↓
Payload / Persistence / Malware

Điểm nguy hiểm là attacker có thể khai thác từ xa mà không cần có mailbox hoặc tài khoản Zimbra hợp lệ.

Quyền thực thi ban đầu là user:

zimbra

không phải root.

Tuy nhiên đây vẫn là mức ảnh hưởng nghiêm trọng bởi user zimbra có quyền truy cập và vận hành nhiều thành phần quan trọng của hệ thống mail.

2. Máy chủ Zimbra nào có nguy cơ?

Nên ưu tiên kiểm tra nếu server đáp ứng các điều kiện:

• Đang chạy Zimbra Collaboration Suite.
• Phiên bản thấp hơn 10.1.20.
• Có package zimbra-snmp.
• SNMP notification đang được bật.
• SMTP server được public ra Internet.

3. Kiểm tra phiên bản Zimbra

Đăng nhập SSH vào server và chạy:

su - zimbra -c 'zmcontrol -v'

Hoặc:

su - zimbra
zmcontrol -v

Ví dụ:

Release 10.1.19.GA...

Nếu phiên bản thấp hơn:

10.1.20

thì nên tiếp tục kiểm tra SNMP và các dấu hiệu compromise.

4. Kiểm tra package SNMP

Với Ubuntu/Debian:

dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'

Với hệ điều hành sử dụng RPM:

rpm -qa | grep -E 'zimbra-snmp|zimbra-net-snmp'

Nếu server có package liên quan đến SNMP, tiếp tục kiểm tra service.

su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep -i snmp'

Nếu xuất hiện:

zimbraServiceEnabled: snmp

nghĩa là SNMP service đang được enable trên server.

5. Kiểm tra SNMP notification

Chạy:

su - zimbra -c 'zmlocalconfig snmp_notify'

Nếu kết quả:

snmp_notify = yes

thì SNMP notification đang được bật.

Trong trường hợp máy chủ đồng thời đang chạy phiên bản vulnerable, cần ưu tiên cập nhật bản vá.

6. Kiểm tra trạng thái dịch vụ Zimbra

Trước khi thực hiện thay đổi, nên lưu lại trạng thái hiện tại:

su - zimbra -c 'zmcontrol status'

Ví dụ:

Host mail.example.com
    amavis                  Running
    antispam                Running
    antivirus               Running
    ldap                    Running
    logger                  Running
    mailbox                 Running
    memcached               Running
    mta                     Running
    proxy                   Running
    snmp                    Running
    stats                   Running

Một điểm cần lưu ý:

Tất cả service đang Running không có nghĩa server chắc chắn chưa bị compromise.

Malware vẫn có thể hoạt động dưới user zimbra trong khi Zimbra hoạt động bình thường.

7. Kiểm tra dấu hiệu máy chủ đã bị khai thác

Server thuộc phiên bản vulnerable không đồng nghĩa chắc chắn đã bị hack.

Cần kiểm tra thêm các dấu hiệu bất thường.

7.1. Kiểm tra /dev/shm

Chạy:

ls -lah /dev/shm

Liệt kê chi tiết file:

find /dev/shm -maxdepth 1 -type f \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %p\n' | sort

/dev/shm là vùng shared memory dạng tmpfs.

Malware có thể sử dụng vị trí này để:

• Lưu binary tạm thời.
• Chạy payload.
• Tạo file persistence.
• Lưu script tải malware.

Tuy nhiên:

Không được kết luận file là malware chỉ vì file nằm trong /dev/shm.

Cần kiểm tra thêm:

• Owner.
• Process đang sử dụng.
• Hash.
• Thời gian tạo.
• Nội dung file.

7.2. Kiểm tra cron của user zimbra

Chạy:

crontab -l -u zimbra

Đặc biệt chú ý cron gọi file từ:

/dev/shm
/tmp
/var/tmp

Ví dụ dạng đáng nghi:

* * * * * /dev/shm/<random-file>

Nếu một file lạ được chạy mỗi phút, đây là dấu hiệu cần điều tra.

Backup cron trước khi thay đổi:

crontab -l -u zimbra \
> /root/zimbra-crontab-$(date +%F-%H%M%S).txt 2>&1

7.3. Kiểm tra process của user zimbra

Chạy:

ps -fu zimbra

Hoặc:

ps auxf | grep '[z]imbra'

Có thể kiểm tra executable thực tế:

for pid in $(pgrep -u zimbra); do
    echo "===== PID $pid ====="
    readlink -f /proc/$pid/exe 2>/dev/null
    tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null
    echo
done

Nếu process thuộc user zimbra đang chạy binary từ:

/dev/shm/
/tmp/
/var/tmp/

thì cần ưu tiên kiểm tra.

7.4. Kiểm tra kết nối mạng

Chạy:

ss -tunap

Hoặc:

lsof -nP -i -a -u zimbra

Cần lưu ý các outbound connection:

• Tới IP Internet không rõ nguồn gốc.
• Connection được duy trì liên tục.
• Port bất thường.
• Process không thuộc thành phần Zimbra quen thuộc.

7.5. Kiểm tra file mới được tạo bởi user zimbra

Có thể kiểm tra:

find /tmp /var/tmp /dev/shm \
-user zimbra -type f -mtime -30 -ls 2>/dev/null

Lệnh trên tìm các file thuộc user zimbra được thay đổi trong vòng 30 ngày gần nhất.

Không nên chạy:

find /

trên production server lớn nếu không cần thiết vì có thể tạo thêm I/O cho hệ thống.

8. Vì sao chỉ xóa file malware là chưa đủ?

Giả sử phát hiện file:

/dev/shm/<malware>

và chỉ thực hiện:

rm -f /dev/shm/<malware>

thì chưa thể kết luận server đã sạch.

File có thể được tạo lại bởi:

• Process vẫn đang chạy trong RAM.
• Cron persistence.
• Systemd timer.
• Systemd service.
• Webshell.
• Script khác.
• Máy chủ tiếp tục bị khai thác do chưa vá.

Quy trình đúng nên theo hướng:

Containment
      ↓
Thu thập evidence
      ↓
Xác định persistence
      ↓
Dừng malicious process
      ↓
Quarantine malware
      ↓
Patch Zimbra
      ↓
Kiểm tra lại hệ thống

9. Quy trình xử lý khi nghi ngờ server đã bị compromise

Đối với server production, không nên xóa file ngay khi phát hiện dấu hiệu bất thường.

Nên thu thập evidence trước.

Bước 1: Tạo thư mục lưu thông tin incident

TS=$(date +%Y%m%d_%H%M%S)
INC="/root/zimbra-incident-$TS"

mkdir -p "$INC"

Bước 2: Lưu danh sách process

ps auxf > "$INC/process.txt"

Bước 3: Lưu kết nối mạng

ss -tunap > "$INC/network.txt"

Bước 4: Lưu cron của user zimbra

crontab -l -u zimbra \
> "$INC/zimbra-crontab.txt" 2>&1

Bước 5: Lưu thông tin /dev/shm

ls -lah /dev/shm \
> "$INC/dev-shm.txt"

Bước 6: Lưu trạng thái Zimbra

su - zimbra -c 'zmcontrol status' \
> "$INC/zmcontrol-status.txt" 2>&1

Lưu version:

su - zimbra -c 'zmcontrol -v' \
> "$INC/zimbra-version.txt" 2>&1

10. Tạm thời tắt SNMP notification

Nếu chưa thể patch ngay, có thể cân nhắc disable SNMP notification để giảm vector tấn công.

Kiểm tra:

su - zimbra -c 'zmlocalconfig snmp_notify'

Tắt:

su - zimbra -c 'zmlocalconfig -e snmp_notify=no'

Kiểm tra lại:

su - zimbra -c 'zmlocalconfig snmp_notify'

Kết quả:

snmp_notify = no

Đây chỉ là giải pháp containment tạm thời.

Giải pháp chính vẫn là upgrade Zimbra lên phiên bản đã vá.

Nếu doanh nghiệp đang sử dụng SNMP để giám sát hệ thống thì cần lưu ý việc tắt SNMP notification có thể ảnh hưởng monitoring.

11. Xác định process sử dụng file nghi ngờ

Ví dụ:

lsof /dev/shm/<suspicious-file>

Hoặc:

fuser -v /dev/shm/<suspicious-file>

Kiểm tra hash:

sha256sum /dev/shm/<suspicious-file>

Kiểm tra metadata:

stat /dev/shm/<suspicious-file>

Nếu đã xác định process độc:

kill <PID>

Nếu process không dừng:

kill -9 <PID>

Không nên sử dụng pkill với pattern quá rộng vì có thể kill nhầm process Zimbra hợp lệ.

12. Kiểm tra persistence

Ngoài cron của user zimbra, cần kiểm tra thêm.

Systemd timer

systemctl list-timers --all

Systemd service

systemctl list-unit-files --type=service

Cron hệ thống

find /etc/cron* -type f -mtime -30 -ls 2>/dev/null

Cron spool

find /var/spool/cron -type f -mtime -30 -ls 2>/dev/null

Không xóa entry chỉ vì thấy lạ.

Cần xác minh xem entry có thuộc hệ thống hoặc phần mềm hợp lệ hay không.

13. Quarantine malware thay vì xóa ngay

Tạo thư mục quarantine:

QUA="/root/zimbra-quarantine-$(date +%Y%m%d_%H%M%S)"
mkdir -p "$QUA"

Copy evidence:

cp -a /dev/shm/<suspicious-file> "$INC/"

Di chuyển malware:

mv /dev/shm/<suspicious-file> "$QUA/"

Tính SHA256:

sha256sum "$QUA"/* \
> "$QUA/sha256.txt" 2>/dev/null

Sau đó có thể hạn chế quyền:

chmod -R 000 "$QUA"

Việc giữ lại hash và file giúp phục vụ:

• Điều tra incident.
• Đối chiếu IOC.
• Kiểm tra bằng antivirus.
• So sánh với các server khác.

14. Kiểm tra JSP/Webshell

Sau khi attacker có khả năng chạy command dưới user zimbra, không nên giả định /dev/shm là persistence duy nhất.

Một vị trí cần kiểm tra là Jetty webapps.

find /opt/zimbra/jetty/webapps \
     /opt/zimbra/jetty_base/webapps \
-type f \( -iname '*.jsp' -o -iname '*.jspx' \) \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %s %p\n' \
2>/dev/null | sort

Kiểm tra file được thay đổi gần đây:

find /opt/zimbra/jetty/webapps \
     /opt/zimbra/jetty_base/webapps \
-type f \( -iname '*.jsp' -o -iname '*.jspx' \) \
-mtime -30 -ls 2>/dev/null

Cần lưu ý:

File JSP mới không mặc định là webshell.

File có thể thuộc:

• Zimbra patch.
• Zimlet.
• Customization.
• Web application hợp lệ.

Cần kiểm tra nội dung, package, owner và hash trước khi xử lý.

15. Kiểm tra SSH persistence

Kiểm tra user hệ thống:

awk -F: '$3 >= 1000 {print $1,$3,$6,$7}' /etc/passwd

Kiểm tra SSH authorized keys:

find /root /home /opt/zimbra \
-name authorized_keys -type f \
-print -exec cat {} \; 2>/dev/null

Nếu phát hiện key lạ, cần đối chiếu với key quản trị hợp lệ trước khi xóa.

16. Upgrade Zimbra để vá CVE-2026-73570

Zimbra đã sửa lỗi liên quan trong:

Zimbra Collaboration 10.1.20

Nếu đang sử dụng phiên bản vulnerable, nên nâng lên:

10.1.20

hoặc phiên bản mới hơn đang được Zimbra hỗ trợ.

Trước khi upgrade nên:

• Backup mailbox.
• Backup database.
• Backup configuration.
• Kiểm tra dung lượng ổ đĩa.
• Kiểm tra repository.
• Đọc release notes.
• Xác nhận OS tương thích.
• Chuẩn bị phương án rollback.

Sau khi update:

su - zimbra -c 'zmcontrol -v'

Tiếp tục kiểm tra service:

su - zimbra -c 'zmcontrol status'

17. Kiểm tra sau khi xử lý

Kiểm tra /dev/shm

ls -lah /dev/shm

Kiểm tra cron

crontab -l -u zimbra

Kiểm tra process

ps -fu zimbra

Kiểm tra network

ss -tunap

Kiểm tra dịch vụ

su - zimbra -c 'zmcontrol status'

Kiểm tra version

su - zimbra -c 'zmcontrol -v'

Kiểm tra mail queue

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

Nếu malware hoặc file bất thường tiếp tục xuất hiện lại sau khi đã xóa thì rất có thể:

persistence vẫn còn

hoặc:

vector khai thác chưa được xử lý triệt để

18. Có mất dữ liệu email khi xử lý không?

Các thao tác:

• Disable SNMP notification.
• Dừng malicious process.
• Xóa persistence.
• Quarantine malware.
• Upgrade Zimbra.

không trực tiếp xóa mailbox.

Dữ liệu email Zimbra thường nằm tại:

/opt/zimbra/store/

Database nằm tại:

/opt/zimbra/db/data/

Do đó tuyệt đối không tự ý:

xóa
move
chỉnh sửa

các thư mục trên nếu chưa xác định database hoặc mailbox thực sự gặp sự cố.

19. Không recovery MySQL nếu database vẫn bình thường

CVE-2026-73570 là lỗi OS Command Injection.

Nó không đồng nghĩa database Zimbra chắc chắn đã bị lỗi.

Kiểm tra:

su - zimbra -c 'zmcontrol status'

Kiểm tra MySQL:

su - zimbra -c 'mysql.server status'

Kiểm tra port:

ss -ltnp | grep 7306

Kiểm tra log:

tail -n 200 /opt/zimbra/log/mysql_error.log

Nếu kết quả vẫn:

mysql is running
mailbox Running

và log không ghi nhận corruption hoặc lỗi database nghiêm trọng thì không nên thực hiện MySQL recovery.

Database recovery là một quy trình riêng và có rủi ro lớn hơn malware cleanup.

20. Những việc nên làm sau incident

Sau khi hoàn tất xử lý, nên tiếp tục:

1. Theo dõi CPU và Load Average.
2. Theo dõi /dev/shm.
3. Theo dõi cron user zimbra.
4. Kiểm tra outbound connection.
5. Kiểm tra mail queue.
6. Kiểm tra JSP/webshell.
7. Kiểm tra SSH key.
8. Kiểm tra systemd timer/service.
9. Kiểm tra file mới tạo bởi user zimbra.
10. Rotate credential nếu nghi ngờ bị lộ.
11. Đối chiếu IOC với các Zimbra server khác.
12. Kiểm tra log SMTP tại thời điểm nghi ngờ compromise.
13. Đảm bảo server đang chạy phiên bản Zimbra đã được vá.

21. CISA đã ghi nhận khai thác thực tế

CVE-2026-73570 đã được đưa vào danh mục:

Known Exploited Vulnerabilities – KEV

của CISA.

Điều đó có nghĩa đây không chỉ là một lỗ hổng tồn tại trên lý thuyết mà đã có bằng chứng được sử dụng trong các cuộc tấn công thực tế.

Vì vậy, đối với Zimbra server public ra Internet, việc kiểm tra và patch cần được ưu tiên.

Một điểm rất quan trọng:

zmcontrol status

có thể vẫn hiển thị:

mailbox Running
mta Running
proxy Running

trong khi process malware vẫn đang chạy dưới user zimbra.

Do đó không thể chỉ dựa vào việc dịch vụ đang Running để kết luận server an toàn.

22. Tóm tắt quy trình

1. Kiểm tra version Zimbra
        ↓
2. Kiểm tra package/config SNMP
        ↓
3. Kiểm tra /dev/shm
        ↓
4. Kiểm tra cron
        ↓
5. Kiểm tra process
        ↓
6. Kiểm tra network
        ↓
7. Thu thập evidence
        ↓
8. Disable SNMP notification tạm thời
        ↓
9. Dừng malicious process
        ↓
10. Loại bỏ persistence
        ↓
11. Quarantine malware
        ↓
12. Hunt JSP/Webshell/SSH persistence
        ↓
13. Upgrade Zimbra >= 10.1.20
        ↓
14. Kiểm tra service + mail queue
        ↓
15. Theo dõi dấu hiệu tái nhiễm

Kết luận

CVE-2026-73570 là lỗ hổng nghiêm trọng trong Zimbra Collaboration Suite liên quan đến SNMP notification.

Trong điều kiện vulnerable, attacker từ xa chưa xác thực có thể lợi dụng SMTP request được tạo đặc biệt để thực thi OS command dưới quyền user zimbra.

Các điều kiện cần đặc biệt lưu ý:

Zimbra < 10.1.20
+
zimbra-snmp
+
SNMP notification được bật

Nếu phát hiện server có dấu hiệu compromise, không nên chỉ:

rm malware

rồi kết luận hệ thống đã an toàn.

Quy trình đầy đủ cần bao gồm:

Containment
+
Evidence Collection
+
Process Analysis
+
Persistence Removal
+
Malware Quarantine
+
Patch
+
Verification

Quan trọng nhất vẫn là nâng cấp Zimbra lên phiên bản đã được vá và tiếp tục theo dõi server sau khi xử lý.

Nguồn tham khảo

• NIST National Vulnerability Database – CVE-2026-73570
• Zimbra Security Advisories
• Zimbra Collaboration 10.1.20 Release Notes
• CISA Known Exploited Vulnerabilities Catalog
• CERT Polska

Bài viết CVE-2026-73570: Lỗ hổng Zimbra SNMP RCE – Cách kiểm tra và xử lý đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Bước 1: ghi nhớ thông tin:

Tên miền của bạn sẽ có dạng abc.com (thay bằng tên miền thật sự của bạn) và email là user@abc.com (thay bằng email thật sự của bạn), phần lớn các cấu hình email sẽ như nhau nên bạn sẽ cần ghi nhớ các thông tin như sau:
Email: user@abc.com
Username: user
domain: mail.abc.com
password: Password của bạn
Port SMTP: 465
Port POP3: 995

Bước 2: Cấu hình hộp thư gửi đi

Bạn vào phần cài đặt của gmail để cấu hình

Sau đó bạn truy cập và cấu hình theo hình dưới để vào phần cài đặt và cấu hình email gửi đi là email server

Sau đó bạn sẽ nhận được yêu cầu xác nhận, bạn truy cập mail.abc.com (thay bằng tên miền thật sự của bạn) hoặc webmail.abc.com

Sau khi xác minh xong bạn sẽ thấy tuỳ chọn đặt email của bạn làm mặc định và bạn đã có thể gửi email bình thường

Bước 3: Cấu hình nhận email đến bằng gmail:

Trong phần tài khoản và nhập, có phần kiểm tra thư từ tài khoản khác, bạn bấm vào phần thêm tài khoản thư:

Sau đó bạn làm từng bước giống hướng dẫn dưới đây:

Sau khi nhập đủ thông tin và bấm thêm tài khoản, email của bạn sẽ được chuyển về gmail và sẽ được gắn nhãn riêng như dưới đây

Chúc bạn thành công.

Bài viết Cấu hình email tên miền với gmail đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Mail Server là hệ thống máy chủ mail được cấu hình riêng theo tên miền của doanh nghiệp, có đầy đủ thông số như một máy chủ thông thường như CPU, RAM, Storage,…

Cấu hình Email trên iphone để đồng bộ với macbook

Bước 1: Vào phần cài đặt trên iphone

Bước 2: Chọn phần Ứng dụng, với nhưng máy sử dụng ios từ 16 trở xuống có thể bỏ qua bước này.

Bước 3: Chọn vào ứng dụng mail

Bước 4: Chọn “các tài khoản mail”

Bước 5: Chọn thêm tài khoản

Bước 6: Chọn Khác

Bước 7: Chọn Thêm tài khoản mail

Bước 8: Nhập thông tin và bấm tiếp

Bước 9: Nhập đầy đủ thông tin như hướng dẫn trong ảnh, sau đó bấm tiếp và đợi đăng nhập

Bước 10: Lưu

Bước 11: Quay lại màn hình chính, truy cập ứng dụng mail để kiểm tra.

Khi đăng nhập bằng ứng dụng mail trên, nếu macbook của bạn cùng dùng chung tài khoản icolud với iphone thì email sẽ tự đồng bộ sang mà không cần đăng nhập lại.

Bài viết Hướng dẫn đăng nhập email server tenten trên iphone để đồng bộ cùng macbook đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Cách tạo group và soạn Outlook Group Email

Mở Outlook và nhấn People (Mọi người) ở phía dưới bên trái.

Click New Contact (Liên hệ mới), chọn Contact Group (Nhóm liên hệ).

Đặt tên nhóm và nhấn nút Add Members (Thêm người nhận).

Nếu bạn muốn thêm members từ danh bạ Outlook, bạn nhấn đúp chuột vào tên của họ. Sau khi hoàn tất chọn OK.

Thêm thành viên mới theo cách thủ công: nhập họ tên và địa chỉ email của họ và hộp thoại hiện lên.

Cuối cùng, chọn Save & Close để lưu thao tác.

Cách soạn Group Email Outlook

Khi đã lập nhóm xong, bạn có thể gửi mail cho các thành viên:

Soạn thư trực tiếp:

• Chọn New Email.
• Ở phần “To“, bạn soạn tên group email mà bạn muốn gửi hoặc có thể click vào nó và tìm kiếm group hay chọn tên từ danh sách hiển thị.

Như vậy, bài viết trên Tenten đã hướng dẫn quý khách thao tác thành công tạo group mail trong outlook. Chúc quý khách thao tác thành công.

Bài viết Hướng dẫn tạo group Email trong Outlook đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Tính năng Default Address giúp người dùng giữ lại tất cả các email không hợp lệ gửi đến tên miền của bạn. Nghĩa là các email mang tên miền của bạn mặc dù email đó chưa được tạo (không tồn tại).

Giao  diện của tính năng Default Address cho phép bạn thiết lập một địa chỉ mặc định (Default Address), địa chỉ này sẽ “bắt” (catch) – thu nhận tất cả những Email được gửi tới những địa chỉ không hợp lệ trên domain của bạn (Ví dụ như một Email được gửi tới địa chỉ không chính xác,.).

Giao diện này cũng cho phép bạn tùy chỉnh cách mà Default Address xử lý các thư bắt được. Việc tạo ra một địa chỉ mặc định rất có ích trong trường hợp muốn thu gom những Email “lang thang” trên domain của bạn, tuy nhiên việc đó cũng có nghĩa là thu gom cả thư rác hay những Email spam.

Để  truy cập giao diện của tính năng, các bạn đăng nhập vào cPanel sau đó chọn Default Address trong mục Email.

2. Thiết lập Default Address.

Bước 1: Chọn domain mà các bạn muốn tiết lập Default Address.

Bước 2: Chọn một trong các tùy chọn ở dưới (Click Advanced Options) để có thêm tùy chọn.

Discard the email while your server processes it by SMTP time with an error message: Chọn tùy chọn này để gửi một thông báo lỗi cho người gửi.Nhập thông báo bạn muốn hiển thị cho người gửi vào ô Failure Message (seen by sender)

Forward to Email Address: Chuyển tiếp các thư này đến một địa chỉ Email khác.Nhập địa chỉ đó hoặc tên đăng nhập tài khoản cPanel của bạn vào ô Forward to Email Address

Forward to your system account: Tùy chọn này để chuyển tiếp các Email “bắt” được tới system account.

Pipe to a Program: Chọn tùy chọn này để chuyển tiếp các thư tới một chương trình mà đường dẫn của nó được bạn chỉ ra trong khung phía dưới.

Discard (Not Recommended): Nếu bạn chọn tùy chọn này, hệ thống sẽ xóa các thư “bắt” được đồng thời không đưa ra bất kỳ thông báo nào về việc đó. Tùy chọn này không được khuyến cáo với lý do người gửi sẽ không có cách nào để biết về tình trạng của Email mà mình đã gửi đi

Bước 3: Click Change để thay đổi và lưu lại.

Như vậy là các bạn đã thiết lập xong một Default Address. Chúc bạn thao tác thành công !

Bài viết Hướng dẫn sử dụng tính năng Default Address trên mail hosting cPanel đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Trong bài viết này, Tenten sẽ hướng dẫn Quý khách khách thiết lập đặt lịch để gửi email trong outlook.

Bước 1: Mở Outlook và nhấp vào New Email hoặc Reply 1 email bất kỳ.

Bước 2: Thêm các thông tin của email như người nhận, tiêu đề, nội dung của email.

Bước 3: Chuyển đến tab Options trong cửa sổ tin nhắn và chọn Delay delivery trên tab ứng dụng.

Bước 4: Tại phần Properties được mở ra, bạn di chuyển đến phần Delivery options. Đánh dấu vào ô Do not deliver before sau đó chọn ngày và giờ để gửi email.

Bước 5: Nhấp vào Close để thoát khỏi phần Properties.

Bước 6: Lúc này hãy quay lại phần Email. Bấm Send để gửi mail.

Bước 7: Để xem, chỉnh sửa hoặc hủy một email đã lên lịch, hãy chuyển đến thư mục Outbox.

Như vậy Tenten đã hoàn tất hướng dẫn cấu hình hẹn giờ gửi mail trong Outlook. Quý khách tham khảo thêm các bài viết tại đây.

Bài viết Cách hẹn giờ gửi mail trong Outlook cực đơn giản đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Việc chỉnh sửa và cài đặt để kiểm tra lỗi chính tả tiếng Việt trong Outlook là 1 điều rất cần thiết đối với ai đang sử dụng Outlook và tính năng này sẽ giúp bạn:

• Không viết sai các từ khó phát âm và viết.
• Tránh được những lỗi chính tả không đáng có.
• Soạn thảo tốt hơn, tự tin hơn khi làm việc.

II. Hướng dẫn bật/tắt kiểm tra chính tả trên Outloook

1. Hướng dẫn nhanh

Vào File > Chọn Options > Chọn Mail > Chọn Spelling and Autocorrect > Chọn Proofing > Bỏ đánh dấu ô Check spelling as you type > Nhấn OK.

2. Hướng dẫn chi tiết

Đây là lỗi gạch đỏ gây khó chịu khi bật tính năng kiểm tra chính tả. Mình sẽ chỉ bạn cách khắc phục lỗi này nhé!

Lỗi gạch đỏ gây khó chịu khi bật tính năng kiểm tra chính tả

Bước 1: Vào File.

Vào File

Bước 2: Chọn Options.

Chọn Options

Bước 3: Ở hộp thoại Outlook Options chọn Mail sau đó chọn Spelling and Autocorrect.

Chọn Mail sau đó chọn Spelling and Autocorrect

Bước 4: Chọn Proofing sau đó bỏ đánh dấu ô Check spelling as you type và nhấn OK.

Bỏ đánh dấu ô Check spelling as you type và nhấn OK

Lúc này, bạn đã tắt kiểm tra lỗi chính tả trong Outlook thành công. Nếu bạn muốn bật lại tính năng kiểm tra lỗi chính tả thì hãy thực hiện các thao tác trên và đánh dấu vào ô Check spelling as you type nhé!

Tắt kiểm tra lỗi chính tả trong Outlook thành công

Bài viết Hướng dẫn bật/ tắt kiểm tra lỗi chính tả trong Outlook. đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Để quản lý và ghi nhớ địa chỉ của số máy tính khủng này không phải là điều dễ dàng, vì thế chúng ta cần sự hỗ trợ của MX Record.

Trong bài viết dưới đây, Tenten sẽ thông tin chi tiết về MX record.

DNS MX record là gì?

MX record được biết đến là một bản ghi trong DNS zone. Nó chuyển hướng mail từ Client đến Mail Server và cho biết cách gửi email theo giao thức SMTP. Cũng tương tự như CNAME record, MX record phải luôn trỏ đến một domain khác. Dưới đây là ví dụ về MX record:

“Priority” biểu thị quyền được ưu tiên, mức ưu tiên nào thấp hơn thì sẽ được ưu tiên. Quan sát ví dụ trên thì mailhost1 luôn được Server thử trước mailhost 2 vì giá trị 0 thấp hơn 10. Tuy nhiên có nhiều trường hợp dịch vụ email sẽ cấu hình MX record với mức ưu tiên ở “priority” giống nhau. Điều này sẽ giúp cả hai Server có mức độ ưu tiên ngang bằng từ đó đều nhận được lượng thư như nhau, ví dụ:

Quá trình truy vấn MX record

Message transfer agent viết tắt là MTA (tác nhân chuyển thư) đảm nhận vai trò truy vấn MX record. Khi một email được gửi đi, để giúp người nhận xác định được Mail Server thì MTA sẽ gửi đi một truy vấn DNS. Các Mail Server sẽ được thiết lập kết nối bằng giao thức SMTP với MTA, bắt đầu với các domain ưu tiên (ở ví dụ 1 thì đó là mailhost1).

MX record dự phòng là gì?

MX record dự phòng được thiết lập cho MX record có giá trị “priority” cao hơn (tức là mức ưu tiên thấp hơn). Khi Server MX record chính gặp sự cố thì các email sẽ được gửi tới MX record dự phòng. Với ví dụ 1 MX record dự phòng chính là mailhost2 và nó chỉ nhận thư khi mailhost1 có vấn đề phát sinh.

MX record có thể trỏ đến CNAME không?

Bí danh của domain sẽ được CNAME record tham chiếu thay vì tên domain chuẩn. Trong IPv4 và IPv6 CNAME record thường trỏ đến A record và AAAA record cho domain đó. Trong khi đó MX record lại bắt buộc phải trỏ trực tiếp đến A record hoặc AAAA record của Server và không được phép trỏ đến CNAME.

Tổng kết về MX record

Trên đây chúng tôi đã tổng quan một vài nét liên quan tới MX Record. Còn rất nhiều những thông tin thú vị về loại bản ghi này.

Bài viết DNS MX Record là gì? Quá trình truy vấn MX Record đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

SMTP error from remote mail server after pipelined MAIL FROM:<XXX@domain> SIZE=14714496: 552 5.3.4 Message size exceeds fixed limit

HOẶC

<user1@example.com>: host host.example.com said:
552 Message size exceeds fixed maximum message size (5000000)<user@example.com>: host mx2.mail.example.com said:
552 message size exceeds maximum message size

<user@example.com>: host mx01.example.com said:
552 Message size exceeds fixed maximum message size: 5242880 bytes

Bên cạnh đó , sẽ có trường hợp hệ thống Mail sẽ thông báo cho Bạn trước khi lá Mail của Bạn được gửi ra ngoài hệ thống.

Tại Giao Diện Webmail dịch vụ Email Pro v3:

Tại Giao Diện Outlook

Lỗi mail dung lượng thư gửi quá lớn : Dung lượng thư gửi đi quá lớn nên gửi đi không thành công. Bạn có thể kiểm tra dung lượng email gửi đi, bao gồm nội dung thư và files đính kèm. Tổng dung lượng của lá mail gửi đi không vượt quá 30 MB. Nếu có nhu cầu gửi email chứa files đính kèm lớn, bạn có thể gửi thư kèm theo link download thay vì đính kèm files để có thể giao dịch email ổn định và thành công.

Trường hợp này bạn nên nén tập tin lại dưới dạng file zip hoặc rar sau đó thử gửi lại để kiểm tra. Bên cạnh đó bạn cũng có thể tải tập tin lên dịch vụ lưu trữ điện toán đám mây như Google Drive, Mega, MediaFire, … sau đó chia sẻ đường dẫn trong nội dung Email để đối tác có thể tải dữ liệu về.

Ở bài viết này, Tenten.vn sẽ hướng dẫn cho Bạn thao tác tạo đường dẫn đính kèm vào Mail (cụ thể là Google Drive) để việc gửi mail được thuận tiện hơn như sau :

Bước 1 : Các Bạn truy cập vào đường dẫn drive.google.com

Bước 2 : Bạn chọn tải tệp lên và chọn tệp mình cần chia sẻ

Bước 3 : Sau khi tải tệp lên thành công , Bạn vui lòng nhấp chuột phải vào tập tin chọn “Nhận đường liên kết”

Bạn lưu ý nhớ chọn vào dòng “Bất kỳ ai có đường liên kết” để khi đối tác nhận được đường dẫn sẽ không bị giới hạn về quyền truy cập.

Bước 4: Bạn bấm vào “Sao chép đường liên kết” để copy đường dẫn đính kèm vào Email của mình.

Bước 5: Bạn đính kèm đường dẫn vào nội dung lá mail gửi đi, khi đó sẽ không bị báo lỗi trả về.

Chúc các bạn thao tác thành công!!!

Bài viết Hướng dẫn khắc phục lỗi mail dung lượng thư gửi quá lớn đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

Quý khách có thể tham khảo thêm các bài viết hướng dẫn khác tại đây.

Bước 1: Đăng nhập trang quản trị Email Server.

Bước 2: Cấu hình dung lượng.

Quý khách lựa chọn user cần thay đổi dung lượng -> chọn phần chỉnh sửa ở Dung Lượng để thay đổi.

Bước 3: Cập nhật dung lượng

Quý khách nhập dung lượng cần cấp cho user. Đơn vị tính dung lượng sẽ là MB.

Quý khách nhấn Thay đổi để lưu cấu hình.

Chúc Quý khách thành công!!

Bài viết Hướng dẫn thay đổi dung lượng tài khoản Email Server đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.