- dovecot - dovecot.org

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

[Dovecot] permissions on some dovecot directories
by Arkadiusz Miskiewicz 19 May '07

19 May '07

Hello, What smallest permissions are needed on directories: /var/run/dovecot /var/run/dovecot/login /var/lib/dovecot dovecot run as dovecot:dovecot. Currently I have 775 dovecot:dovecot /var/run/dovecot 750 root:dovecot /var/run/dovecot/login 755 root:root /var/lib/dovecot -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/

1 0

[Dovecot] Maildir subfolder conversion from courier-imap
by Remy Blank 19 May '07

19 May '07

Hello, I am trying to convert a maildir that was managed by courier-imap up to now to dovecot. I am using the courier-dovecot-migrate.pl script as follows: courier-dovecot-migrate.pl --convert --recursive ~/Maildir However, this command only seems to convert the base maildir, but not all the subfolders. I thought that that's what the --recursive option was for. Is the command above supposed to convert the base maildir as well as the subfolders, or should I run the command on all subfolders separately (e.g. using a shell script)? Thanks. -- Remy

2 2

Re: [Dovecot] Replication plans
by Bill Boebel 19 May '07

19 May '07

On Fri, May 18, 2007 1:42 am, Troy Benjegerdes <hozer(a)hozed.org> said: > I'm going to throw out a warning that it's my feeling that replication > has ended many otherwise worthwhile projects. Once you go down that > rabbit hole, you end up finding out the hard way that you just can't > avoid the stability, performance, complexity, and whatever problems. > .. > I've found myself pretty much in the same "all roads lead to the > filesystem" situation. I don't want to replicate just imap, I want to > replicate the build directory with my source code, my email, and my MP3 > files. One of the problems with the clustered file system approach seems to be that accessing Dovecot's index, cache and control files are slow over the network. For speed, ideally you want your index, cache and control on local disk... but still replicated to another server. So what about tackling this replication problem from a different angle... Make it Dovecot's job to replicate the index and control files between servers, and make it the file system's job to replicate just the mail data. This would require further disconnecting the index and control files from the mail data, so that there is less syncing required. i.e. remove the need to check directory mtimes and to compare directory listings against the index; and instead assume that the indexes are always correct. Periodically you could still check to see if a sync is needed, but you'd do this must less frequently. I agree that there are already great solutions available for replicated storage, so this would allow us to take advantage of these solutions for the bulk of our storage without impacting the speed of IMAP. Bill

3 2

Re: [Dovecot] dbox redesign
by Bill Boebel 19 May '07

19 May '07

On Sat, May 12, 2007 9:10 am, Timo Sirainen <tss(a)iki.fi> said: > Fast copying > ============ > > Would be nice if copying a message from one mailbox to another wouldn't > require actually reading+writing the whole message contents. But I can't > really figure out how to implement this without requiring that there is > only a single dbox storage which contains the mails for all the > mailboxes, and the mailboxes themselves are just Dovecot's index files > containing pointers to the dbox storage. > > The problem with having everything in one storage is that if the index > files are broken, the messages can't be placed into correct mailboxes > anymore. > > Although one possibility would be treat mailboxes a bit similarly than > keywords. So that when a message is copied to another mailbox, the > message in dbox file is updated to contain information that it exists in > such and such mailboxes. Hmm. Perhaps that would be good enough, yes. > Yes, I think treating mailboxes similary to keywords is ideal. There really is no reason to physically separate mailboxes on disk. All that is needed is this logical separation if it can be done in a reliable way. Or maybe track this in mailbox-specific index files, and also have a corespodning text file that stores a list of messages that are contained in that mailbox... similar to maildir's dovecot-uidlist file. Then if you lose the index you can rebuild the index from the text file. Bill

4 7

[Dovecot] dovecot-shared being ignored?
by bhayden＠umn.edu 19 May '07

19 May '07

So, I'm working on a shared folder. Everything is nice except for one bit. My dovecot-shared file in the Maildir is either being ignored, or doesn't work the way I think it does. Any messages copied into the Maildir using a mail client are mode 660 and owned by the user who did the copy. Perms on the dovecot-shared file are 700 (I'm using Solaris ACLs in addition to the Dovecot ACLs in order to prevent unauthorized access via means that don't pass through Dovecot's IMAP server... ie SFTP/SCP, and so I'm using 700 with a rwx mask and access to the file set per user in the Solaris ACL). The message files being created 660 means they are accessible via SFTP/SCP to anyone in the group, and we have a single one for (nearly) all users. This is not really acceptable, so if anyone can offer guidance on the dovecot-shared that'd be great. I checked the wiki, and it has very minimal information. -Brian

2 1

[Dovecot] Virtual mailbox plans
by Timo Sirainen 18 May '07

18 May '07

Configuration ------------- There could be global and user-specific configuration files, similar to how ACLs work. I think the global virtual mailboxes should be only defaults though, so that users could delete them and create a new mailbox (virtual or non-virtual) with the same name. The global virtual mailboxes could be described in a single file, such as: Trash deleted Work/My Unseen (mailboxes "box1" "box2" "box2/*") or to "tss(a)iki.fi" to "timo.sirainen(a)iki.fi" unseen So the format would be <virtual mailbox name> LF <search condition, allowed to wrap to new line> LF LF <next virtual mailbox, etc.> Per-user virtual mailboxes could also be listed in a similar file. If the search condition is empty, a globally defined virtual mailbox has been deleted. Another way would be to have per-mailbox dovecot-virtual files, but I'm not sure how global virtual mailboxes could then be easily deleted. Also having all of them in a single file makes listing the mailboxes pretty fast. The search condition would be a standard IMAP SEARCH reply, with the exception of the mailboxes parameter to specify what mailboxes are used. Virtual mailboxes would be implemented as a new mail storage backend, so their namespace configuration would be like: namespace private { prefix = "virtual/" location = virtual:~/virtual:GLOBAL=/etc/dovecot/virtual-globals.conf } Syncing ------- ~/virtual directory would contain index files for the virtual mailboxes. If the index files don't exist, a full resync for the virtual mailbox is done. This means opening all the real mailboxes configured for the vbox, running the SEARCH command and adding the returned UIDs to the vbox's indexes. The index would contain at least mailbox ID and message UID numbers. Probably would be a good idea to also save UIDVALIDITY numbers just to be safe, although that's a bit of a waste of space and it could be handled in other ways too, such as changing the mailbox ID whenever its UIDVALIDITY changes.. Mailbox IDs would be mapped to names in mailbox list index. This index already exists, although there still seems to be some bugs in it. At least creating a new list index has a race condition. I should look into making the list index a bit more realiable. Also the list indexes work only with Maildir++ layout currently. After the vbox has initially been synced, it needs to also handle updates. I think optionally the updates could be done the same way as full sync (opening all mailboxes to see if there are changes), but a faster way would be to update the virtual mailboxes immediately when the real mailboxes are being modified. So IMAP, POP3 and deliver all need to be aware of the virtual mailboxes and what real mailboxes are mapped to what virtual ones. Whenever doing a change that causes the message to either be added to or removed from a virtual mailbox according to their rules, the virtual mailbox's index is updated immediately. Being able to determine this change quickly might be the biggest change required to Dovecot's base code. Changes ------- Virtual mailboxes would share their state with the real mailbox, so any flag changes done in the vbox would be immediately changed in the real mailbox as well. The same goes for expunges. Virtual mailboxes' transaction logs would use different records for expunges and removals. Expunges would be handled normally, but removals wouldn't be removed from the in-memory view of the mailbox until EXPUNGE command was given (although they would be removed from dovecot.index immediately, so new sessions wouldn't see them). This makes it possible to have a vbox with only unseen messages, but without the message getting expunged immediately after a client opens the mail. So the EXPUNGE command could act as a "session synchronization" command. And of course it would also expunge the messages that had been marked as \Deleted.

1 0