Talk:Internet Message Access Protocol

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

message: 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)
replies: text: What up yo 2600:1016:B015:6DBB:0:46:E281:D701 (talk) 15:47, 8 January 2024 (UTC)
thread_title: Cleanup, Expert Review tags?

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title: Disadvantages of IMAP

message: 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  is working on extending IMAP and SMTP to make them more suitable for mobile users.--C960657 (talk) 12:43, 9 March 2008 (UTC)
thread_title: Traffic Reduction for IMAP?

message: 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)
thread_title: Examples?

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Disadvantages of IMAP. 

message: 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)
thread_title: References missing

message: 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. --Kushalt 18:17, 29 November 2007 (UTC)
replies: text: 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)

text: 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 , 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)
thread_title:  Message state information 

message: 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)
replies: text: 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)
thread_title:  Webmail and IMAP 

message: 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)
replies: text: Thanks! You have saved me a big headache. --Pawyilee (talk) 04:40, 26 December 2011 (UTC)

text: 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)
thread_title:  IMAP Disadvantages w.r.t. POP 

message: "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)
replies: text: Y Done Added a sentence to the section discussing TCP ports. There are no other differences. — Vano 17:14, 7 December 2011 (UTC)
thread_title:  IMAPS 

message: 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)
replies: text: 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)
thread_title:  Multiple clients simultaneously connected to the same mailbox 

message: 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)
replies: text: * 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)
thread_title:  the whole article 

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

message: 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)
thread_title:  Adoption 

message: 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)
thread_title:  Not niche 

message: 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)
replies: text: '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)
thread_title:  email syntax highlighting lost 

message: 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)
thread_title:  Extensions section