- dovecot - dovecot.org

[Dovecot] LDAP for Virtual Domains
by Bryan Vyhmeister 21 May '07

21 May '07

Is anyone using LDAP along with Dovecot where mail is being accessed in the form of /var/vmail/${domain}/${user}? I have not figured out how to extract the domain from LDAP in order to make this work. I know this is sparse information but maybe there is an easy fix. If not, I can post more information. Bryan

6 13

[Dovecot] [Blasphemy] Can I build dovecot with "-fstack-protector"?
by Ralf Hildebrandt 21 May '07

21 May '07

I tried building dovecot using : CPPFLAGS="-fstack-protector" LDFLAGS="-lssp" ./configure That would result in a proper build, yet the binary would complain once being run: dlopen(/usr/local/lib/dovecot/imap/lib10_quota_plugin.so) failed: /usr/local/lib/dovecot/imap/lib10_quota_plugin.so: undefined symbol: __stack_chk_fail_local Error: imap dump-capability process returned 89 and the like. So: Is it possible at all? And sorry for the blasphemy of daring to ask this in the first place :) -- Ralf Hildebrandt (Ralf.Hildebrandt(a)charite.de) plonk(a)charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de First Law of System Requirements: "Anything is possible if you don't know what you're talking about..."

3 14

[Dovecot] NFS lock contention for dovecot-uidlist
by Doug Council 21 May '07

21 May '07

We are in the process of migrating away from Courier-IMAP/POP3 and Maildrop. I want to use Dovecot (LDA, IMAP, POP3). During my testing, it has worked great except for dotlocking on the dovecot-uidlist file. The problem: When a delivery is being made with deliver and a mail client has the mailbox open (Thunderbird in this case), neither Thunderbird or deliver can get a dotlock on the dovecot-uidlist file, causing both deliver and Thunderbird to hang until the dotlock timeout runs out and the lock gets replaced. Once the lock is replaced, both will go about their business until the next lock miss and hang again. Eventually, everything is delivered and Thunderbird wakes up. Looking at each of the processes with truss, they are looping trying to stat the dotcot-uidlist.lock file, which no longer exists. We are using NFS, and based on reading through the mailing list archives, it can be a little difficult to get working reliably. But, I've read quite a few posts with our same or similar configuration having good luck with the setup. To reduce multiple box access-issues for now, I've been doing all testing with a single NFS client. Our configuration: NetApp filers for storage FreeBSD 6.2-RELEASE NFS clients Postfix 2.3.9 MTA Dovecot 1.0.0 LDA for local deliveries Dovecot 1.0.0 IMAP for pickup My dovecot.conf file is at the end of this message. NFS access cachcing on the FreeBSD has been disabled (vfs.nfs.access_cache_timeout = 0, see NFS mount options below). Postfix destination recipient and concurrency limit for the Dovecot LDA is set to 1. The NFS mount options: rw,tcp,-r=32768,-w=32768,nfsv3,dumbtimer,noatime,acregmin=0, acregmax=0,acdirmin=0,acdirmax=0 The dovecot.conf file: protocols = imap imaps pop3 pop3s disable_plaintext_auth = no syslog_facility = local0 ssl_cert_file = /nethere/conf/dovecot/ssl-nh-cert.pem ssl_key_file = /nethere/conf/dovecot/ssl-nh-key.pem login_greeting = Server ready. login_log_format_elements = user=<%u> ip=[%r] method=%m encryption=%c pid=%p login_log_format = %U$: %s mail_location = maildir:~/Maildir:INDEX=MEMORY mmap_disable = yes dotlock_use_excl = no lock_method = dotlock first_valid_uid = 200 last_valid_uid = 200 first_valid_gid = 200 last_valid_gid = 200 maildir_copy_with_hardlinks = yes namespace private { prefix = INBOX. inbox = yes } protocol imap { login_executable = /usr/local/libexec/dovecot/imap-login mail_executable = /usr/local/libexec/dovecot/imap imap_client_workarounds = outlook-idle delay-newmail } protocol pop3 { login_executable = /usr/local/libexec/dovecot/pop3-login mail_executable = /usr/local/libexec/dovecot/pop3 pop3_uidl_format = UID%u-%v pop3_client_workarounds = outlook-no-nuls oe-ns-eoh } protocol lda { postmaster_address = postmaster(a)nethere.com sendmail_path = /usr/sbin/sendmail auth_socket_path = /var/run/dovecot/auth-master syslog_facility = mail } auth_executable = /usr/local/libexec/dovecot/dovecot-auth auth default { mechanisms = plain digest-md5 cram-md5 passdb ldap { args = /nethere/conf/dovecot/dovecot-ldap.conf } userdb ldap { args = /nethere/conf/dovecot/dovecot-ldap.conf } user = root socket listen { master { path = /var/run/dovecot/auth-master mode = 0600 user = mailuser group = mailuser } } } It may just be "how it works", but the lock contention seems a little too fragile for busy mailboxes. Does anyone have any ideas? Thanks in advance for any assistance. -Doug

2 3

Re: [Dovecot] LDAP for Virtual Domains
by Bryan Vyhmeister 21 May '07

21 May '07

On May 18, 2007, at 11:33 PM, Daniel L. Miller wrote: >> Thank you for that info. Do you mind posting the relevant portions >> of your Postfix config? > main.cf: > .... > virtual_mailbox_base = /var/mail > virtual_mailbox_domains = <all your external / internal domains here> > virtual_mailbox_maps = ldap:/etc/postfix/maps/ldap-virtual.cf > virtual_uid_maps = static:5000 > virtual_gid_maps = static:8 > virtual_alias_maps = hash:/etc/postfix/maps/virtual-aliases > .... > ##EOF > > ldap-virtual.cf: > server_host = localhost > search_base = ou=People,dc=amfeslan,dc=local > query_filter = (&(mail=%s)) > result_attribute = mail > result_format = /%d/%u/ > version = 3 > > The ldap-virtual settings look a little odd - but I'm rather proud > of my gimmick. You look for the mail address matching the sender > (mail = %s). Return that same address - but format it as domain/ > user. Append it to /var/mail and there it is! > > virtual-aliases is a simple file for me - I haven't settled on an > LDAP implentation for aliases yet I'm satisfied with. I'm using > ldap-account-manager for adminstration, and there's no explicit > provision for aliases within LAM or the base schemas used. I just asked Pascal as well how he gets around Postfix asking for mailacceptinggeneralid in order to allow messages to be accepted. How do you get around that? Dovecot is working fine but I can't get Postfix to accept messages because it keeps trying to find mailacceptinggeneralid. Bryan

3 3

[Dovecot] per-user delivery to commands
by martin f krafft 20 May '07

20 May '07

Hi, we are using dovecot IMAP in a complex virtual setup with almost 4000 accounts; postfix hands over to deliver for local delivery into a home directory as stored in the SQL database. That's /srv/vmail/$DOMAIN/$LOCALPART for most of them, but I'd rather not hardcode this scheme anywhere as it's in SQL. By a policy change, we need to insert a filter in this chain and the filter must be called in such a way that it knows where to find the "home" directory since the command needs to read a configuration file in ~/.mailfilt.rc. Thus I am looking for a way to make deliver pass incoming messages via this filter, but I cannot find any way to do that. Ideally I want this to happen before the LDA runs the mail through sieve. As an alternative, is there a command I can call to make dovecot look up $HOME for me so that I can use the dovecot data in the SQL database without making assumptions about the representation? A command that would proxy and convert my request into an SQL select as per dovecot.conf and feed back the result? Then I could use a Maildir delivery programme or even procmail to do the delivery according to the dovecot configruation. Thanks for any insights, hints, tips, help, jokes, flames, and useful information. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus(a)madduck.net will kill for oil!

1 1

[Dovecot] CVS to Mercurial switch
by Timo Sirainen 20 May '07

20 May '07

I've been meaning to switch away from CVS for a few years now, but I was never sure what I wanted to switch to, so I kept delaying it. I finally decided yesterday that Mercurial is pretty nice. The Mercurial repository is available from http://hg.dovecot.org/ (has a nice web interface). I wrote a small Mercurial mini-howto below. I'm not a Mercurial expert yet, so if you know better ways to do some things please let me know. The CVS repositories will still exist for a while, but they won't be updated anymore. If you notice the CVS being referenced somewhere (wiki, docs, etc.) please let me know (or fix yourself in wiki). 1. Fetch the initial repository: - ex. CVS HEAD: hg clone http://hg.dovecot.org/dovecot/ - ex. branch_1_0: hg clone http://hg.dovecot.org/dovecot-1.0/ - sieve plugin: hg clone http://hg.dovecot.org/dovecot-sieve-1.0/ The Sieve plugin currently works only with v1.0. I'll make a new "dovecot-sieve" repository for CVS HEAD later. 2. Update the repository: hg pull hg merge # only needed if you had done any changes hg update # to actually see the pulled changes All of this can be done with fetch extension. You can enable it by adding to ~/.hgrc: [extensions] hgext.fetch = After that you can use "hg fetch" which does all the above 3 commands (as far as I know, haven't really tried yet). 3. If you want to modify the sources, add your name to ~/.hgrc so it goes nicely into changelogs: [ui] username = Timo Sirainen <tss(a)iki.fi> You're able to "hg commit" your own changes into your repository. If you want to publish them, use "hg log" to see the changeset ID, and then use "hg export changesetid" to get patch ("hg export tip" might work too if you just want the last change(?)). You can then email the patch to Dovecot mailing list to get it merged. With CVS the ChangeLog file was updated every 15 minutes. Now the ChangeLog file doesn't exist in the repository at all. Instead it's generated with "hg log --style=changelog" when running "make dist".

6 12

Re: [Dovecot] LDAP for Virtual Domains
by Bryan Vyhmeister 20 May '07

20 May '07

On May 18, 2007, at 11:33 PM, Daniel L. Miller wrote: >> Thank you for that info. Do you mind posting the relevant portions >> of your Postfix config? > main.cf: > .... > virtual_mailbox_base = /var/mail > virtual_mailbox_domains = <all your external / internal domains here> > virtual_mailbox_maps = ldap:/etc/postfix/maps/ldap-virtual.cf > virtual_uid_maps = static:5000 > virtual_gid_maps = static:8 > virtual_alias_maps = hash:/etc/postfix/maps/virtual-aliases > .... > ##EOF > > ldap-virtual.cf: > server_host = localhost > search_base = ou=People,dc=amfeslan,dc=local > query_filter = (&(mail=%s)) > result_attribute = mail > result_format = /%d/%u/ > version = 3 > > The ldap-virtual settings look a little odd - but I'm rather proud > of my gimmick. You look for the mail address matching the sender > (mail = %s). Return that same address - but format it as domain/ > user. Append it to /var/mail and there it is! > > virtual-aliases is a simple file for me - I haven't settled on an > LDAP implentation for aliases yet I'm satisfied with. I'm using > ldap-account-manager for adminstration, and there's no explicit > provision for aliases within LAM or the base schemas used. Thank you. I'll try this out. Bryan

1 0

[Dovecot] IMAP "freezing" on OSX
by Ben Carter 20 May '07

20 May '07

Hi, I've got a problem with dovecot on an Intel Mac OSX box. Basically, I was running an older verion (0.8.?, I think), and everything was fine. Then, when I upgraded to 1.0.0 via MacPorts, I found that periodically the system gets into a state where it simply stops dealing with IMAP requests. This tends to manifest itself as Thunderbird simply stalling, not fetching any new messages or folder contents. Sometimes quitting and restarting Thunderbird will help, but at other times the problem persists even afterwards. It seems to be linked to specific mailboxes (or messages?) - often one "problem folder" will reproduce the effect 100% whilst operating on the rest of the mailbox is fine. The problem /seems/ to often start as a result of trying to move messages between folders. I'm not certain if that's a root cause, though, or simply a consequence of "opening" an affected folder to perform the move. I have a spam folder with a large number (>10000) of messages in it, and trying to file stuff in there is a relatively surefire way to generate the problem. Once it's happened once, it inevitably escalates - restarting the client helps a bit, as does restarting dovecot. However, the only way to "fix" it and restore full functionality seems to be to delete all of the index and dovecot* files from the mailbox and folders... it generally takes a day or so after that before things start to go wrong again. All of this seems to point to corruption of the index files in some way, but the log is universally unhelpful - there are no error messages of any kind showing up there. The actual dovecot instance doesn't appear to crash or even "hang" properly - you can still make inbound IMAP connections OK, it's just that they don't ever give a response to commands that touch the affected mailboxes. Sometimes, I end up with temporary files lying around in the folders in the mailbox - apparently mails which were in the process of being moved when the server "gave up". I'm not sure if this is actually part of the problem, though, or just a symptom. My configuration (from dovecot -n) is: # /opt/local/etc/dovecot/dovecot.conf ssl_disable: yes disable_plaintext_auth: no login_dir: /opt/local/var/run/dovecot/login login_executable: /opt/local/libexec/dovecot/imap-login mail_location: maildir:~/Library/Mail/IMAP auth default: passdb: driver: pam args: * userdb: driver: passwd I'm running this on my personal machine, so there's only one user on the system, which I have set up using MailDir (on HFS). There's a fair bit of mail in many of my folders, but I doubt that's the problem as the previous version didn't seem to have any issues... I'm doing mail delivery using postfix directly into the maildir folders. That doesn't seem to be affected at all by this, though - mail still arrives fine even when Dovecot is failing to serve the folder contents to IMAP clients... you just can't see it ^-^ Has anyone seen an effect like this? Or does anyone have any pointers as to what I could try to debug it? Any suggestions would be very greatly appreciated! Thanks! -- Ben Carter - ben(a)gunk.demon.co.uk / ben(a)saillune.net (preferred)

4 6

[Dovecot] Thinking Outside the Box - Extending IMAP
by Marc Perkel 19 May '07

19 May '07

Here's some thoughts I'd like to throw out there. I know it's not standard IMAP protocol but someone has to try new ideas first and I want to see what people (Timo) think of this. IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Here's my initial thoughts on this. Suppose we extended IMAP to include an EXECUTE command as follows: EXECUTE command parameter, parameter .... On the server side is a config file that has the commands that execute will allow and what programs they run. When the execute command is seen by Dovecot then Dovecot runs the program in the list with the parameters passed. For example, suppose there is a command to add a user to a server side blacklist. 100 execute blacklist add joe(a)smith.com 100 ok Dovecot would open a two way connection to the server application allowing the client to talk to any application that is configured and can send and receive text. The connection persists until the server end terminates or the client closes the connection. With a tool like this one can write generic applications easily that would greatly expand what email clients can do interacting with the server. Not only can setting be changes but you could interact with server side calendars, pick up voice messages from phone systems, run any sort of groupware, all over a generic IMAP connection with this simple extension. Example: 100 EXECUTE calendar 100 ok 100 list schedule today 8:00 10:00 100 8:00 make coffee 100 9:00 meeting with boss 100 9:30 Call Joe Blow at 415-555-1212 100 ok 100 quit 100 ok One thing I'd like to use it for is an outgoing SMTP connection to send outgoing email over IMAP. A session might look like this: 999 EXECUTE smtp 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 999 helo ctyme.com 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] 999 mail from:marc@perkel.com 999 250 OK 999 rcpt to:dovecot@dovecot.org 999 250 Accepted ...... 999 quit 999 OK Who likes this idea?

10 23

[Dovecot] [Fwd: An invitation to the "morg" (Message Organization) mailing list]
by Luigi Rosa 19 May '07

19 May '07

This messages has been posted on SquirrelMail development mailing list. Maybe someone is interested in morg mailing list. Ciao, luigi -------- Original Message -------- Subject: [SM-DEVEL] An invitation to the "morg" (Message Organization) mailing list Date: Sat, 19 May 2007 17:08:03 +0300 To: squirrelmail-devel(a)lists.sourceforge.net Hello all, [Note: Yes, I'm not gone after all... There has been a change of plans! I'll be mostly active, time permitting] There is a new IETF effort on IMAP standards, continuing on the work of "IMAPExt" Working Group which has practically closed now. I'm sending this here because people might be interested in joining it and either contributing actively or simply keeping an eye on what will be available in IMAP servers soon. Personally I'm very interested on message and mailbox annotations / metadata, but some other stuff like dynamic, multi-mailbox, persistent searches and virtual mailboxes might be of more interest to you. Anyway, you can join this effort by subscribing to the morg mailing list: https://www1.ietf.org/mailman/listinfo/morg http://www.ietf.org/maillist.html To quote Dave Cridland about the purpose of the list: ====== Quote start ======== This list has been created to look carefully at how existing mail clients search through, sort, and generally organize email. We're also going to - hopefully - have client developers talk about what they'd like to be able to do. There's another group that might be interested in this, too - the "desktop search" people might well be interested in the ability to search effectively through remote message stores. Kjetil commented (on IMAPEXT) that this area might be very interesting to IMAP webmail people, who can't simply download everything and work locally, so if there are any IMAP webmail developers about it'd be interesting to hear from you, and if anyone knows any, please invite them to join. Meanwhile, we're also going to look at what features we have on the store - the IMAP server - that we can leverage for this. There's a number of RFCs and Drafts in the area of searching, organization, etc, and we'll need to ensure we're all aware of the current state of play. So, IMAP specialists need to start to enumerate these - any volunteers? It occurs to me that both the above might benefit from a Wiki page or two - Lisa, is there an Apps Wiki we can use for this, or should I just set one up? [For anyone new to the IETF, Lisa and Chris are the Applications Area Directors] Finally, we'll look at what new work we can do to satisfy client requirements, write up a draft charter, and move to BOF (the first stage in forming a new IETF working group), aiming to form a new working group to do the work, and produce RFCs as we decide is appropriate. I'd like to take a decision on going down this road after Chicago in the summer, hopefully ready for a BOF at the IETF in December. I personally think our ultimate output is likely to be some Standards Track and some Experimental specifications for extensions, and maybe a couple of Informational documents on how this stuff ties together. I'd also note that searching is something that, like a lot of IETF work, has patent minefields in places - please do read that Note Well stuff, and let us know of any IPR you're aware of as soon as you can. ====== Quote end ======== -- / +--[Luigi Rosa]-- \ Sheridan: We have an open door policy. Ivanova: And an open airlock policy. --"The Illusion of Truth", Babylon 5

1 0