June 2004 - dovecot - dovecot.org

[Dovecot] POP (dot) locks
by Christian Balzer 09 Apr '06

09 Apr '06

Hello, just to soothe my paranoia from many years of qpopper usage, which enforces solitary access to a POP mailbox. Only one login per user is possible at the same time and if a session terminates w/o qpopper being properly notified it will remain locked for some time, 30 minutes by default. With dovecot (0.99.10.4) one can login multiple times (using POP, with IMAP of course this comes as no surprise :) and thus I presume this bit from the configuration: --- # Should we create dotlock file even when we want only a read-lock? Setting # this to yes hurts the performance when the mailbox is accessed simultaneously # by multiple processes, but it's needed for reliable reading if no other # locking methods are available. #mbox_read_dotlock = no --- means that if the only other reading accesses to a (mbox style in this case here) mailbox are via other dovecot processes everything will be fine? Regards, Christian Balzer -- Christian Balzer Network/Systems Engineer NOC chibi(a)gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/

5 10

RE: [Dovecot] IMAP login name conversion
by Zoong Pham 24 Feb '06

24 Feb '06

> -----Original Message----- > From: Timo Sirainen [mailto:tss@iki.fi] > Sent: Tuesday, 1 June 2004 9:39 PM > To: Zoong Pham > Cc: dovecot(a)dovecot.org > Subject: Re: [Dovecot] IMAP login name conversion > > What passdb and userdb do you use? Unless you're authenticating from > SQL you probably have to modify the source. Let me explain: My server runs OpenBSD-3.5 and Sendmail. We host few virtual domains. Local accounts have login names in this format: login-domain_abc_xyz For example: joedirt-joedomain_com_au, info-adomain_com, info-otherdomain_com That way login accounts are unique across all the virtual domains. I use the OpenBSD pre-compiled dovecot-0.99.10p2. It is set to use "auth_passdb = passwd" and "auth_userdb = passwd" I can use mutt to access my mailbox via IMAPS with login name format joedirt-joedomain_com_au. Other users use different MUA like Outlook and prefer to login with their email addresses (joedirt(a)joedomain.com.au, info(a)adomain.com, info(a)otherdomain.com) We use squirrelmail for webmail. I modified squirrelmail to automatically convert login name from format of joedirt(a)joedomain.com.au to joedirt-joedomain_com_au. So if users use squirrelmail, they can just login with their email addresses. My question is how to achieve the same thing with other MUAs like Outlook? Do I have to modify dovecot source? Can I use LDAP or SQL instead? Note that we are using Sendmail and prefer it than othe MTA. I have looked at the Wiki, specially the "DovecotOpenLdap" but am still confused. Thanks Zoong

3 2

[Dovecot] imap idle on non-inbox?
by Collin Grady 22 Oct '04

22 Oct '04

Can this be done with dovecot? I really like the imap idle feature, but it doesn't work for me because I sort my mail into folders with procmail, so it only notifies me when one drops into inbox and not a subfolder. Is there just an option for this I'm missing, or does support for this not exist yet? Also, I don't think its a client issue as I watched the traffic with tcpdump and it only announced anything for inbox, messages dropping into other folders caused no traffic. -- Collin Grady BOFH excuse #347: The rubber band broke

5 9

[Dovecot] Plaintext Authentication from Localhost
by Paul C. Bryan 06 Sep '04

06 Sep '04

Hi: It appears that at least at one time, Dovecot supported plaintext authentication from localhost, even if disable_plaintext_auth = yes. To wit, the example configuration file reads: # Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability). Note that 127.*.*.* and # IPv6 ::1 addresses are considered secure, this setting has no effect if # you connect from those addresses. #disable_plaintext_auth = yes On brief inspection of the code, there doesn't seem to be any such support. This is corroborated by the fact that 0.99.10 (Debian package) behaves by disallowing plaintext authentication via connections on localhost. This is a particularly useful feature, as local webmail clients can safely authenticate via the local interface without requiring secure authentication. So, the question is, is Dovecot supposed to support plaintext auth via localhost even if disallowed in dovecot.conf? If so, any suggestions as to what I may be doing wrong? Yours truly, Paul C. Bryan email(a)pbryan.net

2 4

[Dovecot] What about saving your INBOX at ~/mbox ?
by Nico Kadel-Garcia 23 Aug '04

23 Aug '04

Hi, folks. I'm testing out RedHat's "Fedora Core 2" release, which has switched from the old WashU imapd to dovecot-0.99.10. Overall, this looks like a really, really good move on their part: it looks like a very sweet little tool without some of the ingrained idiocy of Mark Crispin insisting that every home directory consist of nothing but mbox files and allowing you to use a configurable subdirectory by default, ~/mail. Cool. There is one feature of the old WashU imapd that I miss, though. That daemonn could be configured to automatically transfer the user's email to the "~/mbox" upon activation of the daemon, effectively reducing the size of the /var/spool/mail/{username}" mail spool and helping keep the user's disk usage in their home directories, not in /var/spool/mail. This can be a good thing for various reasons. But I don't see any way to enable that behavior for dovecot. Is there something I'm missing, or do folks feel it would be reasonable to add? -- Nico Kadel-Garcia Systems Engineer Mitsubish Electric Research Lab <nkadel(a)merl.com>

4 6

[Dovecot] Debian dovecot news
by Jaldhar H. Vyas 04 Jul '04

04 Jul '04

I uploaded 0.99.10.6 to sid. Owing to the importance of the dot lock fix, I've tried to have this pushed to sarge quickly. Let's see how that goes. I've prepared a backport of 0.99.10.6 to woody which should be showing up on www.backports.org soon hopefully. In the meantime, if you desperately need it and don't mind working out dependencies yourself, you can find it at http://www.braincells.com/backports/ I uploaded 1.0test18 to http://src.braincells.com/dovecot-test/ (I'll do test20 tomorrow) I told Timo I'd port dovecot's gnutls support from gnutls7 to gnutls10 but I have absolutely no time for it so if someone would volunteer, contact me, I'd really appreciate it. -- Jaldhar H. Vyas <jaldhar(a)debian.org> La Salle Debain - http://www.braincells.com/debian/

4 7

[Dovecot] 1.0-test22 - maildir fixed?
by Timo Sirainen 02 Jul '04

02 Jul '04

http://dovecot.org/test/ Well, remember when I said: > Here you go, maildir syncing problems finally fixed (I hope). Well, > except there's this "new-dir-only syncing" optimization which I'm not > really sure if it works as it should. Just before I found the expunge bug in index, I was trying to fix the new-dir-only syncing because the code looked wrong. Then I figured out the indexing problem and thought maybe this one wasn't broken after all, and then forgot about it. Finally after lots of debugging, I came to same conclusion again. The code was wrong, and cause of the remaining "Maildir sync: UID < next_uid (312 < 3)" errors. So, please try and see if you still can break this release. Other changes include some crashfixes for cache file and fix for mbox which kept constantly rewriting headers for \recent messages if we had selected the mailbox as read-only (EXAMINE, STATUS).

11 30

[Dovecot] 1.0-test23 and caching decisions
by Timo Sirainen 30 Jun '04

30 Jun '04

http://dovecot.org/test/ mbox fixes mostly. Began some other things, but none of them actually work yet: - Use X-UIDL header in mboxes for POP3 UIDL list - Cache file compression - Some cleverness for cache file for figuring out what to cache Well, I might as well explain the last one now. Users can be divided to three groups: 1. Most users will use only a single IMAP client which caches everything locally. For these users it's quite pointless to do any kind of caching as it only wastes disk space. That might also mean more disk I/O. 2. Some users use multiple IMAP clients which cache everything locally. These could benefit from caching until all clients have fetched the data. After that it's useless. 3. Some clients don't do permanent local caching at all. For example Pine and webmails. These clients would benefit from caching everything. Some locally caching clients might also access some data from server again, such as when searching messages. They could benefit from caching only these fields. After thinking about these a while, I figured out that people who care about performance most will be using the upcoming Dovecot LDA anyway which updates the indexes/cache immediately. In that case even the first user group would benefit from caching the same way as second group. LDA reads the mail anyway, so it might as well extract some information about it and store them into cache. So, group 1. and 2. could be optimally implemented by keeping things cached only for a while. I thought a week would be good. When cache file is compressed, everything older than week will be dropped. But how to figure out if user is in group 3? One quite easy rule would be to see if client is accessing messages older than a week. But with only that rule we might have already dropped useful cached data. It's not very nice if we have to read and cache it twice. Most locally caching clients always fetch new messages (all but body) when they see them. They fetch them in ascending order. Noncaching clients might fetch messages in pretty much any order, as they usually don't fetch everything they can, only what's visible in screen. Some will use server side sorting/threading which also makes messages to be fetched in random order. Second rule would then be that if a session doesn't fetch messages in ascending order, the fetched field type will be permanently cached. So, we have three caching decisions: 1. Don't cache: Clients have never wanted the field 2. Cache temporarily: Clients want this only once 3. Cache permanently: Clients want this more than once Different mailboxes have different decisions. Different fields have different decisions. There are some problems, such as if a client accesses message older than a week, we can't know if user just started using a new client which is just filling it's local cache for the first time. Or it might be a client user hasn't just used for over a week. In these cases we shouldn't have marked the field to be permanently cached. User might also switch clients from non-caching to caching. So we should re-evaluate our caching decisions from time to time. This is done by checking the above rules constantly and marking when was the last time the decision was right. If decision hasn't matched for two months, it's changed. I picked two months because people go to at least one month vacations where they might still be reading mails, but with different clients.

1 0

[Dovecot] Locked index file
by Kevin Cramer 30 Jun '04

30 Jun '04

I have docevot 0.99.10.6 installed on OpenBSD 3.5 and I'm using it with Squirrelmail. I tried to empty my Trash folder and it timed out. It looks like the process or thread died but the lock wasn't removed: Jun 25 09:16:30 plato imap(kevin): Timeout while waiting for release of shared fcntl() lock for index file /home/kevin/Maildir/.Trash/.imap.index How can I free this lock? I have tried stopping and re-starting dovecot already but that didn't help. Also, is there something I should do to prevent this in the future? The OpenBSD package sets the default locking to fcntl for mbox. I'm not sure if that is the setting that also controls the locking mechanism on the index files. Thanks, Kevin

2 3

[Dovecot] ldap auth problems
by Karl Latiss 30 Jun '04

30 Jun '04

I have previously configured dovecot with ldap auth on a fedora setup with no problems. Now, using RHEL 3 with the same config I get: dovecot: Jun 30 17:46:07 Error: Auth process died too early - shutting down dovecot: Jun 30 17:46:07 Error: child 16780 (auth) killed with signal 11 pop3-login: Jun 30 17:46:07 Fatal: fd_send(-1) failed: Broken pipe imap-login: Jun 30 17:46:07 Fatal: fd_send(-1) failed: Broken pipe This doesn't happen when using other kinds of authentication, eg pam The ldap directory is working fine for other apps so I'm pretty sure that's not it. I'm using the rpm from dag's repository and even re-compiled to ensure ldap support is there. Any clues? -- Karl Latiss <karl(a)designit.com.au> designIT

2 1