RFC 9051: IMAP4rev2
Tại Sao Điều Này Tồn Tại
IMAP4rev1 (RFC 3501, xuất bản năm 2003) là nền tảng của email đa thiết bị trong gần hai thập kỷ. Nhưng nó tích lũy hàng chục RFC mở rộng, những trường hợp biên rõ ràng, và các tính năng mà mọi máy chủ thực tế đều triển khai khác nhau. RFC 9051 — IMAP4rev2 — là một bản sửa đổi sạch sẽ:
- Gộp các tiện ích mở rộng thiết yếu. Các tính năng như CONDSTORE (conditional store), NAMESPACE, ESEARCH, LIST-EXTENDED, LITERAL-, và MOVE hiện là một phần của giao thức cơ sở thay vì các add-on tùy chọn.
-
Loại bỏ các tính năng không dùng nữa. Cờ
\Recentcũ đã biến mất. Cũng như những hành vi mơ hồ xung quanh truy cập hộp thư đồng thời. - Làm rõ ngữ nghĩa đồng bộ hóa. Các quy tắc chính xác cho UIDVALIDITY, MODSEQ, và theo dõi thay đổi giúp có thể xây dựng các ứng dụng khách đáng tin cậy có khả năng hoạt động ngoại tuyến.
Nếu bạn đang xây dựng ứng dụng email mới hoặc tích hợp, hãy nhắm đến IMAP4rev2. Nếu máy chủ chỉ hỗ trợ IMAP4rev1, bộ lệnh gần như giống hệt — chỉ cần thương lượng các tiện ích mở rộng từng cái một.
Cách Thức Hoạt Động
Kết Nối và Xác Thực
IMAP sử dụng cổng 143 (STARTTLS) hoặc cổng 993 (TLS ngầm, được khuyến cáo). Sau khi kết nối, ứng dụng khách xác thực:
-- Kết nối đến cổng 993 (IMAPS) -- * OK [CAPABILITY IMAP4rev2 AUTH=PLAIN] server ready a1 LOGIN alice@example.com s3cretP@ss a1 OK [CAPABILITY IMAP4rev2 MOVE CONDSTORE] Logged in
Mỗi lệnh của ứng dụng khách được đặt tiền tố với một thẻ (như a1). Máy chủ trả lời với cùng một thẻ, cho phép các lệnh được đưa vào hàng đợi. Các phản hồi không được gắn thẻ (có tiền tố *) mang dữ liệu như số lượng tin nhắn và danh sách khả năng.
Chọn Hộp Thư
a2 SELECT INBOX * 42 EXISTS ← 42 tin nhắn trong INBOX * OK [UIDVALIDITY 1609459200] ← kỷ nguyên UID; nếu thay đổi, re-sync * OK [UIDNEXT 1053] ← UID tiếp theo sẽ được gán * OK [HIGHESTMODSEQ 7834] ← để đồng bộ hóa tăng dần (CONDSTORE) * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) a2 OK [READ-WRITE] SELECT completed
Tìm Nạp Tin Nhắn
-- Tìm nạp envelope và cờ cho tin nhắn 1:5 -- a3 FETCH 1:5 (FLAGS ENVELOPE) * 1 FETCH (FLAGS (\Seen) ENVELOPE ("Wed, 12 Mar 2025 ..." ...)) * 2 FETCH (FLAGS () ENVELOPE (...)) ... a3 OK FETCH completed -- Tìm nạp phần thân đầy đủ của tin nhắn UID 1050 -- a4 UID FETCH 1050 (BODY[]) * 41 FETCH (UID 1050 BODY[] {4523} (tin nhắn RFC 5322 đầy đủ...) ) a4 OK UID FETCH completed
Tìm Kiếm Phía Máy Chủ
a5 SEARCH UNSEEN FROM "bob@example.com" SINCE 1-Mar-2025 * SEARCH 38 41 42 a5 OK SEARCH completed
Các Chi Tiết Kỹ Thuật Chính
UID và Số Thứ Tự
Mỗi tin nhắn có hai mã định danh: một số thứ tự (vị trí của nó trong hộp thư, thay đổi khi tin nhắn bị xóa) và một UID (một số được gán vĩnh viễn chỉ tăng). Các ứng dụng khách mạnh mẽ luôn sử dụng UID thông qua UID FETCH, UID SEARCH, v.v. Giá trị UIDVALIDITY cho ứng dụng khách biết liệu các UID được lưu trong bộ nhớ cache của nó có còn hợp lệ hay không; nếu nó thay đổi, ứng dụng khách phải re-sync từ đầu.
Cờ
IMAP4rev2 định nghĩa các cờ hệ thống này:
| Cờ | Ý Nghĩa |
|---|---|
\Seen |
Tin nhắn đã được đọc |
\Answered |
Tin nhắn đã được trả lời |
\Flagged |
Được đánh dấu là quan trọng / được gắn dấu sao |
\Deleted |
Được đánh dấu để xóa (xóa trên EXPUNGE) |
\Draft |
Tin nhắn là một bản nháp |
Cờ \Recent từ IMAP4rev1 được loại bỏ trong rev2. Máy chủ cũng có thể hỗ trợ các từ khóa tùy chỉnh (ví dụ: $Forwarded, $Junk).
CONDSTORE và QRESYNC
CONDSTORE gán giá trị MODSEQ cho mỗi thay đổi cờ. Ứng dụng khách biết MODSEQ cuối cùng mà nó thấy có thể hỏi: "cái gì đã thay đổi kể từ MODSEQ 7834?" và chỉ nhận được các delta. QRESYNC (Quick Resynchronization) mở rộng điều này để xử lý các tin nhắn bị xóa một cách hiệu quả. Cùng nhau, chúng làm cho IMAP khả thi trên các mạng di động nơi re-sync đầy đủ quá đắt.
Lệnh MOVE
Trong IMAP4rev1, di chuyển tin nhắn yêu cầu COPY + STORE \Deleted + EXPUNGE — ba lệnh có điều kiện chạy. IMAP4rev2 bao gồm MOVE như một hoạt động nguyên tử asynchronous:
a6 UID MOVE 1050 "Archive" * OK [COPYUID 1609459200 1050 287] * 41 EXPUNGE a6 OK MOVE completed
Những Sai Lầm Phổ Biến
- Sử dụng số thứ tự cho tài liệu tham khảo lâu dài. Số thứ tự thay đổi khi tin nhắn bị xóa. Luôn sử dụng UID cho bất cứ thứ gì bạn lưu trong bộ nhớ cache hoặc tham khảo trên các phiên.
- Bỏ qua những thay đổi UIDVALIDITY. Nếu UIDVALIDITY thay đổi giữa các phiên, tất cả các UID được lưu trong bộ nhớ cache của bạn đều không hợp lệ. Bạn phải loại bỏ bộ nhớ cache cục bộ và re-sync.
-
Thăm dò thay vì sử dụng IDLE. Lệnh
IDLEcho phép máy chủ đẩy thông báo tin nhắn mới. Thăm dò cứ 30 giây lãng phí băng thông và pin. Sử dụng IDLE để cập nhật thực tế. -
Tìm nạp BODY[] khi bạn cần BODY.PEEK[].
FETCH BODY[]ngầm đặt cờ\Seen. Sử dụngBODY.PEEK[]để đọc mà không đánh dấu là đã đọc. - Không hỗ trợ CONDSTORE. Không có CONDSTORE, mỗi kết nối lại yêu cầu re-sync hộp thư đầy đủ. Các ứng dụng khách IMAP hiện đại luôn nên thương lượng CONDSTORE.
- Chạy IMAP trên cổng 143 mà không TLS. Sử dụng cổng 993 với TLS ngầm theo RFC 8314.
Tác Động Đến Khả Năng Gửi
- IMAP là giao thức truy xuất, không phải giao thức gửi. Giống như POP3, nó không trực tiếp ảnh hưởng đến khả năng gửi outbound. Nó xác định cách người nhận trải nghiệm email bạn gửi.
- Tín hiệu tham gia dựa trên cờ. Các nhà cung cấp lớn (Gmail, Outlook) quan sát những thay đổi cờ IMAP — đánh dấu tin nhắn là \Seen, di chuyển đến các thư mục, gắn dấu sao — như tín hiệu tham gia. Sự tham gia tích cực có thể cải thiện danh tiếng người gửi của bạn theo thời gian.
- Tương tác với thư mục spam. Khi người nhận di chuyển tin nhắn của bạn ra khỏi Junk thông qua IMAP, nhà cung cấp thường coi đây là tín hiệu "không phải spam". Ngược lại, di chuyển IMAP đến Junk tính toán chống lại bạn.
- Xử lý hộp thư bounce. IMAP tốt hơn POP3 để xử lý bounce vì bạn có thể TÌM KIẾM các tin nhắn DSN ở phía máy chủ, xử lý chúng, và DI CHUYỂN chúng đến một kho lưu trữ — tất cả mà không cần tải xuống mọi tin nhắn.