Internet Message Access Protocol

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.comYahoo! Mail cũng cung cấp hỗ trợ cho IMAP hoặc POP3.

Giao thức thư điện tử sửa

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]

Lịch sử sửa

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:

IMAP ban đầu sửa

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.

IMAP2 sửa

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 sửa

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]

IMAP2bis sửa

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).

IMAP4 sửa

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.

Ưu điểm so với POP sửa

Chế độ kết nối và ngắt kết nối sửa

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.

Nhiều khách hàng đồng thời sửa

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ụ.

Truy cập vào phần tin nhắn MIME và tìm nạp một phần sửa

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 tin trạng thái tin nhắn sửa

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.

Nhiều hộp thư trên máy chủ sửa

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.

Tìm kiếm phía máy chủ sửa

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.

Cơ chế mở rộng tích hợp sửa

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.

Nhược điểm sửa

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 sửa

Để 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.

Ví dụ về hộp thoại sửa

Đâ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

Tham khảo sửa

  1. ^ Dean, Tamara (2010). Network+ Guide to Networks. Delmar. tr. 519. ISBN 1423902459.
  2. ^ Komarinski, Mark (2000). Red Hat Linux System Administration Handbook. Prentice Hall. tr. 179. ISBN 1423902459.
  3. ^ Ví dụ, Microsoft 's Outlook client sử dụng MAPI, một Microsoft giao thức độc quyền, để giao tiếp với một Microsoft Exchange Server. Máy khách Ghi chú của IBM hoạt động theo cách tương tự khi giao tiếp với máy chủ Domino.
  4. ^ Mullet, Diana (2000). Managing IMAP. O'Reilly. tr. 25. ISBN 0-596-00012-X.
  5. ^ See e.g. Timo Sirainen, Dave Cridland. “IMAP Client Coding HOWTO”.
  6. ^ Crispin, Mark (ngày 13 tháng 2 năm 2012). “Re: [imap5] Designing a new replacement protocol for IMAP” (Danh sách thư). Truy cập ngày 26 tháng 11 năm 2014. Knowledge of the original IMAP (before IMAP2) exists primarily in my mind as all the original IMAP specifications and implementations were replaced with IMAP2. Đã bỏ qua tham số không rõ |mailinglist= (trợ giúp)
  7. ^ Tên dịch vụ và đăng ký giao thức số cổng giao thức. Iana.org (2013-07-12). Truy cập ngày 2013/07/17.
  8. ^ a b “RFC 2061 - IMAP4 COMPATIBILITY WITH IMAP2BIS”. IETF. 1996. Truy cập ngày 21 tháng 8 năm 2010.
  9. ^ “INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3”. IETF. 1991. Truy cập ngày 21 tháng 8 năm 2010.
  10. ^ “IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (LAN Mail Protocols)”. Truy cập ngày 21 tháng 8 năm 2010.
  11. ^ “IMAP Overview, History, Versions and Standards”. Truy cập ngày 21 tháng 8 năm 2010.
  12. ^ “Protocol Action: Interactive Mail Access Protocol — Version 3 to Historic (IETF mail archive)”. 1993. Truy cập ngày 21 tháng 8 năm 2010.
  13. ^ “Innosoft and POP/IMAP protocols? (mail archive)”. 1993. Truy cập ngày 21 tháng 8 năm 2010.
  14. ^ “INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis (Internet Draft)”. IETF. 1993. Truy cập ngày 21 tháng 8 năm 2010.
  15. ^ “IMAP2BIS -- EXTENSIONS TO THE IMAP2 PROTOCOL (DRAFT)”. 1992. Bản gốc lưu trữ ngày 18 tháng 7 năm 2011. Truy cập ngày 21 tháng 8 năm 2010.
  16. ^ “IMAP implementation in Sup, an e-mail client written in Ruby”. rubyforge.com. Bản gốc lưu trữ ngày 12 tháng 12 năm 2007. Truy cập ngày 22 tháng 2 năm 2011.
  17. ^ “IMAP IDLE: The best approach for 'push' e-mail”. Isode.com. Truy cập ngày 30 tháng 7 năm 2009.
  18. ^ “Courier-IMAP: Sending mail via an IMAP connection”. Double Precision, Inc. Truy cập ngày 24 tháng 9 năm 2013.

Liên kết ngoài sửa