[Dovecot] IMAP and webmail applications
I've been hunting around for a webmail application other than squirrelmail for reasons that really don't matter.
But I'm seeing that a lot of these applications tend to sometimes access servers via IMAP, but they always seem to have a touch more information needed than might be for an IMAP session.
An example is openwebmail. It authenticates very similar to how dovecot authenticates, with a userdb and passdb specifications. It reads directly off the disk for some of it's activities.
As for squirrelmail, they seem to want a lot of information regarding the mail architecture (mbox, maildir, folder locations...) and I don't really see where this could come into play with an IMAP implimentation.
So, not actually having read all 82 pages of RFC 2060 (but I did print them!), I'm trying to see what I might miss if I were to attempt a web mail application that was based entirely upon IMAPv4 with the only information known prior to connection is the server name. Kind of like my mail client.
Will I get into trouble with mail directories/folders if I start accessing different IMAP servers other than dovecot? Can I discover this without any hints from the user?
I'm not sure exactly what I'm asking for here, other than some thoughts on what I might have to watch out for or do without (when comparing to squirrelmail as an example). I know I'll have to do something different if someone wants an addressbook, but I'm not there yet.
i thought squirrelmail would be way too much of an overkill for my needs also but i went for it. i'm using debian and i got the squirrelmail package installed and working within 15 minutes. what really makes life easy is that squirrelmail comes with a configuration utility (squirrelmail-configure). it was very easy to get things configured without worry about a lot of conf files :) i also like the many plugins that people have created for squirrelmail. it's also very simple to add these plugins into squirrelmail using squirrelmail-configure.
i had originally been ssh and mutt to check my mail, but i decided it be nice to have a web front-end and squirrelmail /apache /dovecot /procmail /spamassassin /gotmail /getmail /fetchyahoo have been a good mix for me.
the hardest part for me was figuring out procmail and not squirrelmail :)
my 2 cents, dan
I've been hunting around for a webmail application other than squirrelmail for reasons that really don't matter.
But I'm seeing that a lot of these applications tend to sometimes access servers via IMAP, but they always seem to have a touch more information needed than might be for an IMAP session.
An example is openwebmail. It authenticates very similar to how dovecot authenticates, with a userdb and passdb specifications. It reads directly off the disk for some of it's activities.
As for squirrelmail, they seem to want a lot of information regarding the mail architecture (mbox, maildir, folder locations...) and I don't really see where this could come into play with an IMAP implimentation.
So, not actually having read all 82 pages of RFC 2060 (but I did print them!), I'm trying to see what I might miss if I were to attempt a web mail application that was based entirely upon IMAPv4 with the only information known prior to connection is the server name. Kind of like my mail client.
Will I get into trouble with mail directories/folders if I start accessing different IMAP servers other than dovecot? Can I discover this without any hints from the user?
I'm not sure exactly what I'm asking for here, other than some thoughts on what I might have to watch out for or do without (when comparing to squirrelmail as an example). I know I'll have to do something different if someone wants an addressbook, but I'm not there yet.
Dan Wang wrote:
i thought squirrelmail would be way too much of an overkill for my needs also but i went for it. i'm using debian and i got the squirrelmail package installed and working within 15 minutes. what really makes life easy is that squirrelmail comes with a configuration utility (squirrelmail-configure). it was very easy to get things configured without worry about a lot of conf files :) i also like the many plugins that people have created for squirrelmail. it's also very simple to add these plugins into squirrelmail using squirrelmail-configure.
i had originally been ssh and mutt to check my mail, but i decided it be nice to have a web front-end and squirrelmail /apache /dovecot /procmail /spamassassin /gotmail /getmail /fetchyahoo have been a good mix for me.
the hardest part for me was figuring out procmail and not squirrelmail :)
squirrelmails nice. I'm not going to knock it. In fact, I consider it right to be an example of what to follow.
But my interests are to write something for compatability with mod_perl and HTML::Mason so give me a system that will be much faster than squirrelmail and easier to include in web sites. (HTML::Mason would allow you to write the entire webmail application as an object to include in a page...) The advantage of HTML::Mason over PHP is that it's very easy to cache pages in addition to the advantages of mod_perl over PHP (unless you use Zope?).
I haven't worked with Mason but I know a bit of what it does and it seems you want more integration into an existing website. I don't have any expertise with performance between perl and php so I can't comment on that :)
The only other thing I can add to the conversation is my interest in looking at imapproxy or something similar to allow caching of imap and improve web client performance. I haven't tried it yet, but it's something I'll goof around with.
i thought squirrelmail would be way too much of an overkill for my needs also but i went for it. i'm using debian and i got the squirrelmail
easy is that squirrelmail comes with a configuration utility (squirrelmail-configure). it was very easy to get things configured without worry about a lot of conf files :) i also like the many
Dan Wang wrote: package installed and working within 15 minutes. what really makes life plugins
that people have created for squirrelmail. it's also very simple to add these plugins into squirrelmail using squirrelmail-configure. i had originally been ssh and mutt to check my mail, but i decided it be nice to have a web front-end and squirrelmail /apache /dovecot /procmail /spamassassin /gotmail /getmail /fetchyahoo have been a good mix for me. the hardest part for me was figuring out procmail and not squirrelmail :)
squirrelmails nice. I'm not going to knock it. In fact, I consider it right to be an example of what to follow.
But my interests are to write something for compatability with mod_perl and HTML::Mason so give me a system that will be much faster than squirrelmail and easier to include in web sites. (HTML::Mason would allow you to write the entire webmail application as an object to include in a page...) The advantage of HTML::Mason over PHP is that it's very easy to cache pages in addition to the advantages of mod_perl over PHP (unless you use Zope?).
On Fri, 2004-06-18 at 05:21, Tom Allison wrote:
As for squirrelmail, they seem to want a lot of information regarding the mail architecture (mbox, maildir, folder locations...) and I don't really see where this could come into play with an IMAP implimentation.
I suppose it tries to work around some issues with different server implementations. It really shouldn't need them if it and server were both fully IMAP compatible.
Well, except for the folder locations. It needs to know what your sent-mail etc. boxes are named.
Timo Sirainen wrote:
On Fri, 2004-06-18 at 05:21, Tom Allison wrote:
As for squirrelmail, they seem to want a lot of information regarding the mail architecture (mbox, maildir, folder locations...) and I don't really see where this could come into play with an IMAP implimentation.
I suppose it tries to work around some issues with different server implementations. It really shouldn't need them if it and server were both fully IMAP compatible.
Well, except for the folder locations. It needs to know what your sent-mail etc. boxes are named.
OK, I guess that's about the only one I really got stuck on, but unless someone's being difficult or esoteric I think everyone uses the set: inbox, sent, trash, drafts with some variation on capitalization.
IIRC, Kmail used something unexpected by me, but I think it was ~/Mail/ instead of ~/Maildir or ~/mail. Minor, but somewhat predictable.
On Fri, Jun 18, 2004 at 06:07:16AM -0400, Tom Allison wrote:
Timo Sirainen wrote:
On Fri, 2004-06-18 at 05:21, Tom Allison wrote:
As for squirrelmail, they seem to want a lot of information regarding the mail architecture (mbox, maildir, folder locations...) and I don't really see where this could come into play with an IMAP implimentation.
I suppose it tries to work around some issues with different server implementations. It really shouldn't need them if it and server were both fully IMAP compatible.
Well, except for the folder locations. It needs to know what your sent-mail etc. boxes are named.
OK, I guess that's about the only one I really got stuck on, but unless someone's being difficult or esoteric I think everyone uses the set: inbox, sent, trash, drafts with some variation on capitalization.
We have a webmail application developed internally here that is based on IMAP access to remote servers (well, the "remote server" might be and usually is a server sitting in the same rack). It stores its preferences inside of a specially named mail folder on the IMAP server. When you log into the webmail appplication, you tell it the IMAP server and login info, and it finds and fetches the preferences stored there. No special protocols other than IMAP needed.
(OTOH, it does need other, non-IMAP access in order to update delivery rules and delivery scripts. But that's a different arena.)
mm
participants (5)
-
Dan Wang
-
durango99
-
Mark E. Mallett
-
Timo Sirainen
-
Tom Allison