Re: [Dovecot] help with static userdb
On Tue, 2007-04-17 at 19:04 -0600, Kyle Wheeler wrote: args = uid=500 gid=500 home=/domains/%d/%n } When I attempt to log in as, say, [EMAIL PROTECTED] (via telnet, so I *know* I'm logging in as that user), the debug log says that it thinks my home directory is /domains//kyle. Your passdb drops the domain out. This is usually caused by SQL password_query: # The user column is needed to make sure the username gets used with exactly # the same casing as it's in the database. Note that if you store username and # domain in separate fields, you most likely want to return a combination of # them as the user column, otherwise the domain gets stripped. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] help with static userdb
On Wednesday, April 18 at 09:04 AM, quoth Timo Sirainen: When I attempt to log in as, say, [EMAIL PROTECTED] (via telnet, so I *know* I'm logging in as that user), the debug log says that it thinks my home directory is /domains//kyle. Your passdb drops the domain out. This is usually caused by SQL password_query: Ahh, gotcha. I was actually using checkpassword, and I'm not sure how to get the domain back out of what it returns. I just switched over to using ldap directly (my checkpassword program was an ldap frontend), and that seems to have fixed the problem. ~Kyle -- Many who claim to have been transformed by Christ's love are deeply, even murderously, intolerant of criticism. -- Sam Harris pgp7vFNmt7T8F.pgp Description: PGP signature
Re: [Dovecot] v1.1 plans - sieve?
On Wednesday 18 April 2007 00:13, Timo Sirainen wrote: I don't think so. I want to distribute it with Sieve plugin, and that pretty much requires changes that come only in v2.0. so what's the suggested setup for server-side mail filtering right now ?
Re: [Dovecot] v1.1 plans - sieve?
On Wed, 18 Apr 2007 10:04:09 +0200 [EMAIL PROTECTED] wrote: JSS On Wednesday 18 April 2007 00:13, Timo Sirainen wrote: JSS I don't think so. I want to distribute it with Sieve plugin, and JSS that pretty much requires changes that come only in v2.0. JSS JSS so what's the suggested setup for server-side mail filtering right JSS now ? Either use the Dovecot patch from here: http://sinas.rename-it.nl/~sirius/ or run the pysieved managesieve server from here: http://woozle.org/~neale/repos/pysieved/ We use the latter with great success. No patch to maintain and it's written in Python so you can make it do whatever you want pretty much with just a little scripting knowledge (not a requirement). --Jo
Re: [Dovecot] v1.1 plans
Firstly, congratutulations on the official 1.0; we are now running this in production. On Tue, 17 Apr 2007, Timo Sirainen wrote: I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. [...] Quick check: Is next summer envisaged as 2007 or 2008? Features that I'm planning on implementing: - Fully supported shared mailboxes and IMAP ACL extension - Replace Squat FTS indexes with my new design - Case-insensitive searches with non-ASCII text as well - Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work. Could I put in a request for the logfile consistency item mentioned on April 3rd (and receiving some support)? See: http://www.dovecot.org/list/dovecot/2007-April/021532.html and subsequent thread. Many thanks. -- : David LeeI.T. Service : : Senior Systems ProgrammerComputer Centre : : UNIX Team Leader Durham University : : South Road: : http://www.dur.ac.uk/t.d.lee/Durham DH1 3LE: : Phone: +44 191 334 2752 U.K. :
Re: [Dovecot] v1.1 plans
Richard Laager wrote: On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote: I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1. Please, this needs to be Everyone's v1.0 dovecot.conf will work in v1.1. If you're going to change the configuration file format even in some subtle way, please bump the major version. Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break. Richard I second that. Cheers, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email: [EMAIL PROTECTED] Telefone : +351 212948300 Ext.15307 Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt [EMAIL PROTECTED] ci.fct.unl.pt:~# _
Re: [Dovecot] v1.1 plans
Timo Sirainen wrote: Features that I'm planning on implementing: - Fully supported shared mailboxes and IMAP ACL extension - Replace Squat FTS indexes with my new design - Case-insensitive searches with non-ASCII text as well - Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work. Hello Timo, one thing i already discussed with you some time ago that would make some difference and open lots of possibilities, in my opinion, would be the ability to have a virtual INBOX that could be composed by a list of folders. That would make a world of difference to those who maintain a mixed service of pop and imap to their users. Just from the top of my head, two great possibilities would be able to 1 - One could use server side filtering (sieve, maildrop, etc) to separate junk from the INBOX to make things look nice for IMAP users, but still allow POP users to retrieve their marked messages and not miss any false positives. 2 - If the list of folders could be a wildcard, allow POP users to retrieve ALL their messages, even if they're also regular IMAP based webmail users. I'm sure other folks would find other ways to use such feature. Best regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email: [EMAIL PROTECTED] Telefone : +351 212948300 Ext.15307 Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt [EMAIL PROTECTED] ci.fct.unl.pt:~# _
Re: [Dovecot] v1.1 plans
Richard Laager wrote: On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote: I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1. Please, this needs to be Everyone's v1.0 dovecot.conf will work in v1.1. If you're going to change the configuration file format even in some subtle way, please bump the major version. Well, there is room for argument here... I would call a 'minor' version going from 1.0 to 1.0.1. For these increments, I totally agree. However, going from 1.0.x to 1.1 is obviously a larger change, and I don't see a problem with *minor* config file changes, as long as they are well documented - and Timo has never failed to do that. In virtually every case, I imagine Timo would also provide backwards compatibility, so it would be a non-issue... Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break. Agree - but anyone who upgrades *anything* without reading the release notes is asking for trouble. -- Best regards, Charles
Re: [Dovecot] v1.1 plans
Timo Sirainen wrote: On Tue, 2007-04-17 at 15:41 -0400, Justin McAleer wrote: In my testing of using sql dictionary for quota, it appears pretty buggy. Are you aware of such problems? Either way, would you consider reliable dictionary quota support a target for 1.1? Actually I think I did it today. The biggest problem with v1.0 implementation was that expunges could be counted multiple times if multiple processes were running. I ran imaptest for a while with 10 connections and in 3 different tests the dict quota always contained correct values, so I thought it was probably working. I was having problems with it seemingly not making updates at all. It would do the initial usage calculation when I logged in, but never updated when I sent a message or expunged anything. In the past (months ago) I also saw problems when sending a message to multiple recipients... I believe it would only update the first recipient or something like that. I was quite astounded by that, since deliver is run once per user, of course. So I was figuring there may be a problem in the dictionary proxy. But, let me double-check all of my configs. If 1.0 should be reliable except for the expunge problem, I'll spend some time today giving it a more thorough examination. While I'm talking about dictionary quota, do you think it could be configurable how to identify the users? I'd like to use uid rather than username/email address, as our users can change their userids. It's not a huge deal, I can make deleting/updating the quota table row part of the rename process, but it would be nice and maybe others would benefit from being able to tweak it. I did find that it seemed to blow maildir++ away in terms of performance. We have a few really large maildirs that basically choke when quota is enabled using maildir++ (200,000+ messages). Even if filenames had the ,S=size? Another problem is that the quota is read, and possibly recalculated, much more often than is really necessary.. I haven't fixed that yet in v1.1. Yes, even then. Perhaps I made it sound a little worse than it was, but expunging a single message made the imap process hang for a while. I'm not sure how long, but definitely long enough that users would (rightfully) complain. I was expecting just an incremental update to be made to maildirsize, but it did the same after every single expunge. I'll do an strace on the process to get a better idea of what exactly is taking so long, but it's fine with quota set to 0, bad when set to anything else (enabled).
Re: [Dovecot] v1.1 plans
Charles Marcus wrote: Richard Laager wrote: On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote: I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1. Please, this needs to be Everyone's v1.0 dovecot.conf will work in v1.1. If you're going to change the configuration file format even in some subtle way, please bump the major version. Well, there is room for argument here... I would call a 'minor' version going from 1.0 to 1.0.1. For these increments, I totally agree. However, going from 1.0.x to 1.1 is obviously a larger change, and I don't see a problem with *minor* config file changes, as long as they are well documented - and Timo has never failed to do that. Agreed, Dovecot was released as 1.0.0 for precisely this reason, I imagine. That being the case, 1.0 - 1.1 should be seen as a significant update (at least worth reading for incompatibilities). In virtually every case, I imagine Timo would also provide backwards compatibility, so it would be a non-issue... Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break. Agree - but anyone who upgrades *anything* without reading the release notes is asking for trouble.
Re: [Dovecot] v1.1 plans
- - Fully supported shared mailboxes and IMAP ACL extension will be very nice I agree wholeheartedly - this is one of the two biggest features I see as dovecot needing to make it numero uno without argument. The other is single-instance storage... and I don't see a mention of that anywhere... Timo - can you make a guess as to whether or not single-instance storage is even a possibility with 2.0? A wiki page with a feature wishlist - complete with commenting from Timo on whether or not he sees the value of the feature and if so, a milestone target - would be very nice. -- Best regards, Charles
[Dovecot] Fwd: dovecot - cas authentication help needed
-- Forwarded message -- From: Vidyasagar Warge [EMAIL PROTECTED] Date: Apr 17, 2007 4:36 AM Subject: dovecot - cas authentication help needed To: [EMAIL PROTECTED] Hello All, I am new to CAS writing my first mail on this mailing list. So please forgive me if I am asking something trivial or stupid :). I am trying to configure dovecote-IMAP server to authenticate the users against CAS through PAM authentication. I found a tutorial here: http://translate.google.com/translate?hl=ensl=fru=http://esup-portail.org/consortium/espace/SSO_1B/tech/cas/cas_pam.htmlsa=Xoi=translateresnum=3ct=resultprev=/search%3Fq%3Dpam_cas%26complete%3D1%26hl%3Den I followed the instructions, but not able to get the authentication running through PAM :(. I googled a lot but didn't found any text on dovecot-pam-casauthentication. If anyone has done it before? and can tell me the steps? Thanks in advance! Regards, Vidyasagar Warge.
Re: [Dovecot] v1.1 plans - sieve?
On Wednesday 18 April 2007 2:19 am, Joakim Ryden wrote: or run the pysieved managesieve server from here: http://woozle.org/~neale/repos/pysieved/ It has a web page now: http://woozle.org/~neale/src/pysieved Thanks for the kind words :) Neale
Re: [Dovecot] v1.1 plans
Justin McAleer wrote: I was having problems with it seemingly not making updates at all. It would do the initial usage calculation when I logged in, but never updated when I sent a message or expunged anything. In the past (months ago) I also saw problems when sending a message to multiple recipients... I believe it would only update the first recipient or something like that. I was quite astounded by that, since deliver is run once per user, of course. So I was figuring there may be a problem in the dictionary proxy. But, let me double-check all of my configs. If 1.0 should be reliable except for the expunge problem, I'll spend some time today giving it a more thorough examination. Ok, my problem with the quota flat out not being updated was some still unexplainable problems with mysql on the server I was using. The insert ... on duplicate key update ... query was successfully inserting new rows, but not ever updating. No error was given, just said 0 rows affected (which by definition shouldn't be possible). But anywho... There is a definite problem delivering mail under load, though. Sometimes a single username will keep getting updated for all incoming mail, regardless of user. I have a group set up in postfix that sends to 100 random accounts. When I send to that group address, one user will get updated for each delivery (one user updated 100 times rather than each user once). If I start up a script sending 15 msgs/sec (for example) to random accounts, some either apply to other users or get lost altogether. in one batch I sent to 350 unique users, yet the quota table only has 223 rows. One last thing, when I sent a message to that huge account with 200,000+ messages, the initial quota calculation seemed to only count up the inbox, not the whole maildir. I'll be happy to do whatever debugging you'd like to see for this stuff, just met me know... I didn't want to waste any more time doing things that may be of no help though.
Re: [Dovecot] v1.1 plans - sieve?
Jorge Salamero Sanz wrote: On Wednesday 18 April 2007 00:13, Timo Sirainen wrote: I don't think so. I want to distribute it with Sieve plugin, and that pretty much requires changes that come only in v2.0. so what's the suggested setup for server-side mail filtering right now ? If you're a Horde fan, another way besides pysieved is to use the Dovecot sieve plugin and Horde's Ingo application. It takes a bit of work, but you can set it up so that when users create/modify filters within Horde, it writes out the appropriate Sieve file that the Dovecot plugin can parse. It makes for an easy GUI for filter rules that pretty much any user can figure out. Gentoo makes this easier since the sieve use flag causes the patch to be downloaded and compiled into Dovecot for you, so you only have to worry about the configuration, not getting and applying the patch. --Jeff
Re: [Dovecot] v1.0.0 released (in Red Hat Rawhide)
--On Friday, April 13, 2007 2:22 PM -0700 Troy Engel [EMAIL PROTECTED] wrote: Hi Tomas, if you want to feed this back upstream based on the work I've done with Axel: dovecot-1.0.beta2-pam-tty.patch: no longer needed, applied upstream in rc22 (slightly different but same result) dovecot-1.0.rc15-default-settings.patch: needs reworked, these files it's patching have changed a lot. The latest rework I did was for rc29, which applies cleanly to 1.0.0 as well (just verified today). Additionally we added a default (commented out) /var/log/dovecot.log setting for the logfile in the default conf file. There's also an added dovecot logrotate.d script (using SIGUSR1) to support the above log; alas, right now I can't connect to the atrpms.net servers to post a link. Feel free to ping me off list and I'll file-attach the patches to save the Fedora folk some work. :) I recommend opening a bugzilla bug against component dovecot. Here's the current list for that component: https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=dovecot When a new version comes out for some program, I just open an RFE bug and paste the release announcement. That provides the downstream packagers a place to track the progress of the update, as well as a place to attach any special patches (such as the ones you mention). Since 1.0.0 is now in Rawhide, no request for that is needed, so you'll want to open a new bug to request modifications to patches in that package. Open the bug against Fedora Core, devel version, etc. For those wanting to check out the Rawhide package, here's one mirror: ftp://mirror.stanford.edu/pub/mirrors/fedora/linux/core/development/source/SRPMS/dovecot-1.0.0-11.fc7.src.rpm You'll find others here: http://rhold.fedoraproject.org/Download/mirrors.html
