Internet Message Access Protocol

Bộ giao thức Internet
Tầng ứng dụng (Application layer)
BGP DHCP DNS FTP HTTP IMAP LDAP MGCP NNTP NTP POP ONC/RPC RTP RTSP RIP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP xem tất cả...
Tầng giao vận (Transport layer)
TCP UDP CCP SCTP RSVP xem tất cả...
Tầng mạng (Internet layer)
IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec xem tất cả...
Tầng liên kết (Link layer)
ARP NDP OSPF L2TP PPP PPTP STP MAC Ethernet DSL ISDN FDDI xem tất cả...
x t s

Trong máy tính, Internet Message Access Protocol (IMAP) là giao thức chuẩn Internet được sử dụng bởi các ứng dụng email để truy xuất thư email từ máy chủ thư qua kết nối TCP/IP.^[1] IMAP được xác định bởi RFC 3501.

IMAP được thiết kế với mục tiêu cho phép quản lý hoàn toàn hộp thư email của nhiều khách hàng email, do đó, khách hàng thường để lại thư trên máy chủ cho đến khi người dùng xóa chúng một cách rõ ràng. Một máy chủ IMAP thường lắng nghe trên cổng số 143. IMAP qua SSL (IMAPS) được gán số cổng 993.

Hầu như tất cả các máy khách và máy chủ email hiện đại đều hỗ trợ IMAP, cùng với POP3 (Post Office Protocol) trước đó là hai giao thức tiêu chuẩn phổ biến nhất để truy xuất email.^[2] Nhiều nhà cung cấp dịch vụ webmail như Gmail, Outlook.com và Yahoo! Mail cũng cung cấp hỗ trợ cho IMAP hoặc POP3.

Giao thức truy cập thư Internet là một giao thức Internet của lớp ứng dụng cho phép máy khách email truy cập email trên máy chủ thư từ xa. Phiên bản hiện tại được xác định bởi RFC 3501. Một máy chủ IMAP thường lắng nghe trên cổng 143 nổi tiếng, trong khi IMAP qua SSL (IMAPS) sử dụng 993.

Tin nhắn e-mail đến được gửi đến một máy chủ e-mail lưu trữ tin nhắn trong hộp e-mail của người nhận. Người dùng truy xuất các thư với ứng dụng khách email sử dụng một trong số các giao thức truy xuất email. Mặc dù một số khách hàng và máy chủ ưu tiên sử dụng các giao thức độc quyền, dành riêng cho nhà cung cấp,^[3] hầu như tất cả đều hỗ trợ POP và IMAP để truy xuất email - cho phép nhiều lựa chọn miễn phí giữa nhiều ứng dụng khách email như Pegasus Mail hoặc Mozilla Thunderbird để truy cập các máy chủ này và cho phép các máy khách được sử dụng với các máy chủ khác.

Các ứng dụng email khách sử dụng IMAP thường để lại tin nhắn trên máy chủ cho đến khi người dùng xóa chúng một cách rõ ràng. Điều này và các đặc điểm khác của hoạt động IMAP cho phép nhiều khách hàng quản lý cùng một hộp thư. Hầu hết các ứng dụng khách email đều hỗ trợ IMAP ngoài Post Office Protocol (POP) để truy xuất thư.^[4] IMAP cung cấp quyền truy cập vào bộ lưu trữ thư. Khách hàng có thể lưu trữ các bản sao cục bộ của tin nhắn, nhưng chúng được coi là bộ đệm tạm thời.^[5]

IMAP được Mark Crispin thiết kế vào năm 1986 như một giao thức hộp thư truy cập từ xa, trái ngược với POP được sử dụng rộng rãi, một giao thức chỉ đơn giản là lấy nội dung của hộp thư.

Nó đã trải qua một số phiên bản trước VERSION 4rev1 (MAPI4) hiện tại, như chi tiết dưới đây:

Interim Mail Access Protocol ban đầu được triển khai dưới dạng máy khách Xerox Lisp và máy chủ TOPS-20.

Không có bản sao của đặc tả giao thức tạm thời gốc hoặc phần mềm của nó tồn tại.^[6][7] Mặc dù một số lệnh và phản hồi của nó tương tự IMAP2, giao thức tạm thời thiếu gắn thẻ lệnh / phản hồi và do đó cú pháp của nó không tương thích với tất cả các phiên bản IMAP khác.

Giao thức tạm thời nhanh chóng được thay thế bằng Interactive Mail Access Protocol (IMAP2), được xác định trong RFC 1064 (năm 1988) và sau đó được cập nhật bởi RFC 1176 (năm 1990). IMAP2 đã giới thiệu gắn thẻ lệnh / phản hồi và là phiên bản phân phối công khai đầu tiên.

IMAP3 là một biến thể cực kỳ hiếm của IMAP.^[8] Nó được xuất bản với tên RFC 1203 vào năm 1991. Nó được viết cụ thể như một đề xuất phản đối với RFC 1176, chính nó đã đề xuất sửa đổi cho IMAP2.^[9] IMAP3 không bao giờ được chấp nhận bởi thị trường.^[10][11] IESG phân loại lại RFC1203 "Giao thức truy cập thư tương tác - Phiên bản 3" như một giao thức Lịch sử vào năm 1993. Nhóm làm việc IMAP đã sử dụng RFC1176 (IMAP2) thay vì RFC1203 (IMAP3) làm điểm bắt đầu.^[12][13]

Với sự ra đời của MIME, IMAP2 đã được mở rộng để hỗ trợ cấu trúc đối tượng MIME và thêm chức năng quản lý hộp thư (tạo, xóa, đổi tên, tải lên tin nhắn) không có trong IMAP2. Bản sửa đổi thử nghiệm này được gọi là IMAP2bis; đặc điểm kỹ thuật của nó đã không bao giờ được công bố ở dạng không dự thảo. Một bản nháp của IMAP2bis đã được Nhóm làm việc IETF IMAP xuất bản vào tháng 10 năm 1993. Dự thảo này dựa trên các thông số kỹ thuật trước đây: IMAP2bis chưa được công bố . Tài liệu TXT, RFC1176 và RFC1064 (IMAP2).^[14] IMAP2bis. Bản nháp TXT đã ghi lại trạng thái của các phần mở rộng cho IMAP2 kể từ tháng 12 năm 1992.^[15] Các phiên bản đầu tiên của Thông được phân phối rộng rãi với hỗ trợ IMAP2bis ^[8] (Pine 4 và sau đó hỗ trợ IMAP4rev1).

Một nhóm làm việc IMAP được thành lập trong IETF vào đầu những năm 1990 đã chịu trách nhiệm về thiết kế IMAP2bis. WG IMAP đã quyết định đổi tên IMAP2bis thành IMAP4 để tránh nhầm lẫn.

Khi sử dụng POP, khách hàng thường kết nối nhanh với máy chủ email, chỉ khi cần tải xuống thư mới. Khi sử dụng IMAP4, khách hàng thường duy trì kết nối miễn là giao diện người dùng được kích hoạt và tải xuống nội dung tin nhắn theo yêu cầu. Đối với người dùng có nhiều hoặc nhiều tin nhắn, mẫu sử dụng IMAP4 này có thể dẫn đến thời gian phản hồi nhanh hơn.

Giao thức POP yêu cầu máy khách hiện được kết nối là máy khách duy nhất được kết nối với hộp thư. Ngược lại, giao thức IMAP đặc biệt cho phép truy cập đồng thời bởi nhiều khách hàng và cung cấp các cơ chế để khách hàng phát hiện các thay đổi được thực hiện đối với hộp thư bằng các máy khách khác, được kết nối đồng thời. Xem ví dụ RFC3501 phần 5.2 trong đó trích dẫn cụ thể "truy cập đồng thời vào cùng một hộp thư bởi nhiều tác nhân" làm ví dụ.

Thông thường tất cả e-mail Internet được truyền ở định dạng MIME, cho phép các tin nhắn có cấu trúc cây trong đó các nút lá là bất kỳ loại nội dung một phần nào và các nút không có lá là bất kỳ loại đa dạng nào. Giao thức IMAP4 cho phép khách hàng truy xuất bất kỳ phần MIME riêng lẻ nào và cũng có thể truy xuất các phần của từng phần riêng lẻ hoặc toàn bộ tin nhắn. Các cơ chế này cho phép khách hàng truy xuất phần văn bản của tin nhắn mà không cần truy xuất các tệp đính kèm hoặc truyền phát nội dung khi nó đang được tìm nạp.

Thông qua việc sử dụng các cờ được xác định trong giao thức IMAP4, khách hàng có thể theo dõi trạng thái tin nhắn: ví dụ: tin nhắn đã được đọc, trả lời hay xóa. Các cờ này được lưu trữ trên máy chủ, vì vậy các máy khách khác nhau truy cập vào cùng một hộp thư vào các thời điểm khác nhau có thể phát hiện các thay đổi trạng thái được thực hiện bởi các máy khách khác. POP không cung cấp cơ chế cho khách hàng lưu trữ thông tin trạng thái như vậy trên máy chủ, vì vậy nếu một người dùng truy cập hộp thư có hai ứng dụng khách POP khác nhau (vào các thời điểm khác nhau), thông tin trạng thái, chẳng hạn như liệu tin nhắn đã được truy cập có thể được đồng bộ hóa giữa khách hàng Giao thức IMAP4 hỗ trợ cả cờ hệ thống được xác định trước và từ khóa do khách hàng xác định. Cờ hệ thống cho biết thông tin trạng thái như tin nhắn đã được đọc chưa. Từ khóa, không được hỗ trợ bởi tất cả các máy chủ IMAP, cho phép tin nhắn được cung cấp một hoặc nhiều thẻ có ý nghĩa tùy thuộc vào máy khách. Không nên nhầm lẫn từ khóa IMAP với nhãn độc quyền của dịch vụ email dựa trên web đôi khi được dịch sang thư mục IMAP bởi các máy chủ độc quyền tương ứng.

Máy khách IMAP4 có thể tạo, đổi tên và/hoặc xóa hộp thư (thường được hiển thị cho người dùng dưới dạng thư mục) trên máy chủ và sao chép thư giữa các hộp thư. Hỗ trợ nhiều hộp thư cũng cho phép các máy chủ cung cấp quyền truy cập vào các thư mục chung và chung. Phần mở rộng Danh sách kiểm soát truy cập IMAP4 (ACL) (RFC 4314) có thể được sử dụng để điều chỉnh quyền truy cập.

IMAP4 cung cấp một cơ chế để khách hàng yêu cầu máy chủ tìm kiếm các thư đáp ứng nhiều tiêu chí khác nhau. Cơ chế này tránh yêu cầu khách hàng tải xuống mọi thư trong hộp thư để thực hiện các tìm kiếm này.

Phản ánh trải nghiệm của các giao thức Internet trước đó, IMAP4 xác định một cơ chế rõ ràng mà theo đó nó có thể được mở rộng. Nhiều phần mở rộng IMAP4 cho giao thức cơ sở đã được đề xuất và được sử dụng phổ biến. IMAP2bis không có cơ chế mở rộng và POP hiện có một cơ chế được xác định bởi RFC 2449.

Mặc dù IMAP khắc phục được nhiều thiếu sót của POP, nhưng điều này vốn đã giới thiệu sự phức tạp bổ sung. Phần lớn sự phức tạp này (ví dụ: nhiều máy khách truy cập cùng một hộp thư cùng một lúc) được bù đắp bằng các cách giải quyết phía máy chủ như Maildir hoặc phụ trợ cơ sở dữ liệu.

Đặc tả IMAP đã bị chỉ trích là không đủ nghiêm ngặt và cho phép các hành vi phủ nhận tính hữu dụng của nó một cách hiệu quả. Chẳng hạn, thông số kỹ thuật nói rằng mỗi tin nhắn được lưu trữ trên máy chủ có một "id duy nhất" để cho phép khách hàng xác định các tin nhắn mà họ đã thấy giữa các phiên. Tuy nhiên, đặc điểm kỹ thuật cũng cho phép các UID này bị vô hiệu mà không bị hạn chế, thực tế đã đánh bại mục đích của chúng.^[16]

Trừ khi các thuật toán lưu trữ và tìm kiếm thư trên máy chủ được triển khai cẩn thận, khách hàng có khả năng tiêu thụ một lượng lớn tài nguyên máy chủ khi tìm kiếm các hộp thư lớn.

Các máy khách IMAP4 cần duy trì kết nối TCP / IP đến máy chủ IMAP để được thông báo về sự xuất hiện của thư mới. Thông báo về việc gửi thư được thực hiện thông qua báo hiệu trong băng tần, điều này góp phần vào sự phức tạp của việc xử lý giao thức IMAP phía khách hàng.^[17] Một đề xuất riêng, đẩy IMAP, sẽ mở rộng IMAP để triển khai e-mail đẩy bằng cách gửi toàn bộ thư thay vì chỉ một thông báo. Tuy nhiên, việc đẩy IMAP thường không được chấp nhận và công việc IETF hiện tại đã giải quyết vấn đề theo những cách khác (xem Hồ sơ Lemonade để biết thêm thông tin).

Không giống như một số giao thức độc quyền kết hợp các hoạt động gửi và truy xuất, gửi tin nhắn và lưu một bản sao trong thư mục phía máy chủ với ứng dụng khách IMAP cấp cơ sở yêu cầu truyền nội dung thư hai lần, một lần đến SMTP để gửi và lần thứ hai đến IMAP lưu trữ trong một thư mục thư đã gửi. Điều này được giải quyết bằng một bộ tiện ích mở rộng được xác định bởi IETF Lemonade Profile cho thiết bị di động: URLAUTH (RFC 4467) và CATENATE (RFC 4469) trong IMAP và BURL (RFC 4468) trong SMTP-SUBMISSION. Ngoài ra, Courier Mail Server cung cấp một phương thức gửi không chuẩn bằng IMAP bằng cách sao chép thư đi vào thư mục hộp thư đi chuyên dụng.^[18]

Để bảo mật bằng mật mã các kết nối IMAP, IMAPS trên cổng TCP 993 có thể được sử dụng, sử dụng TLS. Kể từ RFC 8314, đây là cơ chế được khuyến nghị.

Ngoài ra, STARTTLS có thể được sử dụng để cung cấp liên lạc an toàn giữa MUA giao tiếp với MSA hoặc MTA thực hiện Giao thức SMTP.

Đây là một kết nối IMAP ví dụ như được lấy từ RFC 3501 phần 8:

C: <open connection>
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:)
S: a004 OK FETCH completed
C a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed

• "IMAP Protocol Mailing List". Bản gốc lưu trữ ngày 3 tháng 11 năm 2007. Truy cập ngày 19 tháng 3 năm 2019.
• RFC 3501 - đặc điểm kỹ thuật của phiên bản IMAP 4 phiên bản 1
• RFC 2683 - Gợi ý triển khai IMAP RFC
• RFC 2177 - Lệnh IDLE IMAP4
• Phần mở rộng IMAP cho các ứng dụng lớp di động được trình bày và minh họa trong luận án tiến sĩ