Please sign the IMAP for Gmail petition I found there
Thank you very much.
I have a question kael: What is the point of this? As you know
Sergey Brin has said that Google will eventually support IMAP.
And my guess is that it will be for a fee, which is perfectly
fine. In the meantime, I recommend that you put your energy into
supporting and promoting tools and providers who are *already*
providing IMAP and other standards-based server-side solutions,
especially IMAP keywords (labels), Sieve, shared IMAP mailboxes,
and the intertwingling of RSS/Atom and IMAP.
Kael, your petition has been approved:
Use a full address (ie including the "@gmail.com") to log in. Captcha
("type the warped word you see here") is fully supported. Tested with
Thunderbird, AppleMail, and GNUS.
It's amazing to use this server !!!
Thanks you very much !!! :-) :-) :-)
I don't understand everything. If I log on with my password I can
see some of the "Inbox" mails but not all and some are duplicated. If I
log on with Captcha I can see a "Captcha" mailbox but no mails in it nor
in "Inbox" except one for a request. But I don't know what is it made for.
Please, can you explain how it works . More precisely I would like to
know how the labels are managed.
Thank you very much. You're a genius !
> I have a question kael: What is the point of this? As you know
> Sergey Brin has said that Google will eventually support IMAP.
> And my guess is that it will be for a fee, which is perfectly
> fine. In the meantime, I recommend that you put your energy into
> supporting and promoting tools and providers who are *already*
> providing IMAP and other standards-based server-side solutions,
> especially IMAP keywords (labels), Sieve, shared IMAP mailboxes,
> and the intertwingling of RSS/Atom and IMAP.
You forgot IMAP urls. ;-)
> ---- Original Message ----
> From: "Adam Megacz" <ad...@megacz.com>
> Newsgroups: comp.mail.imap
> Sent: Thursday, September 02, 2004 8:57 PM
> Subject: Re: IMAP for Gmail
>> "kael" <ka...@alussinan.org> writes:
>>> Please sign the IMAP for Gmail petition I found there
>>> http://google.logenv.org/ .
>> Kael, your petition has been approved:
>> Use a full address (ie including the "@gmail.com") to log in. Captcha
>> ("type the warped word you see here") is fully supported. Tested with
>> Thunderbird, AppleMail, and GNUS.
> It's amazing to use this server !!!
> Thanks you very much !!! :-) :-) :-)
And thank _YOU_ for sending your Gmail userid and password to someone who
you've never heard of before! :-)
Not to mention transmitting it in the clear, unencrypted, over the Internet.
Ah, how naive some people are.
I'm almost positive that your Windows PC is also infested with spyware and
at least a couple of viruses.
> And thank _YOU_ for sending your Gmail userid and password to someone
> who you've never heard of before! :-)
I don't give a f*£$ c'os I have 4 accounts and mostly because I don't
use them. Actually, I use one... I uploaded IMAP mailing list archive
and added keywords. It's nice for IMAP learning. I'm gonna learn IMAP
thanks to Gmail. lol
> Not to mention transmitting it in the clear, unencrypted, over the
> Ah, how naive some people are.
Always equal to yourself. :p
> I'm almost positive that your Windows PC is also infested with spyware
> and at least a couple of viruses.
And you are "over-NNTP lucid" ! Amazing !
Take it easy, Sam.
Do a google search on me. I wrote parts of the compiler used to build
most Linux distros. I have write access to the GCC master repository.
If I really wanted to hack peoples' machines, slipping malicious code
into the compiler would have been a much better way to go about it.
My IMAP-to-GMail proxy is still under development; right now it has
quite a few shortcomings (read-only, and it doesn't refresh the cached
header set as often as it should). It doesn't use libgmail.py.
I'm toying with the idea of open-sourcing it, although the increased
usage would probably just encourage google to break it (and it being
open source would clearly help them figure out how). OTOH it might
help me popularize my new mail server architecture in the meantime
(which definately will be open source).
I dunno. I have a friend who works for Google; I'll see if she can
feel out their reaction.
Right now they aren't managed at all. Pretty soon each label will be
a mailbox (messages can appear in multiple mailboxes).
> I'm toying with the idea of open-sourcing it, although the increased
> usage would probably just encourage google to break it (and it being
> open source would clearly help them figure out how).
I think that's unlikely. For the most part I really doubt Google gives
a stuff about projects like this, well for the moment anyway, maybe if
they start eating into the revenue stream when/if they implement IMAP
for real, but that's unlikely too, because the people who think it's
worth it (without stuffing around with extra utilities) will always be
prepared to pay for it. It's only a matter of time before another IMAP
implementation appears (yeah, yeah, it's a TODO for libgmail), you
might as well get credit for being the first.
From my reading of the IMAP specification & knowledge of Gmail the
most difficult part is not at the Gmail end of things--it's fitting
the IMAP peg into the Gmail hole, so there's probably not too much
Google could change in the Gmail interface that would be too difficult
I'd recommend open-sourcing it and see what happens. I'll even offer
you a money-back guarantee on what you paid for my advice if Google
turns out to make your life difficult. (Note: Offer may not be valid
in your location.)
--Phil. (Author of libgmail, in case that wasn't obvious...)
Sorry, Phil ;) I originally hacked up a version that invoked your
archive.py. Needless to say it was awfully inefficient, mainly
because of my poor choice of an interface rather than anything
inherent in libgmail! I should have instead said "implemented
interpreter for an unrelated project, which definately helped with
parsing GMail's replies.
By the way, does Google change the mappings you have in the
auto-generated constants.py often? I hardcoded them in GMail.java, so
I'm wondering if that's a long-term bad idea. OTOH I guess they could
change anything at any time...
Thanks again for all your hard work; if I had had to figure out the
GMail "protocol" myself instead of deducing it from libgmail.py, it
would have taken me *waaaay* longer to do this.
> implementation appears (yeah, yeah, it's a TODO for libgmail), you
I think the biggest problem you'll encounter is lack of a flexible
implementation of the server side of IMAP. Implementing the *server*
side of IMAP is a huge undertaking, and I've found very few
implementations flexible enough to serve IMAP from anything other than
local storage -- most of them are written in such a style that
pervasively assumes that iterating over the headers of every message
in a mailbox is a "cheap" operation.
This is also the reason why there are plenty of NNTP and POP proxies
for other protocols (ie nntp2rss, etc), but few or no IMAP proxies
There's actually one commercial company (can't remember the name) that
has a whole line of IMAP-to-$FOO proxies, but that's about it.
> I think the biggest problem you'll encounter is lack of a flexible
> implementation of the server side of IMAP. Implementing the *server*
> side of IMAP is a huge undertaking, and I've found very few
> implementations flexible enough to serve IMAP from anything other than
> local storage -- most of them are written in such a style that
> pervasively assumes that iterating over the headers of every message
> in a mailbox is a "cheap" operation.
If you're really interested about doing that, I'd suggest looking at
Dovecot's 1.0-test releases. It avoids opening messages as long as
possible and can do local caching of some useful information, although in
gmail case it might even be useful to cache entire messages.
I think Dovecot APIs should be flexible enough to make it easy enough to
implement. One annoying thing is that it'd have to use blocking sockets.
Maybe some day I'll figure out how to write simple to use nonblocking APIs.
Can you point me to the API documentation?
It was down for about six hours the night before you posted
this... should be back now.
No real documentation yet, but src/lib-storage/mail-storage.h contains it
all and is pretty well commented. You'd probably want to base it on
existing indexing code (which I'll probably make required in future).
Then the only difficult part is syncing gmail storage with local
indexes, ie. figure out what's changed in gmail and send local changes to
To tell you the truth, unless IMAP is supported there's no practical
use Gmail in a first place, cmon Spymac give 10GBs with the very same
POP. And message download from them seems to be much faster
If you don't like Gmail, don't use it. There are plenty of decent
IMAP providers and more and more popping up every day -- if I
wanted to, I could spend all my time keeping my IMAP Service
Providers page up to date!
Good luck finding an IMAP provider you like,
With Google Employees condescending marketing style, it's probably the
best thing that can be done: not using Gmail except for personal junk.
And when they implement IMAP in Gmail they will _give the impression_
that they invented IMAP.
So I can find a reason for Gmail implementing IMAP, can you find
a reason for them net too? And make it reasonable too, and not some
overprotective stuff you wrote before.
Maybe the reason that Gmail hasn't implemented IMAP is because
they haven't yet figured out a good way to reflect their mail
store onto an IMAP mail store. One possibility is to have all the
messages be in one IMAP box and each label be an IMAP keyword.
But AFAIK there are not many IMAP clients that this would work
with. The most popular IMAP client is Moz Suite/Thunderbird and
it supports 5 IMAP keywords and each message can have at most 1
keyword. One of the most respected IMAP clients is Mulberry and
it supports 8 IMAP keywords. Another IMAP client (and the one I
use as my primary IMAP client) is Pine. It supports an unlimited
number of IMAP keywords and each message can have multiple
keywords. I've been trying to emulate Gmail with Pine and IMAP
keywords and it is not easy.
My question to you Igal.Hunter is: How should Gmail map their
mail store onto an IMAP mail store so that users can keep their
labels in sync?
It's a hard problem, but it's not insurmountable and I'm hoping
that Gmail's solution will help to drive the evolution of IMAP
clients by using a lot of currently underused IMAP features,
including IMAP keywords and IMAP annotations.
Here's a prediction: Since there aren't any IMAP clients that
would really work with Gmail right now, I bet that Gmail is
creating their own desktop IMAP client and that they are going to
release Gmail server-side IMAP simultaneously with the Gmail IMAP
client. (You heard it here first :-))
Infinite Ink: <http://www.ii.com/>
Procmail Quick Start: <http://www.ii.com/internet/robots/procmail/qs/>
IMAP Service Providers: <http://www.ii.com/internet/messaging/imap/isps/>
All About Pine: <http://www.ii.com/internet/messaging/pine/>
A Google IMAP client ! Oh shit ! (Exceptionally vulgar)
> Another IMAP client (and the one I
> use as my primary IMAP client) is Pine. It supports an unlimited
> number of IMAP keywords and each message can have multiple
I see you are using it on Mac OS X. Does Pine support double-byte character
sets like Chinese and Japanese?
Pine "somewhat" supports East Asian character sets. By "somewhat", I mean
that it can be used quite successfully with East Asian character sets, but
since it doesn't specifically know about double-byte characters it treats
them as pairs of single-byte characters. This becomes an issue when
editing the text; it's easy to put the cursor in the middle of a character
and insert/delete at that point.
Other than that, however, Pine handles East Asian character sets rather
well. It knows how to convert between ISO-2022-JP strings and EUC-JP (on
UNIX) or Shift-JIS (on Windows). If you have Pine configured for one of
the East Asian character sets (BIG5, GB2312, ISO-2022-JP, EUC-KR) and
receive a message in UTF-8, Pine will convert from UTF-8 into your local
character set (actually, Pine does this for European languages as well).
-- Mark --
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Your idea is very interesting but probably too optimistic.
If G$$G released an unlimited storage on 1st April, it was mostly *not*
to provide an IMAP access - at least this is what I think.
The unlimited storage is only a diversion. IMAP is the most wanted
feature  but people may finally forget they want an IMAP access.
Also, an unlimited storage is very useful for people who don't know how
to quote correctly and include all the messages they're replying to, all
the more since they can write RTF messages.
Not to mention that "Google has pretty much assured themselves that most
of its users won't stray from their Gmail accounts now" -
IMAP is uncompatible with their business model... I mean, with their
"philosphy" - my foot :-/ - they have no more philosphy now, except the
/port 80/ one.
So I don't think it's only a technical problem. They could easily
display labels into folders, no matter with duplicates, or they could
hardly work with IETF IMAP working groups to try to develop an
extension. Are there any Google employees in those working groups ?
Or they could work to fix the bug 114656 - allow arbitrary number of
labels  unless they would need to buy the Mozilla Foundation before ?
They probably don't care about IMAP keywords or about the ANNOTATEMORE
The only things they care about are their ads, and if they created an
IMAP client, they will probably put "targetted" (sic) ads in it.
Google was mostly an algorithm  but since it transformed into G$$G,
"[...] the honeymoon is over" .
I for one hope this algorithm could be used with IMAP - a kind of
PERTINENCE algorithm, in cunjunction with the SORT and THREAD extensions.
But maybe I'm completely wrong. Maybe G$$G will release an IMAP access
and we will be able to APPEND a 4 GB message and read it with a future
STREAMING extension. I would probably use a Gmail account... to store
audio and video data in there unlimited storage.
If Yahoo! provided an IMAP access, maybe G$$G will do the same ?
Two very interesting RFCs have been published. :o)
*Requirements for Morality Sections in Routing Area Drafts*
*UTF-9 and UTF-18 Efficient Transformation Formats of Unicode*