Talk:Internet Message Access Protocol

DIMAP

DIMAP redirects here, but the article doesn't seem to discuss it at all. --C167 (talk) 17:17, 15 March 2013 (UTC)

Cleanup, Expert Review tags?

I'd be interested in seeing some review of the article as it stands. The page was tagged for cleanup in January, but there has been no modern discussion of needed cleanups. I did rewrite the sole section that had both an incorrect implication and a citation element, but I don't know what folks feel is needed to get the remaining clean up tags removed. Jonabbey (talk) 19:03, 30 July 2009 (UTC)

What up yo 2600:1016:B015:6DBB:0:46:E281:D701 (talk) 15:47, 8 January 2024 (UTC)

Which Citadel?

Which Citadel is being referenced? The link currently goes to a non-software page. I would assume that it was meant to refer to Citadel/UX, but the page for that is planned for deletion. --JamesStansell

send vs. receive

Near this,

Whether using POP3 or IMAP4 to retrieve messages, clients use the SMTP protocol to send messages. E-mail clients are sometimes referred to as either POP or IMAP clients, but in both cases SMTP is also used.

Emphasize again which of the three are for sending. Which for receiving. —Preceding unsigned comment added by 210.201.31.246 (talk • contribs) 20:10, 18 February 2006

Disadvantages of IMAP

IMAP is a very heavy and complicated protocol. Writing your own custom implementation of an IMAP server is of at least 20 orders of magnitude more complicated than a POP3 implementation.
20 orders of magnitude is like 100000000000000000000x. Knowing both protocols, I'd say 20 times more complicated would be closer to reality, though still highly exaggerated.

Oops, I meant twenty times, and I can state this is not much of an exaggeration as I've seen people implement a POP server in as little as a week, while an IMAP server takes about 20 weeks to implement. --Thoric 15:53, 6 March 2006 (UTC)

I removed the last bullet point here, the one that talked about how header changes might cause header changes that will make POP3 clients think a message is new. The article claimed this was not true for "most" implementations. In truth, most implementations (UW, Cyrus, maildir-based) get this right. It is also not a disadvantage of IMAP per se, but just of the complexity of a multi-protocol message store, and that's already covered in other bullets. --ts4z 31 mar 2006

I just implemented an IMAP server in two weeks, so maybe it's only twice as hard as POP. Most of the complexity is in understanding the FETCH syntax, IMHO. -- wcj

You implemented a complete working IMAP server from scratch in two weeks? This I'd like to see... --Thoric 17:36, 23 May 2007 (UTC)

I wrote one a few years ago in about 6 weeks, although I was doing other things as well. It was a fully threaded C application that used a MySQL database for the storage. Most of the time was spent accomodating several very fussy points in the protocol and learning how Outlook expected IMAP servers to behave. IMAP is not terribly complex protocol. StaticSan (talk) 03:18, 14 January 2009 (UTC)

Sure you can pretty easily write a server that works (or appears to work) with Outlook, but to actually implement the IMAP server in a way that it fully conforms to the specification and is otherwise also considered "well behaving" is going to be much more difficult. There are very few such servers: http://imapwiki.org/ImapTest/ServerStatus. TimoSirainen (talk) 22:26, 22 January 2009 (UTC)

Traffic Reduction for IMAP?

IMAP is not very focused on low bandwidth usage. E.g. if you want to use it via mobile access (GPRS, ...). Especially if you have many messages in your inbox. Are there any initiatives for a leaner protocol? Maybe with push facility? What is going on with HTTP and XML in sense of email retrival?

I use (and have used for nearly 20 years) IMAP on a fairly regular basis from low bandwidth links; although the slowest was 1200 bps modem. IMAP was designed with low bandwidth usage in mind from the onset. Now, it may be that many IMAP clients do not work particularly well on low bandwidth links, but that's the fault of the client in question and not the protocol. I can assure you that with the right client, IMAP works quite well with 4-5 digit message count mailboxes on low bandwidth links. -- MRC

The Lemonade working group [1] is working on extending IMAP and SMTP to make them more suitable for mobile users.--C960657 (talk) 12:43, 9 March 2008 (UTC)

Examples?

Are there any examples that anyone can give users regarding real world differences in the day to day operations of using POP3 vs. IMAP. I use POP3 but have been pushed by business assoc. to start using IMAP. I personally don't see the benefits of using IMAP. It is said here that one has to be continually connected to the IMAP server to read mail since messages are downloaded on demand. What if one is in an airplane, for example, without access to the internet? It seems it is not possible to read messages at all if not continually connected. If this is not correct, the proper changes should be made. I also don't see why it is preferable since you would need a LOT more server resources. For the past 3 years I have been paying $5/yr for 25mb hosting. Upwards of 1GB of mail has been sent to me and I don't need to pay for expensive hosting to store 1GB of messages. I'm pretty much a geek here but don't know anything about IMAP. Can anyone help explain things?

POP was designed as an easy way to get may from a mail server to your own machine. It has few features, and isn't really intended for you to be able to leave your mail on the server (despite "leave mail on server" client configurations).

IMAP on the other hand, was designed to allow you to do every fancy thing your client supports while leaving all the mail on the server. This is ideal for a web-based email system, whereby mail never has to be stored anywhere but on the server. It is also useful if you read your mail from many different places (i.e. on the web, from Outlook at the office, from Eudora at home, from your laptop on the go, from your mobile device, etc).

If you desire to download all your mail onto a laptop or other mobile device so that you can read it without maintaining an internet connection, then your client would have to support that operation. If the client only does that with POP, and not IMAP, then IMAP could cause some issues for you. --Thoric 13:49, 18 August 2006 (UTC)

Interim Mail Access Protocol

I thought IMAP stood for Interim Mail Access Protocol, but citations are needed in any case. If it is "Interim", then "Interim" for what? Until a better system is developed? -- 198.170.2.93 19:26, 6 November 2006 (UTC)

http://tools.ietf.org/html/rfc3501 is cited as the defining document in the lead paragraph, and calls it "Internet Message Access Protocol". -- Rick Block (talk) 13:17, 7 November 2006 (UTC)

The first IMAP (1986) was "interim", and was in fact quickly replaced by IMAP2 (RFC 1064, 1176) the next year. In IMAP2, the "I" in IMAP stood for "interactive". The modern name was introduced in IMAP4 (RFC 1730). -- MRC

OK. I've updated the intro to include both "Interactive Mail Access Protocol" and "Interim Mail Access Protocol" (with references). -- Rick Block (talk) 04:56, 19 November 2006 (UTC)

Disadvantages of IMAP.

Having a section headline 'disadvantages' rather suggests that there ought to be one headed 'advantages' doesn't it? As I suspect that an Advantages section could see the entire article descend into a bun fight between IMAP promoters and detractors, should the disadvantages section be removed in the interests of presenting "just the facts"?

I think the intent is that this section parallels "Advantages over POP3", although most of the cited disadvantages aren't relative to POP3. Deleting this section outright probably isn't quite the right solution, but I agree there's a structural problem. The article could stand a major revision at some point. -- Rick Block (talk) 23:49, 21 March 2007 (UTC)

I believe they are relative to POP3, as this section is pointing out server issues that arise in an IMAP environment that do not arise in a POP3 environment. Speaking as someone who has developed both POP3 and IMAP4 server code from scratch, I know both protocols intimately, and the issues surrounding both. Regardless of this, it is plain to even the most technically naive, that a system which is based around accessing, maintaining and manipulating messages across multiple folders on a mail server via an extensive protocol which allows complex searches (IMAP) is going to be far more complicated and require far more server resources as compared to a protocol which is based upon simple message retrieval, which was not designed around the concept of leaving the messages on the server (POP). --Thoric 01:04, 22 March 2007 (UTC)

I'd agree the first paragraph is relative to POP3. The second and fourth, about server side search and saving a sent message in a server side folder, are not quite so clear (these are capabilities simply not offered by POP3, so calling them disadvantages seems a little curious). Both POP and IMAP clients have to "explicitly request new email message content" (perhaps this is a disadvantage of both IMAP and POP relative to some unnamed proprietary protocol). I believe the point of the original comment is the article should not express either a "pro" or "anti" IMAP POV. -- Rick Block (talk) 02:03, 22 March 2007 (UTC)

Most of this article expresses pro-IMAP POV, the point of maintaining a NPOV is to provide opposing POVs, hence a section outlining disadvantages to IMAP is the only thing which adds some balance to this article. I think the second paragraph is relevant as if the user was using POP, all searches would occur on the client side, and would not involve server-side resources. I do agree that the sections outlining problems using IMAP on mobile devices do not seem to make sense in this section, and should perhaps be in a different section regarding limited/expensive bandwidth access. --Thoric 02:56, 22 March 2007 (UTC)

The whole "disadvantages" section is a bit amateurish, but I couldn't care less. However, I did remove one paragraph saying that one disadvantage of the IMAP email protocol was that it was an email protocol. :-/ — Preceding unsigned comment added by 90.54.24.212 (talk) 20:18, 12 February 2014 (UTC)

Far too much general email discussion

Email has its own article. This one doesn't need to keep bleating on about the general concept. Nor, for that matter, does it need the huge list-o-links to related software. Chris Cunningham 13:35, 3 July 2007 (UTC)

I tend to agree. Although some of this can be bent toward describing IMAP's role among all mail protocols, much of this information isn't peculiar to IMAP or necessary to understanding IMAP. Here's a proposed edit.

The various older specs and "definitions" for IMAP are in the history section; I suggest leaving them out of this one.

==IMAP and other e-mail protocols==

IMAP, or IMAP4, is an application layer Internet protocol operating on port 143 or port 993. IMAP allows an e-mail client to access e-mail on a mail server. The current specification, IMAP version 4 revision 1 (IMAP4rev1), is defined in RFC 3501.

IMAP was designed primarily as a means of reading and searching e-mail that is stored remotely. Mail is delivered to an IMAP server and saved in the server's message store. An e-mail client using IMAP can connect to the server and retrieve summaries or copies of these messages on demand. Many IMAP clients will cache messages locally to improve access speed, but messages remain on the server until explicitly deleted by the client. By contrast, clients using the older Post Office Protocol (POP) usually delete the server's copy as soon as a message is downloaded, although this behavior is not part of the POP specification and might or might not be enforced by the server software. Most e-mail clients support both POP and IMAP for message retrieval.

Many IMAP clients support a disconnected mode for offline use, wherein mailbox changes and outbound messages are sequenced locally. When the client next enters connected mode, these queued changes are sent as a series of IMAP commands and the server's copy of the mailbox is updated.

Although intended for message retrieval, IMAP can be used for sending messages through the use of a designated outbox. However, IMAP clients more commonly use SMTP for message delivery.

IMAP's design and specification allow many different client programs to implement it, and IMAP servers are generally client-neutral. This makes IMAP a popular choice for organizations providing mail service to heterogeneous user populations, whose choices of mail client might vary widely.

– dgc (talk) 07:40, 19 March 2009 (UTC) |unsigned]] comment added by 203.82.42.66 (talk) 08:50, 12 February 2010 (UTC)

References missing

Hello. Some RFCs are mentioned which is good. I added a "noreferences" tag to a section that seem to be lacking a source. It is fine with me to remove or change this tag. I am not a mail scientist, only a user, but I hope this helps. -Susanlesch 20:54, 11 November 2007 (UTC)

Message state information

Is Gmail the only example here? I know that we need to meet notability requirements, and I love Gmail myself but this is almost ridiculous. --Kushal^t 18:17, 29 November 2007 (UTC)

As far as I know, Gmail was the first web based email system to introduce the notion of user defined tags, but this really doesn't have much to do with IMAP (other than being a feature that could be implemented in a client if the server supports user defined keywords). Perhaps the best thing to do is delete the entire sentence. -- Rick Block (talk) 02:33, 30 November 2007 (UTC)

Gmail is a notable service. I would rather have more notable service providers added than delete the one that is there. --Kushal^t 18:36, 30 November 2007 (UTC) (PS: is it implicit from the above sentence that I am a clutterbug I am not.

No question that Gmail is a notable service - but I think the sentence is talking about its web interface, not its IMAP interface. I gather Gmail supports IMAP access [2], but I don't know if it supports user defined keywords through this interface (and doesn't seem to be accepting incoming connections at the moment so I can't check). If it does, then the sentence could be changed to talk about this. -- Rick Block (talk) 01:24, 1 December 2007 (UTC)

Webmail and IMAP

As far back as, at least, 9 August 2008, the first section of this article has been stating

"Many implementations of webmail use IMAP to retrieve e-mail messages from a server and display them within a web browser"

This is incorrect. Webmail acts as a server, not a client. In an interaction between a web browser and a webmail site, the latter is the server, the former is the client, and the exchange is merely in HTTP; IMAP does not enter into it at all! OTOH, if an email client (such as Thunderbird, Outlook or other MUAs which appear like a web browser) fetches mail from a mail server (which may be hotmail.com or any other webmail service which may be providing POP3/IMAP service as an addition to their regular web-based interface), then the communication is done via POP3/IMAP.
In my first edit to this section, I attempted to minimise the edit. However, I could not salvage the paragraph: It seemed to confuse browsers and HTML-capable email clients, amongst other things! And so the paragraph was largely eliminated, instead.--P00r (talk) 06:27, 26 January 2009 (UTC)

The claim was that many web mail servers are implemented using IMAP, in which case the user runs a web browser which communicates to a web server using HTTP but the web server then uses IMAP to talk to a mail store which actually hosts the user's mail. SquirrelMail, IMP, and (likely) any web mail server using Sun's JavaMail API are implemented this way. It is perhaps common now for mail stores to natively expose web interfaces in which case the web interface and IMAP interface likely both use some server specific mechanism (generally an internal API or database query) to directly access the user's mail. The point is that IMAP can be (and is) used both as a client retrieval protocol directly by end user mail clients and as a server to server protocol. If anyone would like to clarify this in the article that'd be great. References would help. -- Rick Block (talk) 14:35, 26 January 2009 (UTC)

IMAP supports all types of facilities incorporated in the system

IMAP Disadvantages w.r.t. POP

I think the most important disadvantage of IMAP when compared with POP is that the client has to remain connected to the server at all times when reading or manipulating mail. The local store on the client is considered a "cache" and not an offline mail store, and is likely to be incomplete. If the server goes down or becomes unreachable for any reason, the user potentially loses access to all of their historical mail until the server is accessible again. It's also a useless protocol for those whose Internet access charges are based on duration of the connection, e.g. mobile users, or those using metered dial-up services. It can also be very frustrating when the connection to the server is extremely slow. None of these points are mentioned in the article. 86.141.40.218 (talk) 22:37, 5 April 2010 (UTC)

Thanks! You have saved me a big headache. --Pawyilee (talk) 04:40, 26 December 2011 (UTC)

The reason why none of those points are mentioned in the article is, I will hazard, because none of them are true. — Preceding unsigned comment added by 90.54.24.212 (talk) 20:21, 12 February 2014 (UTC)

IMAPS

"IMAPS" (IMAP over SSL) redirects here, but the article doesn't seem to discuss it at all. - dcljr (talk) 12:00, 20 May 2011 (UTC)

Y Done Added a sentence to the section discussing TCP ports. There are no other differences. — Vano 17:14, 7 December 2011 (UTC)

Multiple clients simultaneously connected to the same mailbox

What are the the means to detect others' changes and eliminate race conditions? I searched high and low with no results on synchronization schemes. — Vano 17:00, 7 December 2011 (UTC)

It's right there in the IMAP RFC. Unsolicited untagged responses about new messages, flag changes and expunges are sent by the IMAP server to all clients that have the mailbox open, regardless of which client (if any) did the changes. Race conditions aren't really anything to worry about normally, because the protocol pretty much avoids them in most cases. There is CONDSTORE (RFC 4551) extension if you want to make sure there are no race conditions when modifying message flags. QRESYNC (RFC 5162) is also about synchronization, but it's not so much about syncing between clients while logged in. TimoSirainen (talk) 12:19, 22 December 2011 (UTC)

Added sentence to refer the reader to a relevant part of RFC3501. -- GWH -- — Preceding unsigned comment added by 81.149.136.94 (talk) 08:40, 1 February 2012 (UTC)

I dropped the Dispute tag, since I think the added sentence provides sufficient documentation, although it might be better as a reference. — Preceding unsigned comment added by Wcoole (talk • contribs) 21:27, 2 March 2012 (UTC)

The following statement -- The POP protocol requires the currently connected client to be the only client connected to the mailbox is incorrect. While the POP3 protocol does not describe concurrent access, it also does not specify that it requires exclusive access. I've changed the section on simultaneous access to instead be about reporting external changes, because that is the only real difference here -- that POP provides a "static" view of the mailbox, and IMAP provides a "real time" view --Thoric (talk) 17:03, 7 February 2023 (UTC)

the whole article

the whole article is unsourced POV rubbish, show some references or I will be removing a lot more in the next week --intraining ^{Jack In} 12:49, 14 January 2013 (UTC)

• agree. IMAP has progressed enormously and many of its RFCs and extensions are not even mentioned here (ex. 4155, 4314, 4467, 4468, 4469, 4550, 5550). Very poor presentation of the protocol, imho. --Ank99 (talk) 14:23, 24 August 2013 (UTC)

Hi

Hi — Preceding unsigned comment added by 58.111.84.198 (talk) 09:23, 26 January 2014 (UTC)

Adoption

I am curious about the adoption level of IMAP. For instance, what proportion of email users use it? And, for comparison, what proportion use POP (or other protocols, if there are any of significance)? Similarly, what proportion of email service providers support IMAP (either instead of or in addition to POP)? Is IMAP usage increasing or decreasing (both in terms of total adoption and also as a proportion of the industry)? That is, is it a dwindling protocol that may soon be marginalized out of existence?

I used POP exclusively for 15 years then began switching to IMAP about a decade ago. For me, the key advantage of IMAP over POP was the greater ease of maintaining synchronicity when viewing the contents of a mailbox from multiple clients. (That is, IMAP makes it easier for me to ensure that the state of my mailboxes when viewed from my email client on the desktop at work will match the content I see when viewing with the client my personal laptop.) I did not see this advantage addressed directly. (Then again, perhaps POP is actually just as capable in that respect, but I have merely not been email-saavy enough to learn to use it that way.) Starling2001 (talk) 17:33, 21 May 2014 (UTC)

Not niche

I've readded the EL to a doctoral thesis because it not "niche", rather it fulfills the need for information lacking in the article, namely mobility and extensions, as ELs were intended to do. The abstract and TOC of the link speak for themselves: Even the seven percent devoted to the Trojita email client is largely about implementation of the comprehensive and scholarly coverage of IMAPs mobile extensions that are, BTW, well laid out in the other ninety-three percent. — CpiralCpiral 14:41, 22 September 2014 (UTC)

email syntax highlighting lost

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for 'email' was unfortunately dropped, as can be seen with the plain text formatting on this page. Are there other pages using this syntax? If we want email syntax highlight support again, it will need to be added to Pygments. I havent been able to find any handler in Pygments which is a suitable fallback for 'email'. John Vandenberg ^(chat) 03:38, 13 July 2015 (UTC)

'http' might be an alternative that works, but probably only in some cases, but especially when 'email' was used for non-email source such as here. John Vandenberg ^(chat) 03:54, 13 July 2015 (UTC)

Extensions section

I suggest we add an Extensions section. Basically a list with a short description of each and some link. I think there are a lot of these, both with RFC and without (the notable ones). Any problem with this? Viktor Söderqvist (talk) 11:08, 15 February 2019 (UTC)