Re: OT: advanced mailbox protocols
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday, September 28 at 01:24 PM, quoth Enrico Weigelt:
>>> I'm currently thinking about designing a new one, which should
>>> handle lots of things which (AFAIK) aren't supported by pop or
>>> imap,
>>> for example:
>>>
>>> * (full text) searching
>>
>> IMAP does this one. Mutt supports it as well; search for '=b text'
>
> Ah, cool :) How exactly does it work ?
Read RFC 3501, section 6.4.4
>>> * direct access to metadata and single message parts
>>
>> IMAP does this as well.
>
> So, you can tell the server "give me part 1 of Mail XYZ" ?
Yes. Read RFC 3501, section 6.4.5, specifically the
BODY[<section>]<<partial>> syntax.
>>> * storage / encoding abstraction
>>
>> I'm not sure exactly what you mean here, but IMAP does what it sounds
>> like you want here.
>
> A kind of views, but for content. So, ie. the client can tell:
> "give me the HTML part as plain text", "convert to charset XYZ"
> or "cut off the signature".
Ahh, no. This seems like something that would be a bit of a bad idea,
because it would tend to discourage progress. I like the fact that I
don't have to rely on my ISP to support UTF-8 in order for me to use
it in my email. What would be the purpose of this "feature"? To
theoretically make it so that people NEVER have to update their buggy,
easy-to-hack clients (a. la. Outlook Express 6.0), by instead
expecting ISP's to do all the supporting of new features? Um, no.
>>> * update notification
>>
>> IMAP does this.
>
> Yeah, I know there's an notification for new email.
> But does it also tell that an certain mail has changed etc
> (so an complete reload of the index can be circumvented).
>
> For example: I'm using mutt (direct) and seamonkey (imap) to
> go on the same mailboxes. When flushing the mbox in mutt, I'd
> like to get seamonkey informed immediately.
Yes, IMAP does this. Read RFC 3501, section 5.2.
>>> * keywording / tagging (listings by keywords, etc)
>>
>> IMAP supports arbitrary user-defined tags, and I believe it supports
>> searching for tags, but I haven't double-checked.
>
> hmm, do you have any source/howto how this works ?
>
> For example, I'd like to get mails from/to certain persons get
> tagged (ie. via procmail), ie. friends, customers, ...
> now I want to query for mails with certain tags (ie. "friend")
> and maybe store it as a view / virtual mailbox.
>
> Is this possible w/ IMAP
Procmail has NOTHING to do with IMAP. If you're confusing mail
delivery with retrieval, then you need to do some serious rethinking.
You can use Procmail to do things like add X-Label headers, and then
you can use IMAP to search for those X-Label headers (or, heck, call
it the X-Weigelt header, if X-Label doesn't do it for you), but that
has absolutely nothing to do with the mail retrieval protocol. The
arbitrary tags I was speaking of are stored as IMAP-server-specific
meta-data, not as something that procmail can twiddle in the message
when delivering. As far as protocol-based arbitrary tags (i.e. things
that do not modify the content of the message in order to tag it),
read RFC 2060, section 7.1, specifically the bit about the
PERMANENTFLAGS response code.
And as I said in my previous email, no, IMAP does not do "views" or
"virtual mailboxes".
>>> * compression
>>
>> As in back-end compression, or communication compression?
>> Communication compression is a recent IMAP extension (lookup the
>> LEMONADE project).
>
> Cool. Is this already supported in mutt ?
No. Mutt's IMAP support is rather simplistic and finicky (check out
what it does if your IMAP server doesn't support the CHILDREN
extension, or if your IMAP server goes offline for a bit, if you don't
believe me). Supporting very recently published draft extensions to
IMAP is not something *anybody* is really in the business of doing. My
point was not to say "and you can do this TODAY by toggling this
setting!" but rather to say "designing a new protocol to do this is a
bad idea, because what you desire is already a lot further along and
closer to being a reality (and an actual standard) than starting from
scratch."
>>> * virtual mailboxes (ie. defined upon queries)
>>
>> Currently not available in any existing protocol.
>
> hmm, would it be hard to extend IMAP for that ?
Many people have thought about it. I don't think it would be too hard,
conceptually. There are many issues that you'd have to work out, such
as persistence, how to specify the contents of a virtual folder, and
what happens if you try to delete something from a virtual folder
that's defined by specific attributes, among other things. The
extension would likely be extremely complex. Then, of course, you have
to write your own mail client to support the server you just wrote.
>> As for message composing, I have no idea what you're getting at.
>
> Create a new mail in the postponed box and change it multiple times
> (ie. upload attachements or edit text later)
... Is there some problem with the current implementation of postponed
messages in existing IMAP-based email clients that I'm not aware of?
> Okay, I've now learned that IMAP has much more capabilities than I
> ever expected :)
>
> Maybe someone could point some problems of the IMAP protocol.
;) Perhaps, before volunteering to design a new email protocol, one
should be familiar with the existing protocols. I suggest a thorough
reading of RFC 3501 (http://www.ietf.org/rfc/rfc3501.txt), RFC 2060
(http://www.ietf.org/rfc/rfc2060.txt), and probably many of the rest
of the documents linked off of this page:
http://www.imap.org/biblio.html
And to educate yourself about POP3, read RFC 1939
(http://www.ietf.org/rfc/rfc1939.txt), RFC 1725
(http://www.ietf.org/rfc/rfc1725.txt), and perhaps RFC 1081 for a bit
of history (http://www.ietf.org/rfc/rfc1081.txt).
You are likely to hear badmouthing of the IMAP protocol that goes
along the lines of "IMAP isn't good for slow connections" and such.
This is poppycock, and is usually expounded upon by people whose IMAP
clients/servers haven't implemented/supported the entire IMAP protocol
(it can be significantly more efficient than POP3, and thus better for
slow connections). One criticism I have heard of the IMAP protocol is
that it is so feature-rich that most mail clients (and many IMAP
servers) simply do not support the entire protocol (leading to many
people becoming unjustly upset with it), but this cannot be IMAP's
fault; it tries to be all things to all people, and while it does its
job well, actual implementations suffer from human laziness, and
there's not much you can really do about that. The only serious
criticism I have heard is that because of all of its features, IMAP
servers tend to require more resources than a more simplistic protocol
like POP3, thus making some ISPs reluctant to support it. This
criticism is not going to be addressed by adding *MORE* features.
Many people, upon seeing Gmail's interface, suddenly think to
themselves "my god, that's EXACTLY how I wish I could manage my
email!". In rare cases, the person had already thought that. This is a
matter that, in my opinion, is not the protocol's responsibility.
Certainly one *could* add virtual folders and such to the protocol,
though it would add considerable overhead to the server. However, I
tend to think that this is more appropriately the mail client's
responsibility. Take for example Apple's Mail.app program, which has
implemented virtual folders (using their "Spotlight" technology) with
*any* protocol or storage backend. The only reason you're probably
wishing it was in the protocol is because you perceive mail clients
like mutt as thin veneers over the underlying protocol. And while
there is some truth to this, a new protocol isn't going to help; you
would still have to rewrite large amounts of code in the mail client
to support such a protocol feature, only you'd have to write your own
server as well. If you're unsatisfied with mutt's IMAP support or it's
rather direct view of folders, then I think directing your attention
to improving the client is probably a better direction for your
energy.
~Kyle
- --
I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forgo their use.
-- Gallileo
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iD8DBQFFG95kBkIOoMqOI14RAtsnAKCuWmyeQJx93wuTkKQ5K2QgrCPQwgCfTWKr
j4QNsEjhTZDPR0lWpVD1R6w=
=zRBB
-----END PGP SIGNATURE-----