Talk:Internet Message Access Protocol
From Wikipedia, the free encyclopedia
Contents |
[edit] 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
[edit] 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.
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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. --Kushalt 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. --Kushalt 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)