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. >
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 accessservers 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 dovecotauthenticates, 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 regardingthe 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 printthem!), 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 startaccessing 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 thoughtson 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?).
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20040618/fe7fd52e/attachment-0001.bin>
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.