Not to be a bitch, but I've asked several times about some basic questions or examples to clarify the essentials for configuration. What do some of the parameters mean? Expecially the ones that are mentioned only one in a paragraph and no where else in the documentation or wiki. (ie: login_process_per_use) And there have been a few others as well. that I won't bother to repeat. But I've been sitting on this list for a while yet and have found that when it comes to configuration, none of the emails posted have been answered or addressed. The closest I got was a suggestion to use views instead of tables in postgres. But technically nothing was ever said about dovecot itself. So I have to ask. Is the sketchy documentation in the source file, the web page, wiki, and limited reponse on the mailing list a matter of "I haven't gotten around to it yet" or a deliberate move to promote the commercial support potential for Procontrol? I've run into this kind of environment twice before (cyrus and razor) and in the case of cyrus they just didn't believe in doing the documentation but suggested I write it myself. That may be the case there as well ("I haven't gotten around to it yet". That's OK but cyrus has the difficulty of no one still not providing any answers to how anything was done, configured, functioned, or why. So documentation was kind of a reverse-engineering project in itself. In the case of razor it's a mix of no time and they would rather support the company than the project. I went back and re-read the emails that I had posted earlier and am pretty sure that they weren't too stupid (ie: how do I test an imap connection), difficult, or obscure (well, maybe one). I'm just trying to find more information on how to correctly configure this server such that I can retain the concept of keeping security in mind. I'm trolling through the archives and there doesn't seem to be much discussion from anyone else. So maybe I'm really stupid and can't do authentication schemes. I'm sure by this point I've really pissed a few people off and for that I mostly apologize. I'm a little bent here myself. It just that I didn't plan on having to set up sniffit to track my IMAP traffic in order to verify that things were actually working securely. I'm going to plug along and do it myself and probably get something to work. I have plain_text authentication working now, but was really hoping to actually get something secure. At this point I really don't expect an answer, but do hope that after 1.0 is released there will be time available to get some documentation in order. IMHO the level of documentation that is available on a software project is critical to it's use.
On Thu, 2004-06-10 at 13:24, Tom Allison wrote:> Not to be a bitch, but I've asked several times about some basic > questions or examples to clarify the essentials for configuration.I haven't gotten around to answering any questions here for a few days. It always takes some energy and time which I don't always have.> What do some of the parameters mean? Expecially the ones that are > mentioned only one in a paragraph and no where else in the documentation > or wiki. (ie: login_process_per_use)All configuration settings are explained in dovecot-example.conf, more or less well. If something isn't very clear there, I try to fix it if I can. The documentation in doc/ dir was written quite a long time ago and I haven't looked at it lately. login_process_per_user is one example which has changed to login_process_per_connection, which is explained shortly in the config file.> But I've been sitting on this list for a while yet and have found that > when it comes to configuration, none of the emails posted have been > answered or addressed. The closest I got was a suggestion to use views > instead of tables in postgres. But technically nothing was ever said > about dovecot itself.I'm not sure what mails you're referring to, all I see from you are the three mails two days ago which no-one replied to, and the ones last year which weren't configuration related.> So I have to ask. Is the sketchy documentation in the source file, the > web page, wiki, and limited reponse on the mailing list a matter of "I > haven't gotten around to it yet"I've tried to keep the Dovecot-specific settings well explained in comments in config file. More generic documentation is yet to be written, although some is in Wiki and some in doc/ dir. Actually I would have written more documentation already, except that there's quite a lot of differences between 0.99.10 and upcoming 1.0. Writing the docs for 1.0 would be better, but it's not usable yet, so docs for it wouldn't really matter to anyone yet. I'm also still hoping someone else gets to write the documentation :)> or a deliberate move to promote the > commercial support potential for Procontrol?I don't intend to do any blackmailing to get people to pay for Dovecot. Commercial support isn't really planned until v1.0 comes out, although we do already sell software development (Dovecot and non-Dovecot related). When 1.0 gets nearer, more Procontrol people should get more involved in Dovecot development and support (yes, free support in here too). For now however, it's just me. -------------- 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: <dovecot.org/pipermail/dovecot/attachments/20040610/2f12bb87/attachment-0001.bin>
Tom Allison wrote:> Not to be a bitch, but I've asked several times about some basic > questions or examples to clarify the essentials for configuration. >I have to apologize to the group for my rather untidy outburst. With a few good pointers from Timo and another session with the Fine manuals, I've managed to get everything working correctly (I think). I also hope to get the opportunity this weekend to write up some of my notes on the configuration process to make a contribution. I can document a lot of mistakes not to make! But right now, it's looking really good! I've worked out a rather minimalist configuration with md5 hash passwords over plaintext authentication. The passwords are in postgres and the user information is in /etc/passwd. For now, this lets everyone one the machine have an account that they can manage, but the passwords are distinctly seperated from the shell login passwords. I haven't gotten to the virtual user stuff yet as I don't quite know how I'm going to tie all of that into some procmail rules I have for filtering. I also have nothing regarding shared files, but it appears I have to do some more of that Fine reading on symlinks before I get there. Many thanks to those who haven't /dev/null-ed me on their mail servers!