Internet message Access protocol - wikipedia Internet message Access protocol `` IMAP '' redirects here. For the antipsychotic, see Fluspirilene. Internet protocol suite 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 more... Transport layer TCP UDP DCCP SCTP RSVP more... Internet layer IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec more... Link layer ARP NDP OSPF Tunnels L2TP PPP MAC Ethernet DSL ISDN FDDI more... In computing, the Internet Message Access Protocol ( IMAP ) is an Internet standard protocol used by e-mail clients to retrieve e-mail messages from a mail server over a TCP / IP connection. IMAP is defined by RFC 3501. IMAP was designed with the goal of permitting complete management of an email box by multiple email clients, therefore clients generally leave messages on the server until the user explicitly deletes them. An IMAP server typically listens on port number 143. IMAP over SSL ( IMAPS ) is assigned the port number 993. Virtually all modern e-mail clients and servers support IMAP. IMAP and the earlier POP3 ( Post Office Protocol ) are the two most prevalent standard protocols for email retrieval, with many webmail service providers such as Gmail, Outlook.com and Yahoo ! Mail also providing support for either IMAP or POP3. Contents 1 E-mail protocols 2 History 2.1 Original IMAP 2.2 IMAP2 2.3 IMAP3 2.4 IMAP2bis 2.5 IMAP4 3 Advantages over POP 3.1 Connected and disconnected modes of operation 3.2 Multiple clients simultaneously connected to the same mailbox 3.3 Access to MIME message parts and partial fetch 3.4 Message state information 3.5 Multiple mailboxes on the server 3.6 Server - side searches 3.7 Built - in extension mechanism 4 Disadvantages 5 Security 6 Dialog example 7 See also 8 References 9 Further reading 10 External links E-mail protocols The Internet Message Access Protocol is an Application Layer Internet protocol that allows an e-mail client to access e-mail on a remote mail server. The current version, IMAP version 4 revision 1 ( IMAP4rev1 ), is defined by RFC 3501. An IMAP server typically listens on well - known port 143. IMAP over SSL ( IMAPS ) is assigned well - known port number 993. IMAP supports both on - line and off - line modes of operation. E-mail clients using IMAP generally leave messages on the server until the user explicitly deletes them. This and other characteristics of IMAP operation allow multiple clients to manage the same mailbox. Most e-mail clients support IMAP in addition to Post Office Protocol ( POP ) to retrieve messages ; however, fewer e-mail services support IMAP. IMAP offers access to the mail storage. Clients may store local copies of the messages, but these are considered to be a temporary cache. Incoming e-mail messages are sent to an e-mail server that stores messages in the recipient 's e-mail box. The user retrieves the messages with an e-mail client that uses one of a number of e-mail retrieval protocols. Some clients and servers preferentially use vendor - specific, proprietary protocols, but most support SMTP for sending e-mail and POP and IMAP for retrieving e-mail, allowing interoperability with other servers and clients. For example, Microsoft 's Outlook client uses MAPI, a Microsoft proprietary protocol, to communicate with a Microsoft Exchange Server. IBM 's Notes client works in a similar fashion when communicating with a Domino server. All of these products also support POP, IMAP, and outgoing SMTP. Support for the Internet standard protocols. allows many e-mail clients such as Pegasus Mail or Mozilla Thunderbird to access these servers, and allows the clients to be used with other servers. History IMAP was designed by Mark Crispin in 1986 as a remote mailbox protocol, in contrast to the widely used POP, a protocol for retrieving the contents of a mailbox. IMAP was previously known as Internet Mail Access Protocol, Interactive Mail Access Protocol ( RFC 1064 ), and Interim Mail Access Protocol. Original IMAP The original Interim Mail Access Protocol was implemented as a Xerox Lisp machine client and a TOPS - 20 server. No copies of the original interim protocol specification or its software exist. Although some of its commands and responses were similar to IMAP2, the interim protocol lacked command / response tagging and thus its syntax was incompatible with all other versions of IMAP. IMAP2 The interim protocol was quickly replaced by the Interactive Mail Access Protocol ( IMAP2 ), defined in RFC 1064 ( in 1988 ) and later updated by RFC 1176 ( in 1990 ). IMAP2 introduced the command / response tagging and was the first publicly distributed version. IMAP3 IMAP3 is an extremely rare variant of IMAP. It was published as RFC 1203 in 1991. It was written specifically as a counter proposal to RFC 1176, which itself proposed modifications to IMAP2. IMAP3 was never accepted by the marketplace. The IESG reclassified RFC1203 `` Interactive Mail Access Protocol - Version 3 '' as a Historic protocol in 1993. The IMAP Working Group used RFC1176 ( IMAP2 ) rather than RFC1203 ( IMAP3 ) as its starting point. IMAP2bis With the advent of MIME, IMAP2 was extended to support MIME body structures and add mailbox management functionality ( create, delete, rename, message upload ) that was absent from IMAP2. This experimental revision was called IMAP2bis ; its specification was never published in non-draft form. An internet draft of IMAP2bis was published by the IETF IMAP Working Group in October 1993. This draft was based upon the following earlier specifications : unpublished IMAP2bis. TXT document, RFC1176, and RFC1064 ( IMAP2 ). The IMAP2bis. TXT draft documented the state of extensions to IMAP2 as of December 1992. Early versions of Pine were widely distributed with IMAP2bis support ( Pine 4.00 and later supports IMAP4rev1 ). IMAP4 An IMAP Working Group formed in the IETF in the early 1990s took over responsibility for the IMAP2bis design. The IMAP WG decided to rename IMAP2bis to IMAP4 to avoid confusion. Advantages over POP Connected and disconnected modes of operation When using POP, clients typically connect to the e-mail server briefly, only as long as it takes to download new messages. When using IMAP4, clients often stay connected as long as the user interface is active and download message content on demand. For users with many or large messages, this IMAP4 usage pattern can result in faster response times. Multiple clients simultaneously connected to the same mailbox The POP protocol requires the currently connected client to be the only client connected to the mailbox. In contrast, the IMAP protocol specifically allows simultaneous access by multiple clients and provides mechanisms for clients to detect changes made to the mailbox by other, concurrently connected, clients. See for example RFC3501 section 5.2 which specifically cites `` simultaneous access to the same mailbox by multiple agents '' as an example. Access to MIME message parts and partial fetch Usually all Internet e-mail is transmitted in MIME format, allowing messages to have a tree structure where the leaf nodes are any of a variety of single part content types and the non-leaf nodes are any of a variety of multipart types. The IMAP4 protocol allows clients to retrieve any of the individual MIME parts separately and also to retrieve portions of either individual parts or the entire message. These mechanisms allow clients to retrieve the text portion of a message without retrieving attached files or to stream content as it is being fetched. Message state information Through the use of flags defined in the IMAP4 protocol, clients can keep track of message state : for example, whether or not the message has been read, replied to, or deleted. These flags are stored on the server, so different clients accessing the same mailbox at different times can detect state changes made by other clients. POP provides no mechanism for clients to store such state information on the server so if a single user accesses a mailbox with two different POP clients ( at different times ), state information -- such as whether a message has been accessed -- can not be synchronized between the clients. The IMAP4 protocol supports both predefined system flags and client - defined keywords. System flags indicate state information such as whether a message has been read. Keywords, which are not supported by all IMAP servers, allow messages to be given one or more tags whose meaning is up to the client. IMAP keywords should not be confused with proprietary labels of web - based e-mail services which are sometimes translated into IMAP folders by the corresponding proprietary servers. Multiple mailboxes on the server IMAP4 clients can create, rename, and / or delete mailboxes ( usually presented to the user as folders ) on the server, and copy messages between mailboxes. Multiple mailbox support also allows servers to provide access to shared and public folders. The IMAP4 Access Control List ( ACL ) Extension ( RFC 4314 ) may be used to regulate access rights. Server - side searches IMAP4 provides a mechanism for a client to ask the server to search for messages meeting a variety of criteria. This mechanism avoids requiring clients to download every message in the mailbox in order to perform these searches. Built - in extension mechanism Reflecting the experience of earlier Internet protocols, IMAP4 defines an explicit mechanism by which it may be extended. Many IMAP4 extensions to the base protocol have been proposed and are in common use. IMAP2bis did not have an extension mechanism, and POP now has one defined by RFC 2449. Disadvantages While IMAP remedies many of the shortcomings of POP, this inherently introduces additional complexity. Much of this complexity ( e.g., multiple clients accessing the same mailbox at the same time ) is compensated for by server - side workarounds such as Maildir or database backends. The IMAP specification has been criticised for being insufficiently strict and allowing behaviours that effectively negate its usefulness. For instance, the specification states that each message stored on the server has a `` unique id '' to allow the clients to identify messages they have already seen between sessions. However, the specification also allows these UIDs to be invalidated with no restrictions, practically defeating their purpose. Unless the mail storage and searching algorithms on the server are carefully implemented, a client can potentially consume large amounts of server resources when searching massive mailboxes. IMAP4 clients need to maintain a TCP / IP connection to the IMAP server in order to be notified of the arrival of new mail. Notification of mail arrival is done through in - band signaling, which contributes to the complexity of client - side IMAP protocol handling somewhat. A private proposal, push IMAP, would extend IMAP to implement push e-mail by sending the entire message instead of just a notification. However, push IMAP has not been generally accepted and current IETF work has addressed the problem in other ways ( see the Lemonade Profile for more information ). Unlike some proprietary protocols which combine sending and retrieval operations, sending a message and saving a copy in a server - side folder with a base - level IMAP client requires transmitting the message content twice, once to SMTP for delivery and a second time to IMAP to store in a sent mail folder. This is remedied by a set of extensions defined by the IETF LEMONADE Working Group for mobile devices : URLAUTH ( RFC 4467 ) and CATENATE ( RFC 4469 ) in IMAP and BURL ( RFC 4468 ) in SMTP - SUBMISSION. POP servers do n't support server - side folders so clients have no choice but to store sent items on the client. Many IMAP clients can be configured to store sent mail in a client - side folder, or to BCC oneself and then filter the incoming mail instead of saving a copy in a folder directly. In addition to the LEMONADE `` trio '', Courier Mail Server offers a non-standard method of sending using IMAP by copying an outgoing message to a dedicated outbox folder. Security STARTTLS can be used to provide secure communications between the MUA communicating with the MSA or MTA implementing the SMTP Protocol. Dialog example This is an example IMAP connection as taken from RFC 3501 section 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 See also List of mail servers Comparison of e-mail clients Comparison of mail servers IMAP IDLE Post Office Protocol ( POP ) Push - IMAP Simple Mail Access Protocol Webmail References Jump up ^ Dean, Tamara ( 2010 ). Network+ Guide to Networks. Delmar. p. 519. ISBN 1423902459. Jump up ^ Komarinski, Mark ( 2000 ). Red Hat Linux System Administration Handbook. Prentice Hall. p. 179. ISBN 1423902459. Jump up ^ Mullet, Diana ( 2000 ). Managing IMAP. O'Reilly. p. 25. ISBN 0 - 596 - 00012 - X. Jump up ^ See e.g. Timo Sirainen, Dave Cridland. `` IMAP Client Coding HOWTO ''. Jump up ^ Service Name and Transport Protocol Port Number Registry. Iana.org ( 2013 - 07 - 12 ). Retrieved on 2013 - 07 - 17. Jump up ^ Crispin, Mark ( 13 February 2012 ). `` Re : ( imap5 ) Designing a new replacement protocol for IMAP ''. imap5 ( Mailing list ). Usenet : alpine.OSX.2.00.1202131243200.38441@hsinghsing.panda.com. Retrieved 26 November 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. ^ Jump up to : `` RFC 2061 - IMAP4 COMPATIBILITY WITH IMAP2BIS ''. IETF. 1996. Retrieved 2010 - 08 - 21. Jump up ^ `` INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3 ''. IETF. 1991. Retrieved 2010 - 08 - 21. Jump up ^ `` IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 ( LAN Mail Protocols ) ''. Retrieved 2010 - 08 - 21. Jump up ^ `` IMAP Overview, History, Versions and Standards ''. Retrieved 2010 - 08 - 21. Jump up ^ `` Protocol Action : Interactive Mail Access Protocol - Version 3 to Historic ( IETF mail archive ) ''. 1993. Retrieved 2010 - 08 - 21. Jump up ^ `` Innosoft and POP / IMAP protocols ? ( mail archive ) ''. 1993. Retrieved 2010 - 08 - 21. Jump up ^ `` INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis ( Internet Draft ) ''. IETF. 1993. Retrieved 2010 - 08 - 21. Jump up ^ `` IMAP2BIS -- EXTENSIONS TO THE IMAP2 PROTOCOL ( DRAFT ) ''. 1992. Retrieved 2010 - 08 - 21. Jump up ^ `` IMAP implementation in Sup, an e-mail client written in Ruby ''. rubyforge.com. Archived from the original on 2007 - 12 - 12. Retrieved 2011 - 02 - 22. Jump up ^ `` IMAP IDLE : The best approach for ' push ' e-mail ''. Isode.com. Retrieved 2009 - 07 - 30. Jump up ^ `` Courier - IMAP : Sending mail via an IMAP connection ''. Double Precision, Inc. Retrieved 2013 - 09 - 24. Further reading Heinlein, P ; Hartleben, P ( 2008 ). The Book of IMAP : Building a Mail Server with Courier and Cyrus. No Starch Press. ISBN 1 - 59327 - 177 - 8. Hughes, L ( 1998 ). Internet e-mail Protocols, Standards and Implementation. Artech House Publishers. ISBN 0 - 89006 - 939 - 5. Johnson, K ( 2000 ). Internet E-mail Protocols : A Developer 's Guide. Addison - Wesley Professional. ISBN 0 - 201 - 43288 - 9. Loshin, P ( 1999 ). `` Essential E-mail Standards : RFCs and Protocols Made Practical ''. Programming Internet Mail. O'Reilly. ISBN 1 - 56592 - 479 - 7. External links Look up IMAP in Wiktionary, the free dictionary. `` IMAP Protocol Mailing List ''. RFC 3501 - specification of IMAP version 4 revision 1 RFC 2683 - IMAP Implementation Suggestions RFC RFC 2177 - IMAP4 IDLE command IMAP extensions for mobility - class applications presented and exemplified in a doctoral thesis Email clients Free software Alpine Balsa Citadel / UX Classilla Claws Mail Columba Cone Elm Evolution fetchmail Geary getmail GNUMail Gnus Gnuzilla IMP KMail Mahogany Mailpile Mailx Mailx ( Heirloom Project ) Modest Mozilla Thunderbird Mulberry Mutt nmh / MH Nylas N1 OfflineIMAP Ream Roundcube SeaMonkey SquirrelMail Sylpheed Trojitá YAM Zimbra Freeware CloudMagic Denshin 8 go eM Client EmailTray Foxmail Inky i. Scribe Mailbird Opera Mail TouchMail Retail Hiri Bloomba / WordPerfect Mail CloudMagic IBM Notes InScribe Mail ( Apple ) Mail ( Windows ) Microsoft Outlook Novell GroupWise Shareware Becky ! Eureka Email Forté Agent GyazMail Gemini Pocomail The Bat ! Donationware Pegasus Mail Discontinued Arachne Beonex Communicator BlitzMail cc : Mail Claris Emailer Columbia MM Courier Cyberdog Cyberjack Embrowser Eudora Hula Mailbox Mailody Microsoft Entourage Microsoft Internet Mail and News MINUET Mozilla Mail & Newsgroups Netscape Mail Netscape Messenger 9 NeXTMail Outlook Express Pine POPmail Sparrow Spicebird Turnpike WebSpyder Windows Live Mail Windows Mail Windows Messaging Related technologies Extended SMTP IMAP POP Push - IMAP SMAP SMTP UUCP Related topics Email Unicode and email Comparison List Uniform Resource Identifier ( URI ) schemes Official about acct crid data file geo gopher http https info ldap mailto sip / sips tag tel urn view - source wais ws / wss Unofficial coffee ed2k feed irc / irc6 / ircs ldaps magnet ymsgr Protocol list GND : 4614711 - 1 Retrieved from `` https://en.wikipedia.org/w/index.php?title=Internet_Message_Access_Protocol&oldid=797799352 '' Categories : Internet mail protocols Hidden categories : All articles with unsourced statements Articles with unsourced statements from January 2013 Wikipedia articles with GND identifiers Pages using RFC magic links Talk Contents About Wikipedia Asturianu Azərbaycanca Български Català Čeština Dansk Deutsch Eesti Ελληνικά Español Esperanto Euskara فارسی Français Galego 한국어 Հայերեն Hrvatski Bahasa Indonesia Italiano עברית Latviešu Lietuvių Limburgs Magyar Македонски Malagasy മലയാളം Bahasa Melayu Nederlands 日本 語 Norsk Norsk nynorsk Polski Português Română Русский Scots Simple English Slovenčina Slovenščina Српски / srpski Srpskohrvatski / српскохрватски Suomi Svenska தமிழ் ไทย Türkçe Українська Tiếng Việt Yorùbá 中文 Edit links This page was last edited on 29 August 2017, at 07 : 15. Text is available under the Creative Commons Attribution - ShareAlike License ; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia ® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization. About Wikipedia

Question: what port is utilized by secure imap (imaps)
Answer: 993