[Dovecot] Documentation
Hello,
I have added a few questions and answers to the wiki, about stuff that
caused me long hunts when trying to set up dovecot with maildir storage.
Some of it I have gleaned from the source. Some of it is actually already
documented, but I had not been able to spot it when I needed it.
At the time of writing I had a particular advantage: I did not know, or
had mostly forgotten, the peculiarities of the imap protocol. I say
'advantage', because I think that when writing documentation it is
important, yet difficult, to see things from the perspective of a user
that is quite ignorant, although not stupid. These need the documentation
most, and they are in majority.
(Some will say the "stupid" ones are in majority, but writing for them is
almost futile anyway. Anyway, I doubt they are a majority; average
intelligence is adequate for all normal tasks. What we often judge and
condemn as "stupidity" is most often the result of a different perspective
that _we_ are too limited to understand.)
Since I am not yet too spoiled, and yet recently had my hands (or rather
my eyes) in the source, this may be a golden opportunity to produce some
more documentation.
I therefore urge you to suggest what I should look at and write about. Do
you have any ideas about how the documentation should be organized? some
questions are not strictly dovecot or even imap questions, yet they arise
quite naturally for an administrator that is migrating to dovecot or to
imap in general.
The existing migration documentation was not as usefull to me as it could
have been because I was both migrating to imap from a non-imap solutions,
and from mbox to maildir, both at the same time. That placed me in a
particularly "ignorant" position.
It is quite likely that much of what I write is not exactly true. I have
suggested procmail as a delivery agent for maildir stores, because it is
the only one I know about at the moment. I just occurred to me that I have
not even checked if /bin/mail (on GNU/Linux systems) can do it. Any ideas?
I have not (yet) found out anything about the CONTROL= part of the mail
environment. Should I write something about it? Is it usefull for system
administrators to know about it? What is it?
Regards
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 2005-07-18 at 20:03 +0200, Enrique wrote:
I therefore urge you to suggest what I should look at and write about. Do
you have any ideas about how the documentation should be organized? some
questions are not strictly dovecot or even imap questions, yet they arise
quite naturally for an administrator that is migrating to dovecot or to
imap in general.
I've been thinking of doing some major wiki restructuring some day before v1.0 release. So that in main page there would be something like:
- Information about IMAP, POP3, SMTP and mail servers in general
- Installing and setting up a simple Dovecot installation
- Full guide to setting up a new system
- Migration from existing systems
- other servers
- mbox <-> maildir
- pop3 -> imap
- Troubleshooting
- Supported features / current status / TODO
Troubleshooting should start with generic "How do I find out what the problem is?" and then several subsections with specific problems.
I'm not sure if any of this helps with what you wanted to write though, since it is going to be a pretty large change.. :)
I have not (yet) found out anything about the CONTROL= part of the mail
environment. Should I write something about it? Is it usefull for system
administrators to know about it? What is it?
It'd be useful to know since with maildir that's pretty much the only way to reliably implement filesystem quota (set Dovecot's control and index files to a partition without quota enforcing).
May I suggest - lots of real world examples. You can't have too many examples. And one thing to remember is that the programmer never had to learn the program. It's easy to forget that other people don't know certian things. Good docs drastically cuts support email and if you get it right all you'll be getting is feature requests and spam. ;)
I've been thinking of doing some major wiki restructuring some day before v1.0 release. So that in main page there would be something like:
- Information about IMAP, POP3, SMTP and mail servers in general
- Installing and setting up a simple Dovecot installation
- Full guide to setting up a new system
- Migration from existing systems
- other servers
- mbox <-> maildir
- pop3 -> imap
- Troubleshooting
- Supported features / current status / TODO May I suggest an additional section with a full breakdown of what every configuration directive does?
Thanks,
--
Nick Maynard nick.maynard@alumni.doc.ic.ac.uk http://www.fluffybrain.com
It could use a good feature/overview page.
Nick Maynard wrote:
I've been thinking of doing some major wiki restructuring some day before v1.0 release. So that in main page there would be something like:
- Information about IMAP, POP3, SMTP and mail servers in general
- Installing and setting up a simple Dovecot installation
- Full guide to setting up a new system
- Migration from existing systems
- other servers
- mbox <-> maildir
- pop3 -> imap
- Troubleshooting
- Supported features / current status / TODO
May I suggest an additional section with a full breakdown of what every configuration directive does?
Thanks,
-- Marc Perkel - marc@perkel.com
Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com
On Fri, 22 Jul 2005 16:57:19 +0200, Timo Sirainen tss@iki.fi wrote:
On Mon, 2005-07-18 at 20:03 +0200, Enrique wrote:
I therefore urge you to suggest what I should look at and write about.
Do you have any ideas about how the documentation should be organized? some questions are not strictly dovecot or even imap questions, yet they
arise quite naturally for an administrator that is migrating to dovecot or to imap in general.I've been thinking of doing some major wiki restructuring some day before v1.0 release. So that in main page there would be something like:
- Information about IMAP, POP3, SMTP and mail servers in general
- Installing and setting up a simple Dovecot installation
- Full guide to setting up a new system
- Migration from existing systems
- other servers
- mbox <-> maildir
- pop3 -> imap
- Troubleshooting
- Supported features / current status / TODO
Troubleshooting should start with generic "How do I find out what the problem is?" and then several subsections with specific problems.
I'm not sure if any of this helps with what you wanted to write though, since it is going to be a pretty large change.. :)
Oh that sounds like a nice plan. I just did not know what I wanted to
write, I just wanted to have a realistic hope that anybody would care
about what I write. But of course, I will also have to do a good deal
research to get it nearly right.
I have not (yet) found out anything about the CONTROL= part of the mail environment. Should I write something about it? Is it usefull for system administrators to know about it? What is it?
It'd be useful to know since with maildir that's pretty much the only way to reliably implement filesystem quota (set Dovecot's control and index files to a partition without quota enforcing).
But this does not sound like the most urgent need.
Perhaps I should start with number 1. above, to expose all my ignorance
about the subject right from the start, and get all your friendly kicks
and blows. Then I would be almost qualified to write something for number
2, the most demanding of all, from a pedagogical point of view. In the
mean time somebody could begin sketching 3. and parts of 4 you happen to
know something about. (I now have a first-hand experience in
mbox->maildir, using formail and procmail - and a script too.)
Are there any issues with clients worth mentioning?
On Mon, 25 Jul 2005 12:33:24 +0200, Nick Maynard
nick.maynard@alumni.doc.ic.ac.uk wrote:
May I suggest an additional section with a full breakdown of what every
configuration directive does?
Oh, dear! Just five minutes, and it's done!
But jokes aside, it's a damned good idea. While points 1-6, and especially
2-4 are perhaps more usefull in real life, not having said breakdown feels
rather frustrating.
Could I suggest a thing? Could you have an explicit call on new users to
write a few words about their experiences and frustrations with Dovecot,
whatever they are, some place where they are likely to see it?
Something like "Please tell us a few words about your experiences with
installing and using dovecot! Newbies are also welcome." - and a large
textbox below, and a submit button.
Perhaps a question too: "What is the single piece of information that
could have saved you most effort and time if you only had known it early
on?"
I don't exactly mean a wiki page, because I think about it more like a
surview, not that many would bother to read tons of trivial observations.
But given the present infrastructure, perhaps a wiki page is the easiest.
You may think a mailing list is for just that, but then the threshold is
too high, and you never find out what most people do in real life.
-Enrique
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 25.7.2005, at 19:10, Enrique Perez-Terron wrote:
Could I suggest a thing? Could you have an explicit call on new users to write a few words about their experiences and frustrations with Dovecot, whatever they are, some place where they are likely to see it?
That could be useful, but the biggest problem with Dovecot currently is its version numbering mess. 0.99.x has many problems and I don't really want to hear about them anymore. It's however still the "stable" version, so people use it.. Something always seems to be broken in 1.0-tests (although test79 looks good so far), and 1.0-stable is missing support for keywords..
Once 1.0-tests get to the point that it's stable enough to fully depricate 0.99.x, then these kind of surveys are much more important. Before that I think it'd only waste time. That's also the reason why I haven't yet bothered all that much to write documentation..
On Mon, 25 Jul 2005 23:56:29 +0200, Timo Sirainen tss@iki.fi wrote:
On 25.7.2005, at 19:10, Enrique Perez-Terron wrote:
Could I suggest a thing? Could you have an explicit call on new users to write a few words about their experiences and frustrations with Dovecot, whatever they are, some place where they are likely to see it?
That could be useful, but the biggest problem with Dovecot currently is its version numbering mess. 0.99.x has many problems and I don't really want to hear about them anymore.
Convinced.
It would be a bad idea to set up a feedback mechanism until a minimum amount of decent documentation is in place.
We would not learn anything usefull from it, since we already know that documentation is a good idea.
Yet I agree with your priority, get the version 1.0 stable and complete with keywords. I can try my hand on some texts in the meantime.
Regards Enrique
On Mon, 2005-07-25 at 12:10, Enrique Perez-Terron wrote:
I've just set up Dovecot and I think there is some definite need on the "guidance side" of Dovecot. A number of my comments likely sit in the "why would you set up an IMAP server in the first place" category but here's my 2 cents worth (warning - that's Canadian money ;-)
I've been thinking of doing some major wiki restructuring some day before v1.0 release. So that in main page there would be something like:
- Information about IMAP, POP3, SMTP and mail servers in general
The Dovecot Wiki shouldn't rephrase what is out there in the big wild Interweb. I think it should be focused on an initial sort of question and answer session that filters out people where IMAP isn't the solution they are really looking for. If you can't get to IMAP there isn't much point in considering Dovecot. As more and more people start to set up email server systems rather than email client systems at home, there is a need for something that says "this is the wrong path". So, to move this from the abstract to almost the marketing side, possibly these are things that should be directly accessible on the Wiki:
- how does your email show up on your email client?
- drop the MTA, MDA, etc. stuff, most people don't understand it
- provide links to web sites that provide this info in a useful fashion
- why do you think an IMAP solution is the way for you?
- provide a couple of scenarios where IMAP is the right solution and
maybe a couple where it is the wrong solution:
- 1 - external access to a work IMAP server
- 2 - small home network where it has become a PIA to have email POP'd down to local clients and then it resides on one computer and the email is inaccessible from another computer.
- 3 - small business which is kinda like (2) but the business needs to backup all email (incoming and outgoing) for accountability reasons.
- 4 - web access to local server email - doe's the implementer understand firewalls and DMZ's
- 5-998 - put your email situation in here (and I don't think I have reserved enough numbers ;-)
- 999 - IMAP is cool and I am going to do it no matter what ;-)
- provide a couple of scenarios where IMAP is the right solution and
maybe a couple where it is the wrong solution:
- Installing and setting up a simple Dovecot installation
I think this is pretty well handled in the doc's and the Wiki. The problem is when someone is trying to do something that is just a bit off the norm and doesn't understand the implications. Running ANY server is something that you need to consider on a security level and IMAP and Dovecot's implementation thereof are no different.
- Full guide to setting up a new system
This could be difficult - what is the "new" system expected to do? Dovecot and thereby IMAP are not a silver bullet, let's make sure that people don't try to misapply an available technology because of the "acronym of the day" syndrome.
- Migration from existing systems
- other servers
- mbox <-> maildir
- pop3 -> imap
- other servers - the mailing list handles this pretty well. Dovecot is not "shrinkwrap" software so if someone is trying to move from another IMAP environment to Dovecot just point them to the mailing list. That said - generic lessons learned as already exist on the Wiki should be kept up to date but someone already running IMAP is aware of the possibility of inconsistencies between IMAP implementations and should be looking for a "harder" resource than the Wiki - like the mailing list.
- mbox <-> maildir - I should just shut up here, really... I like the fact that Dovecot claims to be agnostic on this issue. It is quite happy to work with either (I assume because I am an mbox guy running very small (100+ emails a day). Whaddya like better vi or emacs? Let's not start a conflict here unless Dovecot actually does work better with one or the other. In that case state the fact (and it may require a scaling factor - less than X emails per day it doesn't matter but after that you might be better off with one approach or another). A mini-FAQ that provides migration hints would be a good thing.
- pop3 -> IMAP - I think this is back into my question about "why are you doing this in the first place".
- Troubleshooting
Common Dovecot problems - yes. Getting IMAP going in general, no. As much as one stop shopping seems to be a good idea, it isn't. If the troubleshooting gets into "why are you doing this anyway" then it has gone far afield and will chew up resources that are better spent advancing Dovecot rather than arguing whether IMAP is a good thing or not.
- Supported features / current status / TODO
Mailing list - weekly emails on status. You'll get the people who care. Wiki - one page on committed plans, another page that is a filtered version of "things I am thinking about - if you want to know more join the mailing list and pipe up there ..."
Other issues - Encourage all Dovecot users to update Wiki for how they are using Dovecot with getmail/fetchmail/qmail/procmail and friends. The Wiki needs more example implementations and that has to come from the Dovecot user base.
New page for the Wiki - Well, I got here because I am concerned about SPAM/virus/etc. How does Dovecot fit in? This goes back to the previous paragraph (as well as the "why are you here in the first place stuff"_ - USERS - how is your system setup? I personally pre-filter before anything hits my incoming spool. Works well in my small scale environment but I am sure others have different approaches.
Cheers, As you can tell I am fully behind Dovecot and really appreciate the effort expended in giving me such a wonderful tool. Oh, yeah, it's fully AMD64 functional if you didn't already know ;-).
Kris
--
Kris at Home ... (
\_@
____________\/)_____________
~~-^~~-^~~-\____________\_____________/^~~-^~~-^~~-^~~-^~~-
^~~-^~~-^~~-^~~-^~~-^~~- \^~~-^~~-^~~-^~~-^~~-^~~-^~~-^~~-
~-^~~-^~~-^~~-^~~-^~~-^~~(\^~~-^~~-^~~-^~~-^~~-^~~-^~~-^~
====================================================================
On Tue, Jul 26, 2005 at 10:39:35PM -0400, Kris Boyle wrote:
- why do you think an IMAP solution is the way for you?
- provide a couple of scenarios where IMAP is the right solution and maybe a couple where it is the wrong solution:
- 1 - external access to a work IMAP server
- 2 - small home network where it has become a PIA to have email POP'd down to local clients and then it resides on one computer and the email is inaccessible from another computer.
- 3 - small business which is kinda like (2) but the business needs to backup all email (incoming and outgoing) for accountability reasons.
- 4 - web access to local server email - doe's the implementer understand firewalls and DMZ's
- 5-998 - put your email situation in here (and I don't think I have reserved enough numbers ;-)
- 999 - IMAP is cool and I am going to do it no matter what ;-)
One very important factor here is what mail client (MUA) the prospective user is going to use. One of IMAPs weaknesses in my opinion is that clients (and servers) interpret the rules in different ways such that some clients don't work well with some servers. There isn't yet one 'right' way. If there are going to be multiple mail clients then the issue gets even more complex.
-- Chris Green (chris@areti.co.uk)
"Never ascribe to malice that which can be explained by incompetence."On Wed, 27 Jul 2005 11:20:16 +0200, Chris Green chris@areti.co.uk wrote:
On Tue, Jul 26, 2005 at 10:39:35PM -0400, Kris Boyle wrote:
- why do you think an IMAP solution is the way for you?
- provide a couple of scenarios where IMAP is the right solution and maybe a couple where it is the wrong solution:
- 1 - external access to a work IMAP server
- 2 - small home network where it has become a PIA to have email POP'd down to local clients and then it resides on one computer and the email is inaccessible from another computer.
- 3 - small business which is kinda like (2) but the business needs to backup all email (incoming and outgoing) for accountability reasons.
- 4 - web access to local server email - doe's the implementer understand firewalls and DMZ's
- 5-998 - put your email situation in here (and I don't think I have reserved enough numbers ;-)
- 999 - IMAP is cool and I am going to do it no matter what ;-)
One very important factor here is what mail client (MUA) the prospective user is going to use. One of IMAPs weaknesses in my opinion is that clients (and servers) interpret the rules in different ways such that some clients don't work well with some servers. There isn't yet one 'right' way. If there are going to be multiple mail clients then the issue gets even more complex.
Agreed, there are a couple of issues with imap and clients.
I just switched to Opera (browser with mail&news client), and while is quite interesting how it does its own automatic structuring of mails, it does not really use the imap folders as other than a source of new mails.
It wants to have its own indices and keywords on the mails, and it does not save new mails and drafts in imap folders.
Most of this is probably not dovecot-specific, and the dovecot- specific issues must have priority.
However, with ever increasing numbers of users with limited knowledge showing up on the door (the website), some basic information would be a good service and also reduce pressure on the mailing lists.
By the way, searchning around I found there is a companion protocol for storing user preferences and the like in servers. ACAP - I guess there must have been some discussion about that here before. Does dovecot plan to offer any such services?
Regards, -Enrique
Enrique Perez-Terron enrio@online.no wrote:
By the way, searchning around I found there is a companion protocol for storing user preferences and the like in servers. ACAP - I guess there must have been some discussion about that here before. Does dovecot plan to offer any such services?
As useful as centralized storage of email preferences is (I use it for Mulberry, my IMAP client of choice), I tend to think that such is out of scope in terms of what dovecot should do.
And then there's the whole joy of building Cyrus SASL that goes with building the IMSP/ACAP server. Yuck.
Jon Roma wrote:
Enrique Perez-Terron enrio@online.no wrote:
By the way, searchning around I found there is a companion protocol for storing user preferences and the like in servers. ACAP - I guess there must have been some discussion about that here before. Does dovecot plan to offer any such services?
Actually, at one point I had planned to try this, based on Dovecot, since ACAP uses the same basic protocol as IMAP, but with different verbs. Unfortunately, work got in the way.
And then there's the whole joy of building Cyrus SASL that goes with building the IMSP/ACAP server. Yuck.
Why bother using Cyrus SASL when Dovecot has its own SASL implementation?
-- Curtis Maloney
Curtis Maloney cmaloney@cardgate.net wrote:
And then there's the whole joy of building Cyrus SASL that goes with building the IMSP/ACAP server. Yuck.
Why bother using Cyrus SASL when Dovecot has its own SASL implementation?
This has nothing to do with using SASL to authenticate to Dovecot.
Cyrus SASL is required to build Cyrus IMSP and ACAP, which use SASL to authenticate and which can be used by the Mulberry IMAP client to store address books, preferences, etc.
Jon Roma wrote:
Curtis Maloney cmaloney@cardgate.net wrote:
And then there's the whole joy of building Cyrus SASL that goes with building the IMSP/ACAP server. Yuck.
Why bother using Cyrus SASL when Dovecot has its own SASL implementation?
This has nothing to do with using SASL to authenticate to Dovecot.
Cyrus SASL is required to build Cyrus IMSP and ACAP, which use SASL to authenticate and which can be used by the Mulberry IMAP client to store address books, preferences, etc.
Wasn't the original context of this discussion writing an ACAP server as part of Dovecot?
Or are you presenting the agonies of Cyrus SASL (which I've suffered and learned from) as argument FOR adding ACAP to Dovecot?
Unfortunately, it seems ACAP fell by the wayside as too complicated, and LDAP came along instead. Pity there's not a good, clean OSS LDAP server around :/
-- Curtis
Curtis Maloney cmaloney@cardgate.net wrote:
Jon Roma wrote:
Curtis Maloney cmaloney@cardgate.net wrote:
And then there's the whole joy of building Cyrus SASL that goes with building the IMSP/ACAP server. Yuck.
Why bother using Cyrus SASL when Dovecot has its own SASL implementation?
This has nothing to do with using SASL to authenticate to Dovecot.
It looks like you assumed that I was building Cyrus SASL in place of the built-in-to-dovecot SASL support, when I was actually talking about the Cyrus SASL libraries being in the "food chain" for Cyrus ACAP/IMSP. Sorry if I confused anyone.
Cyrus SASL is required to build Cyrus IMSP and ACAP, which use SASL to authenticate and which can be used by the Mulberry IMAP client to store address books, preferences, etc.
Wasn't the original context of this discussion writing an ACAP server as part of Dovecot?
Yes, and my comment was a reply to Enrique Perez-Terron enrio@online.no, who wrote:
: By the way, searchning around I found there is a companion protocol : for storing user preferences and the like in servers. ACAP - I guess : there must have been some discussion about that here before. Does : dovecot plan to offer any such services?
The gist of what I was trying to say was that this idea felt to me as out of scope for what dovecot ought to do.
ACAP (and its predecessor IMSP) are rather useful as a central store for address books and mail user agent preferences. (I mentioned that I use this with my Mulberry MUA for both address books and Mulberry preferences).
I haven't seen anyone explain the big gain would be for dovecot to act as an ACAP service. There are two plausible roles:
To maintain IMAP preference data -- not sure if this has any value, since dovecot already supports plenty of ways to store user login/password data and mailbox locations and I can't think of much else in the way of IMAP settings/preferences.
To maintain address book data and mail user agent preferences -- to wit, something that could be used in place of Cyrus ACAP or IMSP. This is more useful, but this has nothing to do with an IMAP service and may thus be "out of scope" for the dovecot project.
Still, even if these services don't have anything to do with IMAP itself, one could make the argument that anyone who wants a high- quality, easy-to-run IMAP server may also benefit from an ACAP server.
I'd use it -- anything that would save me from having to build the Cyrus utilities! :-) But I am probably in the minority since I'm a Mulberry user, and I don't know who else supports these protocols and how valuable they'd really be to the dovecot community.
One of the things I find elegant about dovecot is that it strikes a nearly perfect balance between having lots of features but staying away from the "everything but the kitchen sink" approach of some software projects. I would rather have a system that did a small number of things well than a system that does everything poorly. Whether this is a good idea, I don't know. Perhaps Timo will share with us his vision on this point.
Or are you presenting the agonies of Cyrus SASL (which I've suffered and learned from) as argument FOR adding ACAP to Dovecot?
As a Mulberry user I would personally benefit from such an addition> Nevertheless, I am disinclined to suggest it at this time. However, as noted above, someone could certainly make a viable argument in favor! And, in any case, anything that saves one from the agonies of building and running Cyrus SASL is probably a doing the world a favor. :-)
Unfortunately, it seems ACAP fell by the wayside as too complicated, and LDAP came along instead. Pity there's not a good, clean OSS LDAP server around :/
Agreed.
Jon Roma wrote:
It looks like you assumed that I was building Cyrus SASL in place of the built-in-to-dovecot SASL support, when I was actually talking about the Cyrus SASL libraries being in the "food chain" for Cyrus ACAP/IMSP. Sorry if I confused anyone.
No. It's more that when the OP suggested adding an ACAP server to Dovecot, you started talking about Cyrus SASL, as if they were somehow connected, and presented it as some sort of reason to NOT build ACAP into Dovecot.
I can only see Cyrus ACAP and Cyrus SASL as strong supporting arguments TO build an ACAP server on Dovecot.
It almost seems like you're referring to ACAP as a specific application, not a protocol in its own right.
Cyrus SASL is required to build Cyrus IMSP and ACAP, which use SASL to authenticate and which can be used by the Mulberry IMAP client to store address books, preferences, etc.
Wasn't the original context of this discussion writing an ACAP server as part of Dovecot?
Yes, and my comment was a reply to Enrique Perez-Terron enrio@online.no, who wrote:
: By the way, searchning around I found there is a companion protocol : for storing user preferences and the like in servers. ACAP - I guess : there must have been some discussion about that here before. Does : dovecot plan to offer any such services?
The gist of what I was trying to say was that this idea felt to me as out of scope for what dovecot ought to do.
Well, the scope of Dovecot seems to be expanding all the time: LDA, Auth server (with patches to Postfix to use it for SMTP Auth), and (possibly) soon a config server.
Given that ACAP uses the same basic protocol layer as IMAP, and was originally designed as a companion protocol to IMAP, I don't see it being a far stretch.
ACAP (and its predecessor IMSP) are rather useful as a central store for address books and mail user agent preferences. (I mentioned that I use this with my Mulberry MUA for both address books and Mulberry preferences).
And I suspect more programs would support it... if there were a less obnoxious-to-build ACAP server available.
I haven't seen anyone explain the big gain would be for dovecot to act as an ACAP service. There are two plausible roles:
- To maintain IMAP preference data -- not sure if this has any value, since dovecot already supports plenty of ways to store user login/password data and mailbox locations and I can't think of much else in the way of IMAP settings/preferences.
I was never under the impression ACAP was there to store details for the server to use, only for the clients/users.
- To maintain address book data and mail user agent preferences -- to wit, something that could be used in place of Cyrus ACAP or IMSP. This is more useful, but this has nothing to do with an IMAP service and may thus be "out of scope" for the dovecot project.
"out of scope" is a difficult call, and ideally up to Timo (who'll probably say "If the users want it...", and continue looking worn out :)
Still, even if these services don't have anything to do with IMAP itself, one could make the argument that anyone who wants a high- quality, easy-to-run IMAP server may also benefit from an ACAP server.
I agree here. The way I see it, IMAP shifts the separator line, so my MUA is now abstracted from message storage. Since the details of my mail are not tied to a specific MUA install any more, why should the rest of my mail info (address books, filters, etc) be?
I'd use it -- anything that would save me from having to build the Cyrus utilities! :-) But I am probably in the minority since I'm a Mulberry user, and I don't know who else supports these protocols and how valuable they'd really be to the dovecot community.
Sadly, very few MUAs support ACAP - most likely because almost nobody implemented a good ACAP server, and LDAP somehow won favour.
One of the things I find elegant about dovecot is that it strikes a nearly perfect balance between having lots of features but staying away from the "everything but the kitchen sink" approach of some software projects. I would rather have a system that did a small number of things well than a system that does everything poorly. Whether this is a good idea, I don't know. Perhaps Timo will share with us his vision on this point.
I do like the KISS approach. I also like the modular approach Timo has taken. It would mean an ACAP server on the same code base already has most of the work done, on the protocol side.
It would become a matter of implementing the verbs and back-end storage.
-- Curtis
Curtis Maloney cmaloney@cardgate.net wrote:
Jon Roma wrote:
It looks like you assumed that I was building Cyrus SASL in place of the built-in-to-dovecot SASL support, when I was actually talking about the Cyrus SASL libraries being in the "food chain" for Cyrus ACAP/IMSP. Sorry if I confused anyone.
No. It's more that when the OP suggested adding an ACAP server to Dovecot, you started talking about Cyrus SASL, as if they were somehow connected, and presented it as some sort of reason to NOT build ACAP into Dovecot.
Hi, Curtis.
Sorry; I didn't mean that, and looking again at the mail I sent, I can see that it didn't come out at all right. :-(
I can only see Cyrus ACAP and Cyrus SASL as strong supporting arguments TO build an ACAP server on Dovecot.
Assuming that there's justification to do ACAP, I agree wholeheartedly. An implementation that doesn't require pulling one's hair out to install has a lot better odds of widespread adoption.
It almost seems like you're referring to ACAP as a specific application, not a protocol in its own right.
No, I know the difference. To date, I am aware of exactly one ACAP implementation, but that doesn't change the fact that it's a protocol. :-)
Well, the scope of Dovecot seems to be expanding all the time: LDA, Auth server (with patches to Postfix to use it for SMTP Auth), and (possibly) soon a config server.
Given that ACAP uses the same basic protocol layer as IMAP, and was originally designed as a companion protocol to IMAP, I don't see it being a far stretch.
Maybe not. I guess it depends on how the cost/benefit ratio plays out. ACAP would be nice to have, but in my view, the world needs the IMAP server part of Dovecot a LOT more than any of the other pieces.
ACAP (and its predecessor IMSP) are rather useful as a central store for address books and mail user agent preferences. (I mentioned that I use this with my Mulberry MUA for both address books and Mulberry preferences).
And I suspect more programs would support it... if there were a less obnoxious-to-build ACAP server available.
Yes, that's the old chicken and egg problem! Aside from the frustration with dealing with the ACAP/IMSP builds, it's sort of frustrating that work on ACAP's apparently petered out especially since its potential utility is so obvious. But as you noted, LDAP probably stole the spotlight.
I haven't seen anyone explain the big gain would be for dovecot to act as an ACAP service. There are two plausible roles:
- To maintain IMAP preference data -- not sure if this has any value, since dovecot already supports plenty of ways to store user login/password data and mailbox locations and I can't think of much else in the way of IMAP settings/preferences.
I was never under the impression ACAP was there to store details for the server to use, only for the clients/users.
I, perhaps incorrectly, assumed from the question that someone was inquiring about storage related to dovecot's "primary mission" as an IMAP server, which didn't seem particularly useful to me. I didn't really think outside that context until you and I got into this discussion.
- To maintain address book data and mail user agent preferences -- to wit, something that could be used in place of Cyrus ACAP or IMSP. This is more useful, but this has nothing to do with an IMAP service and may thus be "out of scope" for the dovecot project.
"out of scope" is a difficult call, and ideally up to Timo (who'll probably say "If the users want it...", and continue looking worn out :)
Exactly. And one question I could see being asked is "Is this something that should be part of dovecot, or is this a separate project that dovecot could benefit from?" And then there's the whole chicken and egg thing with having applications that can use ACAP to justify the work....
Still, even if these services don't have anything to do with IMAP itself, one could make the argument that anyone who wants a high- quality, easy-to-run IMAP server may also benefit from an ACAP server.
I agree here. The way I see it, IMAP shifts the separator line, so my MUA is now abstracted from message storage. Since the details of my mail are not tied to a specific MUA install any more, why should the rest of my mail info (address books, filters, etc) be?
I'd use it -- anything that would save me from having to build the Cyrus utilities! :-) But I am probably in the minority since I'm a Mulberry user, and I don't know who else supports these protocols and how valuable they'd really be to the dovecot community.
Sadly, very few MUAs support ACAP - most likely because almost nobody implemented a good ACAP server, and LDAP somehow won favour.
Agreed there. Maybe now we need built-in LDAP support too -- uh, oh ... I think I'm opening a can of worms. ;-)
One of the things I find elegant about dovecot is that it strikes a nearly perfect balance between having lots of features but staying away from the "everything but the kitchen sink" approach of some software projects. I would rather have a system that did a small number of things well than a system that does everything poorly. Whether this is a good idea, I don't know. Perhaps Timo will share with us his vision on this point.
I do like the KISS approach. I also like the modular approach Timo has taken. It would mean an ACAP server on the same code base already has most of the work done, on the protocol side.
Agreed with respect to KISS and modularity.
It would become a matter of implementing the verbs and back-end storage.
That could make it promising.
Anyway, it's interesting to see discussion of ACAP. Some days, I feel like the only person on the planet who's heard of it. :)
Hello,
I must thank you all for this discussion that clarified numerous points in
record time. Each question is perhaps answerable using Google and some
luck, but knowing what questions to ask...
Now I only wonder what MUA's do support LDAP?
I installed IMAP in the first place because I wanted to be more
independent of any particular MUA, since I frequently despair over their
(mis)features. But accessing my mailstorre remotely is another attractor.
Regards, Enrique
I don't use LDAP myself but I'm using Exim and it supports LDAP and I'm extremely pleased with Exim. It is like Dovecot in that it has very readable and flexable config files and that "this is done right" feel.
Enrique Perez-Terron wrote:
Hello,
I must thank you all for this discussion that clarified numerous points in record time. Each question is perhaps answerable using Google and some luck, but knowing what questions to ask...
Now I only wonder what MUA's do support LDAP?
I installed IMAP in the first place because I wanted to be more
independent of any particular MUA, since I frequently despair over their (mis)features. But accessing my mailstorre remotely is another attractor.Regards, Enrique
-- Marc Perkel - marc@perkel.com
Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com
Whoops! I didn't read the message right. MUA - Mozilla or Thunderbird are my favorites.
On Wed, 2005-07-27 at 18:41 +0200, Enrique Perez-Terron wrote:
By the way, searchning around I found there is a companion protocol for storing user preferences and the like in servers. ACAP - I guess there must have been some discussion about that here before. Does dovecot plan to offer any such services?
ACAP has very little client support though. Mulberry is probably the only client supporting it. Also I have a feeling that ACAP is pretty much a dead protocol nowadays.
participants (9)
-
Chris Green
-
Curtis Maloney
-
Enrique
-
Enrique Perez-Terron
-
Jon Roma
-
Kris Boyle
-
Marc Perkel
-
Nick Maynard
-
Timo Sirainen