Re: [Dovecot] mbox, hierarchical folders/folders and IMAP
On 24/12/2011 10:31, Stan Hoeppner wrote: With mbox storage, an IMAP FOLDER contains only sub folders or it contains only messages. It CANNOT contain BOTH. Dovecot can store both folders and messages in a folder, under mbox. See http://wiki2.dovecot.org/MboxChildFolders Bill
Re: [Dovecot] Upgrade/Migration
On 23/12/2011 19:20, sottile...@rfx.it wrote: New box (supposed): CentOS 6.x (32/64 bit ? ), dovecot 2.04, mbox format Any hints/comment appreciated ;-) Don't use Dovecot 2.0.4, even if your distro tries to tempt you into doing so by including such a version. Whilst it looks like a stable version number, there were a number of issues with early Dovecot 2.0.x. Instead use 2.0.latest. Starting from http://www.dovecot.org/download.html you could find http://packages.atrpms.net/dist/el6/dovecot/ which provides 32- and 64-bit RPMs of Dovecot 2.0.16. Bill
Re: [Dovecot] Using Amazon S3 storage for Maildir ?
On 20/12/2011 05:29, Timo Sirainen wrote: On 19.12.2011, at 19.35, Forrest Aldrich wrote: I wonder if anyone has tried using an IMAP server with Amazon S3 as a backend. There would be many factors to consider (speed, etc). However, moreso, I don't know that Maildir(++) would support multiple folders that might be linked into the cloud. For example, higher-I/O local incoming mail is on disk, some folders archived on S3. Could be easily done by simply creating another account and storing its Maildir in S3 -- Maybe [sm]dbox with alt storage set to S3? http://wiki2.dovecot.org/MailboxFormat/dbox#Alternate_storage Also consider using the S3QL ( http://code.google.com/p/s3ql/ ) filesystem, which stores files chunked on the backend (e.g. Amazon S3). This ought to work well for dbox alternate storage, and archived mbox mail (though it may be worth arranging for indexes to be stored locally). Bill
Re: [Dovecot] Ubuntu package for dovecot 2.0.x from debian package
On 23/07/2011 10:16, Robert Schetterer wrote: mkdir /usr/src/dovecot_2.0.13 cd /usr/src/dovecot_2.0.13 download i.e wget ... dovecot_2.0.13-0~auto+24_amd64.changes wget dovecot_2.0.13-0~auto+24.debian.tar.gz wget dovecot_2.0.13-0~auto+24.dsc wget dovecot_2.0.13-0~auto+24_i386.changes wget dovecot_2.0.13.orig.tar.gz dpkg-source -x *.dsc Provided you have the relevant line in your apt sources deb-src http://xi.rename-it.nl/debian/ testing-auto/dovecot-2.0 main you can do all of the above with a single command apt-get source dovecot Bill
Re: [Dovecot] My status
On 22/07/2011 12:49, Timo Sirainen wrote: 2. My new apartment gets too hot (30C) when it gets over about 22C outside, which is almost daily. So my brain melts in the heat and I don't have energy to do much of anything. But I finally yesterday bought an air conditioning machine, which should solve this problem. I don't know why I didn't buy it weeks ago. I find that actions which involve spending money typically get delayed while I build up sufficient motivation to overcome the natural desire not to spend money. So I wonder if you might be helped by having a (PayPal) Donate button on the Dovecot website. If forty people donated €10 each, then that might buy a free-standing refridgerative air cooler. OK, you've already bought an air cooler, so that's not a brilliant example. But I suspect you will likely need something else later. New laptop, new chair, something like that. Bill
Re: [Dovecot] Performance with 200k messages in Maildir
On 18/07/2011 11:27, Vegard Svanberg wrote: What should I expect performance-wise if I put 20 messages in a Maildir store and use two or three MUAs (mutt and Thunderbird), on an Athlon dual core 2GHz with SATA drives in software RAID (Linux)? Like; would it be useless/crawling, usable or pretty fast. I imagine MUA startup / first time folder read would be slow, but daily use more or less ok. Thanks to Dovecot's indexing, I imagine I would be better off interfacing Mutt to Maildir via IMAP and Dovecot rather than accessing Maildir/ directly? 200,000 messages under Maildir in a single folder. You will tend to have a relatively large number of inodes compared to the relative overall scale of the system. This will tend to make backing-up a nuisance. One thing you could consider is storing your mail under mdbox. This should drastically reduce the number of inodes. Just remember that under mdbox the so-called indexes are actually critical data files (i.e. they cannot be re-created like they could be with Maildir or mbox). Bill
Re: [Dovecot] Dovecot indexes
On 08/07/2011 11:35, Mike Prispan wrote: could someone answer my following questions about dovecot indexes? - If I delete dovecot indexes, it recreates them without any problem, right? AFAIK, for mbox and Maildir: True, for sdbox and mdbox: False. - If dovecot recreates indexes, it does not affect users (they don't have to download all emails again, seen flag is not lost etc.) or is there any problem? AFAIK this is true, at least for the cases where indexes can reasonably be recreated (mbox and Maildir). AFAIK, under mbox, Dovecot stores UID and flags in the message headers; under Maildir, Dovecot stores UID in dovecot-uidlist file, and flags in filename. AFAIK, under sdbox and mdbox, UID and flags are stored (only) in indexes. sdbox and mdbox indexes cannot be recreated. If sdbox or mdbox indexes are lost, Dovecot will re-create them, but losing data to a greater or lesser extent. - If I use mail_location = ...:INDEX=MEMORY, it recreates indexes every time dovecot is (re)started, right? Does it have any negative effect except performance/resources? AFAIK, INDEX=MEMORY causes Dovecot to recreate indexes every time a mailbox is opened, not just when Dovecot is restarted. Not aware of any negative effects other than the categories mentioned, but I can't claim to be an expert. - Is there any difference in indexes for mbox and maildir (related to previous questions)? See http://wiki2.dovecot.org/IndexFiles Bill
Re: [Dovecot] what to expect from changing index location
I concede that this is most likely a WIBNI (Wouldn't It Be Nice If...) and most likely will end up on the list of WIBNIs, never to be implemented. But I would like to take the brainstorm forward another step, just to see. On 30/06/2011 05:35, Timo Sirainen wrote: To allow for migration of existing installations, it might be an idea to make Dovecot look for both ddb and index when opening, but use ddb when creating new files. This makes it annoying. It wastes disk I/O.. OK fair enough. (Though not actually *disk* I/O /per se/. It is not like we would create any further sync-to-disk requirement (i.e. requiring to wait for another revolution), but rather that it would require more system calls.) Presumably it's important that it works correctly for existing users with minimal risk of problems if people take the path of least resistance (and people don't read the release notes). I imagine many people will not be bothered about some extra failed open calls. But we should still have a way to tune for optimal I/O usage so that systems which are up against it for performance can be tuned. OK, how about this: A configuration directive like this: filename_word_ddb = ddb index This specifies a list of words which will be tried in the place where we mean to say ddb in a filename. If the directive is not present, then the default value would be as per the example above. This should allow existing installations to work correctly using old configuration files. If a new file needs to be created, then it will use the first entry in the list. So new installs will use ddb for all such files, and will be optimal where the file exists already, but mildly sub-optimal where the file doesn't exist (because Dovecot would have to try opening each possible variation before being able to know that the file was not openable). In order to tune for I/O, the administrator can reconfigure the list to be just ddb. Old installs will have existing files with index with new files being created with ddb. This will work correctly, but with some degree of sub-optimality. In order to tune for I/O, the administrator would need to: 1. Configure filename_word_ddb to ddb index ddb (to mitigate the race condition where a file is renamed after ddb is tried but before index is tried) 2. Re-name existing files (from ...index... to ...ddb...) 3. Check that no files with old names exist 4. Change the list to ddb This means that things should work correctly by default, and only get messed-up when people actively go and try to optimise things without paying attention to what they're doing. BTW. Cyrus also has cyrus.index file, which is the only storage for message flags. So Dovecot isn't alone with this. Though two is still a small sample compared to the weight of existing terminology usage. Besides, Cyrus is somewhat in-bred, and we would expect it to be quirky :-) Bill
Re: [Dovecot] Problem accessing Dovecot mailing lists via IMAP
On 30/06/2011 05:49, Timo Sirainen wrote: On Tue, 2011-06-28 at 11:54 +0100, William Blunn wrote: I recently tried to look at the Dovecot mailing lists through an already-configured IMAP profile, which had worked fine in the past. Yeah, it was broken in two ways. Should be working in a few minutes, hopefully :) Marvellous, thank-you. I couldn't get the old profile to work. I raised a new profile, but couldn't get it to work using an empty password. I tried using a password of anonymous, and Thunderbird is now Downloading message header 24888 of 59255 Thanks again. Regards, Bill
Re: [Dovecot] [Urgent] Email Retrieval from remote servers doesn't use Dovecot
On 30/06/2011 14:08, Shazia Javed wrote:
Thank you for the reply. Now I have relatively better understanding of Dovecot
and email service components (MUA, MTA, MRA, etc). However, I am still
struggling with the relevant conceptual understanding, and need your help:
I have installed 'getmail' as I read that it offers ease-of-use and is
relatively more secure. So far I have managed to download emails from Inbox and
Sent folder. All the downloaded emails go to single folder 'new' from 'Maildir'
directory. Please tell me if there is a way (configuration) to download emails
in respective folders.
getmail appears to support delivery to an arbitrary Maildir folder.
See getmail documentation.
You might want to read up about Maildir to see how it works. In
particular you need to know that mail is delivered to a directory new
(the delivery process involves the directory tmp, but the message
isn't considered delivered until it reaches the directory new), but
gets moved to a folder cur when the Maildir is looked at. So mail
could be in either directory new or cur.
(The design of Maildir attempts to address various problems, and only
partially succeeds, and in other cases makes things worse than they
would have been otherwise. But despite its flaws, it still has some
strengths, such as reliability, (relative) simplicity, wide support, and
the ease by which a message store can be queried/interrogated.)
Also, is there any need for Dovecot now? As I see it, I have managed to
download emails from remote servers in maildir format using getmail. How and
why would Dovecot fit in? Will Dovecot (via deliver and sieve) assist in
segregated email storage (i.e. INBOX in 'new', DRAFTS in '.draft/new' etc).
It might be handy to have Dovecot installed as it would mean you could
see into the mail folders using an IMAP client such as Thunderbird.
This will probably make it easier to get a handle on which messages are
in which folders than trying to look in the Maildir directories directly.
IMAP has a special folder called INBOX which appears as the Inbox in
most IMAP clients.
Under Maildir, in the default location, INBOX can be found at
~/Maildir/{new,cur,tmp}
Other folders are mapped into directories, for example
the mail folder Sent will appear at ~/Maildir/.Sent/{new,cur,tmp}
Nested mail folders are flattened into a single directory level in the
filesystem, with the folder levels separated by dots, so
the mail folder Projects/PJ1 will appear at
~/Maildir/.Projects.PJ1/{new,cur,tmp}
(The above is the default way for Maildir to work. However, Dovecot can
be configured to map IMAP folders into Maildir directories in other ways.)
Bill
Re: [Dovecot] dovecot, mdbox and indexes
On 30/06/2011 13:28, Angel L. Mateo wrote: We are now trying to migrate to the third scenario and using mdbox. These errors cause a corrupted index and we have to manually delete the user's index so he could read his mail again. * I connect then to a server that have no index for me. The only problem is that the previously deleted mail appears again. * I connect then to a server with an outdated index: this is the problem. I have only the messages in that outdated index. The mail received since then has disappeared (although I could receive new mail). How could I solve this problem? Is this really a problem? Should I use a shared storage for indexes? What is the best configuration for a high availability service? ! DANGER, DANGER !! Under mdbox, the so-called indexes are not indexes in the traditional (database) sense of the word (a file maintained alongside the main data file which is used to speed up access to the main file, and can be regenerated at will), but rather are (binary) database files which contain crucial metadata which is not held anywhere else. These filed cannot be regenerated at will. For example: The so-called map index (message store database) contains a (flat) list of all messages in a (user's) mailstore together with their reference counts, which storage file they're stored in. The folder index (folder message metadata database) in each folder directory contains a list of the message numbers which are in that folder. Those message numbers identify a particular message in the message store database, which identify a particular m.* storage file, and where within that file the message is. Lose these files, and you destroy the information about: * which message is supposed to be in which folder, * which messages are supposed to be deleted and which aren't, and * all message keywords. Under mdbox, losing these files buggerises the mailstore. You may wish to read http://wiki2.dovecot.org/MailboxFormat/dbox ... with dbox the Index files actually contain significant data which is held nowhere else. Index files for both *single-dbox* and *multi-dbox* contain message flags and keywords. For *multi-dbox*, the index file also contains the map_uids which link (via the map index) to the actual message data. This data cannot be automatically recreated, so it is important that Index files are treated with the same care as message data files. Regards, Bill
Re: [Dovecot] NFS mail storage
On 30/06/2011 00:40, Stan Hoeppner wrote: If you can live with the folder tree limitations of mbox Did you mean with or without considering http://wiki2.dovecot.org/MboxChildFolders ? Bill
Re: [Dovecot] [Urgent] Email Retrieval from remote servers doesn't use Dovecot
On 29/06/2011 13:19, Shazia Javed wrote: --- Objective: --- We need to download emails from remote server using Dovecot and thunderbird. Dovecot doesn't download e-mail from other servers. Our objective is to store emails in maildir or mbox format, and process them as part of our research project. --- Problem: --- Dovecot works for localhost, but not for remote servers. How do I know? Because thunderbird downloads emails in its default location (specified in settings) and not in maildir or mbox folders. If I send mail to user@system_name using mail command, dovecot works and thunderbird shows the email stored in maildir folder. But for email from id@yahoo.com goes to thunderbird's default folder and are browsed from there. It looks like you want to get e-mail from someone else's mail server and store it in maildir or mbox format on your server. You could do this by pulling the mail from someone else's mailserver using Thunderbird, then using Thunderbird to move it across to an account configured to access your server by IMAP. Alternatively you could do it by retrieving the mail using fetchmail on your server and have it delivered to an address on your server. This would have the benefit of being more reliable and more scriptable. - Commentary: - As is obvious from the commands and output listed above that dovecot is running, listening on 110 and 143 - but only for localhost. When I try to telnet mail.ut.ee 110/143 I get to see IMAP4/POP3 ready rather than Dovecot ready. That is the expected behaviour. You installed Dovecot on your server, ergo it is only on your server. Installing Dovecot on your server doesn't magically install and configure it on other people's servers. - Queries - Shouldn't I get Dovecot ready message for remote servers as well? No; you only installed it on your server. It is an MRA and we shouldn't be required to install it on remote servers, right? If, by MRA, you mean Mail Retrieval Agent, then no, Dovecot is not an MRA. What should I do to make dovecot work for remote servers? Dovecot, in and of itself, won't work for remote servers. You may be able to do what I think you want to do by pulling the mail from the remote server on to your server. You may want to look into fetchmail. Bill
Re: [Dovecot] what to expect from changing index location
On 28/06/2011 17:13, Davide Vaghetti wrote: I have one thousand virtual users with mdbox mailbox format and 10 GByte quota. I have noticed some performance problem related to I/O (the mailbox disk is a 6TB raid1+0 on ISCSI), so I want to put the index files on a different disk. My actual mail_location is: mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox and I want to switch to mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox:INDEX=/var/indexes/%-1.1u/%u/ But I cannot figure out a pair of things: - - do the switch trigger the rebuilding of the index files? ! DANGER, DANGER !! Index files cannot be re-generated under mdbox Go away and read http://wiki2.dovecot.org/MailboxFormat/dbox ... with dbox the Index files actually contain significant data which is held nowhere else. Index files for both *single-dbox* and *multi-dbox* contain message flags and keywords. For *multi-dbox*, the index file also contains the map_uids which link (via the map index) to the actual message data. This data cannot be automatically recreated, so it is important that Index files are treated with the same care as message data files. If you don't already know this, then you probably shouldn't even be using mdbox. - - can I get rid of all the old index files? NO! - - how much the index files (no fts squat) can grow? First solve your understanding problem with mdbox, then worry about details such as this. Bill
Re: [Dovecot] what to expect from changing index location
In fact, under sdbox and mdbox, calling these files index files is misleading because it implies that they can be re-created, leading to situations like this. Such situations could result in catastrophic data loss. Whilst we could say it is user error, users could argue that it is common knowledge that files referred to as index files can be re-created from the data files. In reality, these so-called index files are actually database files containing critical data. They happen to use the same format as Dovecot uses for index files in connection with mbox and maildir, but they contain data which is held nowhere else and cannot be recreated. Perhaps the per-mailbox index files for sdbox and mdbox should be re-named to message metadata databases, and the map index should be renamed to message store database. Specifically we should avoid the word index. By including the word database, we make it clearer that these files contain data. Timo, what do you reckon? Regards, Bill On 29/06/2011 17:36, William Blunn wrote: On 28/06/2011 17:13, Davide Vaghetti wrote: I have one thousand virtual users with mdbox mailbox format and 10 GByte quota. I have noticed some performance problem related to I/O (the mailbox disk is a 6TB raid1+0 on ISCSI), so I want to put the index files on a different disk. My actual mail_location is: mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox and I want to switch to mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox:INDEX=/var/indexes/%-1.1u/%u/ But I cannot figure out a pair of things: - - do the switch trigger the rebuilding of the index files? ! DANGER, DANGER !! Index files cannot be re-generated under mdbox Go away and read http://wiki2.dovecot.org/MailboxFormat/dbox ... with dbox the Index files actually contain significant data which is held nowhere else. Index files for both *single-dbox* and *multi-dbox* contain message flags and keywords. For *multi-dbox*, the index file also contains the map_uids which link (via the map index) to the actual message data. This data cannot be automatically recreated, so it is important that Index files are treated with the same care as message data files. If you don't already know this, then you probably shouldn't even be using mdbox. - - can I get rid of all the old index files? NO! - - how much the index files (no fts squat) can grow? First solve your understanding problem with mdbox, then worry about details such as this. Bill
Re: [Dovecot] what to expect from changing index location
On 29/06/2011 18:00, William Blunn wrote:
Perhaps the per-mailbox index files for sdbox and mdbox should be
re-named to message metadata databases, and the map index should
be renamed to message store database.
Also it might be an idea to change the filenames of the files to avoid
the word index.
Perhaps use something like ddb instead (means Dovecot database).
So,
${location}/mailboxes/INBOX/dbox-Mails/dovecot.index
${location}/mailboxes/INBOX/dbox-Mails/dovecot.index.cache
${location}/mailboxes/INBOX/dbox-Mails/dovecot.index.log
${location}/storage/dovecot.map.index
becomes
${location}/mailboxes/INBOX/dbox-Mails/dovecot.ddb
${location}/mailboxes/INBOX/dbox-Mails/dovecot.ddb.cache
${location}/mailboxes/INBOX/dbox-Mails/dovecot.ddb.log
${location}/storage/dovecot.map.ddb
To allow for migration of existing installations, it might be an idea to
make Dovecot look for both ddb and index when opening, but use ddb
when creating new files.
Regards,
Bill
[Dovecot] Problem accessing Dovecot mailing lists via IMAP
I recently tried to look at the Dovecot mailing lists through an already-configured IMAP profile, which had worked fine in the past. But it failed saying that the authentication method was not supported. http://www.dovecot.org/mailinglists.html says: You can get access to the IMAP archives by using *dovecot.org* as the hostname, *anonymous* as the username and an empty password. It's also possible to use ANONYMOUS authentication mechanism if your client supports it (few do). I noticed that my e-mail client was configured to use the server imap.dovecot.org, so I changed it to dovecot.org. But it still complains that the authentication method is not supported. I am using Thunderbird 3.1 over Windows 7 64-bit. Thunderbird was configured for Password, Transmitted insecurely (and this option was not working). I have tried the other authentication options available in Thunderbird. Encrypted password: Does not work; same problem Kerberos / GSSAPI: Does not work; same problem NTLM: Does not work; same problem Any ideas? Bill
Re: [Dovecot] v1.1.20 vs v1.2 v2.0
On 23/05/2011 20:47, Adam wrote: I am currently running v1.1.20 and was wondering if there is any compelling reason to upgrade to v1.2 or v2.0? For example is there any security updates in v1.2 or v2.0 that aren't included in v1.1.20? The other major thing I would be interested in knowing is there any speed enhancements in the newer versions? I am using basic PAM Auth and Maildir mailboxes on a Linux box. Let me know if you need any more information to answer my questions. 1.1 doesn't appear to have been touched since 2009-11-09 1.2 last is 1.2.17 dated 2011-05-11 2.0 last is 2.0.13 dated 2011-05-11 So it looks like 1.1 is unmaintained 1.2 is maintained for security and bug fixes 2.0 is maintained The differences between 1.1 and 1.2, and 1.2 and 2.0 can be seen at http://www.dovecot.org/doc/NEWS-2.0. A compelling reason for me to use 2.0.x was the inclusion of multi-dbox / mdbox ( http://wiki2.dovecot.org/MailboxFormat/dbox#Multi-dbox ). Bill
Re: [Dovecot] Seperator
On 12/04/2011 22:35, Carsten Laun-De Lellis wrote: I hope to get some help on the separator. I am sure that I hava a wrong understanding what the separator is. I thaught the separator is the delimiter within the imap folder structure. The 'separator' directive controls what appears in the IMAP layer only, and does not affect how Dovecot stores e-mail in the filesystem. If you want Dovecot to store Maildir folders in hierarchical directories, you should be able to do this by specifying relevant parameter in the mail location. See: http://wiki2.dovecot.org/MailLocation/Maildir#Directory_layout http://wiki2.dovecot.org/MailLocation/Maildir#Mailbox_directory_name Basically, read this page through: http://wiki2.dovecot.org/MailLocation/Maildir Bill
Re: [Dovecot] Problem in Mail receiving
On 25/04/2011 05:53, Anshul Chauhan wrote: im using dovecot-1.0.7-7.el5 on CentOS 5.5, i'm getting freqent problem of recieving multiple copies of mails received from outside my domain. this problem comes with some users and not with all the users, maillog shows the same mail downloaded again 1.0.x is somewhat ancient and support for it will be limited. Consider upgrading to 2.0.11 or later. There are ready-built binary RPMs for RHEL and clones like CentOS. See: http://wiki2.dovecot.org/PrebuiltBinaries#RPMs_of_newer_Dovecot_and_Sieve_packages http://atrpms.net/name/dovecot/ http://atrpms.net/name/dovecot-sieve/ Regards, Bill
Re: [Dovecot] Having trouble getting Dovecot to read a ~/Maildir configuration
On 21/04/2011 03:32, Stan Hoeppner wrote: A question about where the mail is actually supposed to be delivered to... initially I configured Exim4 to delivery the email to ~/Maildir and I noticed as you saw in the list directories like ~/Maildir/new and ~/Maildir/cur, however once I configured Evolution to login to Dovecot I noticed the directories ~/Maildir/INBOX/new and ~Maildir/INBOX/cur were created. Should therefore Exim4 be configured to ~/Maildir/INBOX instead of just ~/Maildir ? It looks like your IMAP clients are configured to use a server folder of INBOX ... such a thing as you might need to do using Courier-IMAP (were you previously using Courier-IMAP?) Your IMAP clients aren't seeing this folder so are creating it. But configuring IMAP clients with a server folder of INBOX is not required with Dovecot because Dovecot does not require this INBOX prefix to all folders. (Though you can configure Dovecot to emulate the Courier-IMAP behaviour if you like.) Exim is delivering to the root folder, but your IMAP clients are looking in the folder INBOX. Because your clients are prefixing INBOX to all folder names, you can't get up to the root to see the messages. Check the configuration of your IMAP clients to see if they have a server folder configured for INBOX (it may be called something other than server folder depending on what the IMAP client decides to call it). Configuring Exim to deliver to $HOME/Maildir/ is normal and correct. You should get messages delivered as files to the directory $HOME/Maildir/new. Configuring Dovecot with a mail location of maildir:~/Maildir is normal and correct and should cause Dovecot serve up (as the real IMAP INBOX folder, not a folder called INBOX) the messages previously delivered by Exim using the above configuration. There should be no need to specify LAYOUT=fs, unless you actually want that. Check the configuration of your IMAP clients. Another thing you could do is to make a fresh install of Thunderbird 3.1 and see what that thinks is in that IMAP account. A fresh install of Thunderbird 3.1 will not have any spurious server folder configured by default and should show you all the messages in the real INBOX (not a folder called INBOX). Once you can see the messages in Thunderbird, you will then know that it is a configuration issue in your other IMAP clients. Regards, Bill
[Dovecot] Thunderbird 3.1 unable to delete subfolder of Trash under mdbox
Thunderbird 3.1.9 over Windows 7. Dovecot 2.0.11 (2:2.0.11-0~auto+41 from http://xi.rename-it.nl/debian/ source on 8 Apr 2011) over Ubuntu 10.04 LTS. Trying to set up a Dovecot system with mdbox. But I also wanted to keep some Maildir. So I ended up with both mdbox and Maildir side-by-side and noticed an issue. On this system, Dovecot's global mail location is configured with maildir:~/Maildir I have a two users configured in a password-file passdb/userdb: One using the Dovecot global mail location (maildir:~/Maildir) the other with an override mail location (userdb_mail) of mdbox:~/mdbox (The only other configurations different to the default were to turn off the default system password passdb and userdb, and enable my local password-file-format passdb and userdb.) I have configured two IMAP accounts in Thunderbird 3.1.9, one to access each of the two users above. The test procedure is: In Thunderbird, create a folder at the top level (i.e. alongside Inbox), say foo. In Thunderbird, delete the folder just created. This results in Thunderbird moving the folder to Trash, resulting in a folder Trash/foo. Up to this point, both the Maildir and mdbox users behave OK. Then in Thunderbird, delete the trashed folder Trash/foo. At this point, things start to happen differently. With the Maildir user, the folder Trash/foo deletes successfully. But with the mdbox user, Thunderbird pops up an error: The current command did not succeed. The mail server for account accountname responded: Invalid mailbox name: Trash/foo/. The folder does disappear from the Thunderbird folder pane, but if Thunderbird is prodded to refresh what folders it thinks are there, then the folder reappears. If we check the user's mdbox directory, we can see that indeed the mailbox has not been deleted. Whatever I then do, I am unable to delete this folder in the mdbox user through Thunderbird. The only way I have found to safely delete the folder is to use doveadm mailbox delete, but this requires root privilege on the server, which is not really a practical solution. It maybe a Thunderbird problem, but the question then arises: Why does it work under Maildir but doesn't work under mdbox? Any ideas? Bill
Re: [Dovecot] Thunderbird 3.1 unable to delete subfolder of Trash under mdbox
On 08/04/2011 16:09, Timo Sirainen wrote: On Fri, 2011-04-08 at 16:03 +0100, William Blunn wrote: But with the mdbox user, Thunderbird pops up an error: The current command did not succeed. The mail server for account accountname responded: Invalid mailbox name: Trash/foo/. See if imap_client_workarounds=tb-extra-mailbox-sep solves this. It does. Thank-you for responding so rapidly. I have pinged https://bugzilla.mozilla.org/show_bug.cgi?id=301714 Bill
Re: [Dovecot] dsync inbox conversion problem (mbox - mdbox)
On 22/03/2011 09:09, Sergiy Kyrylkov wrote: We are trying to convert all mbox mail on our systems to mdbox using dsync, in order to be able to use email sub-folders in Thunderbird. You should not be using 2.0 beta6. You should be using 2.0.11 or later. You can have folders containing both messages and folders under mbox. See http://wiki2.dovecot.org/MboxChildFolders. But I say again, you should not be using 2.0 beta6. You should be using 2.0.11 or later. Everything works fine for non-inbox folders, however the inbox folders are not getting converted. We used: *dsync -v convert mbox:~/mail:INBOX=/var/mail/%u* *dovecot --version* 2.0.beta6 (3156315704ef) (shipping with RHEL6/SL6) Early 2.0.x supposedly stable versions had many many problems which means you should under no circumstances attempt to use them, LET ALONE 2.0 beta versions. You really should upgrade to 2.0.latest (currently 2.0.11). I will have zero sympathy for whining along the lines of: - Well that's what's in my distro - My employer only allows bona fide distro packages Did I mention you should be using 2.0.11 or later? I can't remember. Anyway, you should be using 2.0.11 or later. Bill
[Dovecot] http://wiki2.dovecot.org/MailServerOverview contains poppycock
Just having another look at http://wiki2.dovecot.org/MailServerOverview , it seems to have some statements in it which are misleading, and some which are really ... well ... wrong. Quote: With the possible, optional, exception of the deliver MDA, Dovecot is not involved with reception, delivery, and storage of mail. That function is provided by a MTA such as postfix http://www.postfix.org. It is the MTA that determines where and how mail is stored - Dovecot must then be configured to retrieve the mail accordingly. (Entered by user amfes.) This contains a significant proportion of poppycock. Dovecot includes extensive functionality for the storage (as in the action of storing) of e-mail as well as retrieval, in the shape of the LDA. Using Dovecot's LDA is /required/ in the case of Dovecot-specific mail storage formats (sdbox, mdbox). With mbox, use of the Dovecot LDA is advisable since it will guarantee a locking strategy which is compatible with Dovecot's mail retrieval functionality. And in any case, use of the Dovecot LDA has merit in that it should guarantee line-up between the mailstore configurations used for storage and retrieval. It is NOT the MTA that determines where and how mail is stored. It is the PERSON who configures the system who decides this, and codifies that configuration into whatever systems carry out local delivery and retrieval. It IS true that use of Dovecot's LDA is optional, but to say that it is a possible exception is misleading. People /should/ use the Dovecot LDA if they are using Dovecot IMAP/POP, and the /option/ is to use the MTA's local delivery system /if/ it is so indicated on a particular system. Quote: Again, it bears repeating, Dovecot /is not responsible for mail delivery or storage/. Any questions on these issues involve your MTA and MDA. Get those working first. (Entered by user DanielMiller.) Again, contains quite a lot of misleading nonsense. Mail delivery includes the hand-off of the message by the MTA to the LDA, and the storage of the message by the LDA. The LDA should probably be Dovecot, so really Dovecot /is/ partially responsible for mail delivery. Storage involves that placing of message into the message store. This should be done by Dovecot, so Dovecot is responsible for this. Bill
Re: [Dovecot] http://wiki2.dovecot.org/MailServerOverview contains poppycock
On 22/03/2011 13:00, Charles Marcus wrote: Instead of complaining, why not just fix it (it is a wiki after all) and *then* post your email explaining the changes you made? For changes for the better to come to fruition, a number of things need to happen, only one of which is actually making the changes. So initially I was identifying problems, and possible solutions. I posted a message in case there would be anything to be gained from a discussion on the subject. After reflection, I decided it might be as well to come up with some new words which should be right enough that they would be an improvement on the existing text even if they needed further work later. So I made changes to the wiki. http://wiki2.dovecot.org/MailServerOverview After making changes in the wiki, I saw your message. Bill
Re: [Dovecot] IMAP Clients can not see 3rd tier nested IMAP directories
On 07/12/2010 15:37, jj...@cornell.edu wrote: I have a very bizarre problem that I hope someone can help me with. I am not sure if this is a Dovecot problem, or IMAP client problem. I recently used Transend's Migrator to move mail from Exchange 2007 to my Dovecot 1.0.7 server. The program seems to have moved the nested IMAP dirs properly as seen below in a directory listing of the maildir dir. The nested dirs have indexes, cur, new dirs as expected. However, when the account is viewed in Windows Thunderbird 3.1.6 or Outlook 2010 the 3rd tier dirs are not seen, nor can they be subscribed to. On a whim, I decided to try Apple Mail 4.3 to view the account and all the IMAP dirs can be seen and accessed as expected. Any idea what is going on? Is this somehow an IMAP client problem (bug) or an issue with Dovecot and these clients? There is a bug in Thunderbird which causes in this behaviour http://www.dovecot.org/list/dovecot/2010-September/052620.html Bill
Re: [Dovecot] dovecot Digest, Vol 91, Issue 18
On 08/11/2010 12:47, Alan Brown wrote: From: Timo Sirainen t...@iki.fi Subject: Re: [Dovecot] emails getting mangled when dragging from Exchange account to IMAP shared folders On Wed, 2010-11-03 at 16:18 -0700, Scott Goodwin wrote: FYI, I got rawlog working and it shows the same break in the raw logs as in the broken headers. Below is a snippet from the rawlog (names and other identifiers redacted). The offending sequence is always in the References headers section, and you can see the line breaks there that show this. So it sounds like this can't be an issue with Dovecot, am I right? Yeah, sounds like Outlook breaks with huge headers. That's one huge References header you have. Summarising mail standards (WRT headers) There is a limit of 4096 characters per line. But surely you can fold header records, e.g. References: f...@bar.com f...@bar.com f...@bar.com meaning you could have a References header record of any length. If Outlook is breaking at less than that it's a bug. I take it you mean breaking as in malfunctioning as opposed to breaking as in folding. If the References: line is longer than that then it should have been truncated by the sending MUA - there's no provision for multiline References headers (which are a non-standardised import from Usenet anyway). Surely the MUA could just fold the References header record on to multiple lines? When you say multiline References headers, do you mean multiple 'References' header records or 'References' header records folded on to multiple lines? Bill
Re: [Dovecot] dovecot Digest, Vol 91, Issue 18
On 08/11/2010 13:16, William Blunn wrote: But surely you can fold header records, e.g. References: f...@bar.com f...@bar.com f...@bar.com For the avoidance of doubt, the second and third lines of that header record are supposed to have an additional space character at the beginning. I did type the required space characters, but obviously the creators of the e-mail client software I use don't think it's important to pass such things through without breaking them. (Whilst I am responsible for choosing that particular e-mail client software, I would venture to suggest that it is hard to find an e-mail client software which is any good.) Bill
Re: [Dovecot] Can you POP a specific folder in Dovecot?
On 28/10/2010 11:26, Peter Reinhold wrote: In my old setup, a user could have folders on the server, and by using his login with the mailbox appended, could pop a given folder specifically. For instance, logging in with u...@example.com would pop INBOX, and logging in with user-fol...@example.com would pop just that specific folder. Is it possible to do something like this in Dovecot, or is the only possible way of popping folders by using the virtual plugin? Though this is of course Paradigm error or Trying to ice-skate up hill. If you want to access folders, then use IMAP. Historically IMAP has difficult, slow, unreliable and generally gnarly. But nowadays Dovecot makes IMAP work well. Of course you have to pick the right client. I've never had good experiences with MS-Outlook over IMAP, but then I haven't even bothered with it for several years. My current favourite is Thunderbird 3. Bill
Re: [Dovecot] Can you POP a specific folder in Dovecot?
On 28/10/2010 16:04, Peter Reinhold wrote: Someone wrote (Probably you), and the time was 14:23 28-10-2010 Though this is of course Paradigm error or Trying to ice-skate up hill. If you want to access folders, then use IMAP. This might be, but I like to be able to access my mail via webmail during the day, and then pop it to my local computer when I get home. Even easier then. Just reconfigure your home computer for IMAP. Then the webmail and the home computer will both see the same folderised mail store. Being on a couple of medium to high traffic mailinglists, and you quickly loose overview when in the webmail, and thats when its nice to be able to file the mails into folders. OK. File it into folders on the IMAP. IMAP supports server-side filing --- the message does not have to be downloaded to the client and re-uploaded; the client just tells the IMAP server to re-file it. (Yes yes yes pedants, I know, IMAP doesn't support MOVE in the core, and by default it's copy-then-delete. The point is there is no download-upload cycle --- in any case under Dovecot, under Maildir, sdbox or mdbox, copies are all done by some form of reference-copying and therefore cheap.) While you're at it, you might as well set up rules on the server to file it for you. Then when you file stuff at home (or the server-side rules file it for you), it will all appear magically filed on the webmail. While you may not agree on the practice, it has worked pretty well for me the past many years, and i'd like to continue doing so, even on a new mailserver (and Dovecot has many nice features that my old one didn't) Weird because you seem to have a perfectly good folderised mail store on the server, then go and break the paradigm by moving everything down on to a single client machine. Bill
Re: [Dovecot] fallocate and glibc 2.10
On 24/10/2010 15:10, Timo Sirainen wrote: A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem. I thought you were fixing bugs coming out of running Dovecot over BSDI in order to make Dovecot *generally* more robust. (Well that was the only explanation I could think of for adding support for a dead OS...) I would imaging Ubuntu 9.10 and Fedora 11 to be, much less dead than BSDI. You may find that hosting providers only have support for certain spot versions of distros, and besides people may have reasons to stick with the distro they are on. So it may be worth just doing it, especially if the reporter has supplied a patch! Bill
Re: [Dovecot] minimize mbox mdbox fragmentation
On 20/10/2010 18:32, Charles Marcus wrote: On 2010-10-20 12:53 PM, Timo Sirainen wrote: Oh, interesting. I didn't know that was possible. And even better: Linux has fallocate() that can do it for other filesystems than just XFS. Or looks like it's only XFS and ext4 (ext3 doesn't support it). How about reiserfs (3, not 4)? Though in the case of the small number of large files (i.e. the opposite of ReiserFS's strength), which you would get with mbox and mdbox, one would have to ask what upside ReiserFS would bring to the party which would outweigh the downside that Namesys is kaput and Hans Reiser is currently serving 15 years to life for second degree murder in a California State Prison... Bill
Re: [Dovecot] minimize mbox mdbox fragmentation
On 21/10/2010 14:25, Charles Marcus wrote: Reiserfs is not 'kaput', it is still being maintained in the linux kernel (both v3 and work is ongoing for v4), and will be for the foreseeable future. For the benefit of anyone reading this and wondering Well is it kaput or not?: Charles and I are both right. I said that *Namesys* was kaput. Namesys was the company which developed ReiserFS. Charles stated correctly (but perhaps confusingly when done as a reply to my comment) that *ReiserFS* is not kaput. We were talking about two different things. The company is dead, but the software (being open source) lives on. Bill
Re: [Dovecot] Limit access to dovecot by domains?
On 13/10/2010 08:08, Jobst Schmalenbach wrote:
Is there any way to limit access to dovecot by domains.
I only need to give access to a well known set of domains, all from
Australia and all networks are known and used either from people at
home or mobile access (phones, laptops etc).
Have you considered using fail2ban ?
This should then block calling IP addresses based on the suspiciousness
of the activity originating from those addresses.
Also it should mean you wouldn't need to keep housekeeping the list of
allowed networks. So people using networks you hadn't thought of, or
people travelling abroad, would still be able to get access without
having to bother you.
In addition it should cover the case of black hats operating out of (or
bouncing activity through) your semi-trusted list
{optusnet,bigpond,tpg}.com.au.
Bill
Re: [Dovecot] managesieve fileinto folder with international characters
On 13/10/2010 19:04, Edward Carraro wrote: main_script: line 1: error: folder name specified for fileinto command is not utf-8: ññoéé. Which versions of things are you using? There is a thread on a similar topic here http://www.dovecot.org/list/dovecot/2010-August/051780.html with a repository commit by Timo mentioned here http://www.dovecot.org/list/dovecot/2010-August/051927.html Bill
Re: [Dovecot] Outlook problem when deleting mails
On 12/10/2010 17:48, Ulf Jaenicke-Rößler wrote: I'm seeking advice to solve the following mystery: I set up an IMAP server on Ubuntu 10.04 (dovecot 1.2.9). It appears to work fine apart from one problem. A colleague is running Outlook 2007 I would suggesting considering the use of an IMAP client which isn't quite so hideously broken. Whilst I am not aware of any even half decent free e-mail software, Thunderbird 3.0 is, to my mind, at least a quarter decent. Bill
Re: [Dovecot] login_* options for 1.0.15
On 08/10/2010 15:02, Hugo Monteiro wrote: Although i'm aware that version 1.0.15 is rather old, that's what is used in Lenny, so... 1.0.15 is ancient. Please consider upgrading to at least 1.2.x. There is a package for 1.2.13 available in Lenny backports http://packages.debian.org/lenny-backports/dovecot-common replete with binaries for 9 architectures. Bill
Re: [Dovecot] Per User Quotas with LDAP on Dovecot 1.x
On 07/10/2010 20:38, Camron W. Fox wrote: If we upgrade, then we lose RH support for any future dovecot issues And if you don't upgrade, you don't get any support from the guy who wrote Dovecot and therefore knows it inside-out :-) I tend to suggest the practice of: Keep your server on distro for the most part, but don't be shy of putting a carefully-chosen handful of packages off distro where you get a useful win. (not that they're being particularly helpful with this issue). Keep on with that line of thinking :-) Bill
Re: [Dovecot] migration 1.2.5 - 2.0.5 load increased dramatically
On 06/10/2010 13:16, Ralf Hildebrandt wrote: * Ralf Hildebrandtralf.hildebra...@charite.de: During norml operation this morning we're seeing a significantly increased load on the IMAP server (factor 5, from 5 to 25). Does dovecot need to rebuild index files or perform other IO intensive operations after the upgrade? We're using Maildir Our monitoring shows increased system time. We're runnign fewer processes, the IO rate ist identical to yesterday, memory usage is identical. I found the reason: My excessive number of ca-certificates! dovecot-lda invoke doveconf, which in turn needs a whooping 1.2s wallclock time to parse the config! I pruned the ca-certificates file and removed ALL ca-certificates but the ones that belong to the certificate chain for postamt.charite.de Hello Ralf, Glad to see you found out what the problem was. I was just wondering if this episode suggested any changes which may be helpful. I am not an expert on the issue you discovered, so I came up with some questions which might help guide us. Do you feel that the problem was more that you were feeding Dovecot an unusually large certificate pack, or that your certificate pack was reasonable and Dovecot should be able to cope better with packs of this size? Should we write something in the Dovecot wiki about it? Should we need to suggest an enhancement to Dovecot? Regards, Bill
Re: [Dovecot] Shared folder again !
On 06/10/2010 14:44, Johan Hendriks wrote: First of all, i have virtual users, with virtual domains. Mail is stored in /usr/local/virtual/domain name/user The following does not have anything to do with the main thrust of your question, but: Storage of e-mail does not fit into the purposes normally associated with '/usr'. All other things being equal, you might want to consider trying to arrange it so that mail is stored somewhere under '/var' or '/home'. That is not to say storing mail under '/usr' won't work; it is just that it is unusual, and by doing this you are setting yourself (or the person who comes after you) up for potential confusion and/or problems later on. a.k.a. Try not to blow against the wind unless you have something worthwhile to gain from it. Regards, Bill
Re: [Dovecot] how to upgrade (update) the dovecot
On 05/10/2010 09:56, arif khwaja wrote: Is there any easy way to upgrade Dovecot like yum command? Or I have to delete the current and install the new version then change the setting? I will appreciate if you can tell me the steps please? ... --- On Fri, 1/10/10, dovecot-requ...@dovecot.orgdovecot-requ...@dovecot.org wrote: [ 15 kilobytes(!) of message digest ] Chaps, Your messages are containing the full 15 kilobytes of digest quoted. There may well be some relevant material in there, but if you don't edit it down you are going to run the risk of upsetting some people on the list. This is not an e-mail thread bouncing around between PHBs; this is the Dovecot mailing list. Can we please edit down our quoted sections to what is relevant!? Thank-you. Regards, Bill
Re: [Dovecot] how to upgrade dovecot
On 01/10/2010 13:32, arif khwaja wrote: I have Centos 5 and devecot 1.0.7 I want to upgrade it to the latest version. I will appreciate if any one can tell me how can I upgrade it please. There are some wiki pages about upgrading here: http://wiki2.dovecot.org/Upgrading There appears to be some binary RPMs of Dovecot 2.0.4 for RHEL5 (which should be compatible with CentOS 5) here: http://packages.atrpms.net/dist/el5/dovecot/ (You can also get to the above page by starting at http://wiki2.dovecot.org/PrebuiltBinaries#RPMs_of_newer_Dovecot_and_Sieve_packages ) Though I can't personally vouch for whether any of the above will work. Bill
Re: [Dovecot] Can't receive emails
On 05/10/2010 15:52, Chris wrote: I searched every logfile I could find, but without any results :( How does it usually work? The mail is send by another server and on my server, does postfix receive the email or is it dovecots job? Who puts the mail into that mail directory? I guess it's postfix? If you are administering an e-mail server, this is stuff you are supposed to know. If it is a large enough installation to warrant /domain/localpart/ naming and MySQL user database, then you really should be fully up to speed on this stuff. In general, your MTA (Postfix in your case) usually receives e-mail by SMTP usually via TCP on port 25. Depending on your MTA configuration it may deliver the mail directly to a file itself, or it may send it to another program by means of a socket, or by piping the message into another program invoked on a per-message basis. To progress your issue further, you probably need to work out how you have Postfix configured. Bill
Re: [Dovecot] v2.0.5 released
On 04/10/2010 14:27, Attila Nagy wrote: It seems there is an FD leak in this version. The number of open file descriptors quickly raise after upgrading from 2.0.4. (I haven't got more time to look after the issue, it may be obvious from the diffs) You may be probably ten steps ahead of me but I had a thought here which was to try using the lsof program to find out what object was associated with the leaked FDs, which might help finding where they are leaking from. Bill
Re: [Dovecot] Dovecot v0.99.13-3 upgrade to 1.0.15-2 ??
On 30/09/2010 22:17, cajun wrote: I've read some of the mailing lists looking for information on this. Thus far, about all I've found is there was a complete rewrite of Dovecot some time back. I'm wondering now is it even possible to use the same mbox's from 0.99.13-3 with version 1.0.15-2? Is there a procedure documented somewhere? Any pointers would be much appreciated. If you have picked up the issue of upgrading Dovecot, I would * suggest that you consider going up to version 2.0.4, and * recommend going for at least version 1.2.x. Many consider Dovecot versions older than 1.2.x to be somewhat ancient and as such you may find it difficult to get any help (or at least any help which doesn't begin with First upgrade to version 1.2.x or better) when using version 1.1.x or older. Bill
Re: [Dovecot] (Single instance) attachment storage with single-dbox
On 24/09/2010 19:57, Timo Sirainen wrote: Just a note to myself and whoever else cares, should be added to wiki once it has its own page about this: I have been meaning to say we should have a wiki page about this. With single-dbox messages can be copied with hard linking. This means that there can be multiple files that point to the same attachment file. The attachment is now deleted only once the mail file's link count drops to zero, so this works fine.. ..until someone goes and starts manually copying files or maybe restoring from backups or whatever, causing the hard links to be replaced with separate files having link count=1, even when there are other files pointing to the same attachment file. Now deleting this one mail will delete the attachment too early. I can't think of any other reasonable way to handle this though, so unless someon has some great ideas, I think the solution is to simply add enough warnings that message store shouldn't be accessed directly. Maybe add some import/export commands to doveadm which can be used to add a bunch of mails to storage without doing it directly on filesystem. Conceptually there is an attachment table with a primary key, and a message table which has foreign keys referring into the attachment table. In database theory, you could set up a foreign key constraint, and then it would not be possible to remove attachments which were still referenced by messages. I'm not saying all this data should be under *SQL; just thinking aloud. Can we do something /like/ that but only using a filesystem? Perhaps each message could have its own hard links to the attachment file? That way a message's attachments would be kept in existence by the filesystem itself. When you store a message with attachments, you could store the message file: u.123 and have its attachments stored as hard links under names which appear adjacent to the message file's name when the directory listing is sorted. u.123.a.1 u.123.a.2 Because the attachment files are adjacently-named to the message file, people accessing the sdbox mailstore as a filesystem should realise that they must backup/restore the message file and its associated attachment files. Bill
Re: [Dovecot] Dovecot needs to be built with SSL support?
On 22/09/2010 05:35, ksri...@yahoo.com wrote: I intend to use Dovecot without SSL. Hence, I built it without SSL support. When I am trying start Dovecot, I am getting the following error message. I have set ssl=no in 10-ssl.conf. Can anyone please let me know if it is possible to build and run Dovecot without SSL support? If it is, how can I overcome the following error message? Thanks a lot. Srini Sep 21 11:18:11 master: Info: Dovecot v2.0.3 starting up (core dumps disabled) Sep 21 11:18:11 ssl-params: Fatal: Dovecot built without SSL support Sep 21 11:18:11 master: Error: service(ssl-params): command startup failed, throttling (Ooops, accidentally sent message to OP only and not to list.) http://www.dovecot.org/list/dovecot/2010-September/053074.html Bill
Re: [Dovecot] tags disappear in Thunderbird
On 21/09/2010 11:39, Stan Hoeppner wrote: Daniel Luttermann put forth on 9/21/2010 5:02 AM: I would also use maildir for all mailboxes instead of mbox for inbox... Do you have technical justification for this recommendation, or is this merely personal preference? If both exist on NFS storage in a Dovecot cluster environment I would tend to agree due to potential locking and caching issues. Regarding local storage I don't see how there would be much, if any, of an operational difference, performance or otherwise. I'm not calling BS here, but asking for solid technical reasoning behind the recommendation. Reduced complexity. One storage format is simpler, and really (think Occam's razor) should be the starting point for negotiations. If anyone has to come up with an argument it is why someone should use two storage formats instead of one. To some people that may sound specious, but I suspect that is probably just a manifestation of the underestimation of the cost of complexity. Bill
Re: [Dovecot] Dovecot with Virtual Domains
On 21/09/2010 16:14, Edmonds Namasenda wrote: I have copied the *example-config*s to /usr/local/etc/dovecot/ but literally every change I make as of v1.* is not valid. I wish to use protocals IMAP POP3 then authenticate with shadow and passwd for system users and mysql for the virtual users. There is a good amount of useful information in the Dovecot 2 wiki http://wiki2.dovecot.org/ Bill
[Dovecot] Documentation link from http://www.dovecot.org/
On the Dovecot home page http://www.dovecot.org/ we have a link Documentation which links to the Dovecot 1.x wiki ( http://wiki.dovecot.org/ ). There is a question mark in my mind as to whether that is a good idea considering as how the current stable version of Dovecot appears to be 2.0.x. In the Dovecot 1.x wiki, there is a pink stripe across the top of the page which says that the documentation is for Dovecot 1.x. It looks as though the intention was to make that prominent so as to guide visitors to the right documentation, and I think to a certain extent it may work. But I am wondering if perhaps the stripe could be too easily missed. People might start browsing around in the Dovecot 1.x wiki without it even occurring to them that there was a whole another wiki for 2.x. I have an idea: Perhaps the Documentation link on the home page could be re-worked to something like Documentation v2.x v1.x where v2.x and v1.x are links to the two wikis. This would make it obvious that there was different documentation available for v2.x and v1.x, and encourage visitors to choose the appropriate set. Bill
Re: [Dovecot] Documentation link from http://www.dovecot.org/
On 21/09/2010 19:17, Timo Sirainen wrote: Wonder if http://dovecot.org/index2.html looks ok. Interesting. Though for me, the version numbers are too small to be useful. I tried it through Firefox 3.6.8 and Microsoft's version 8 offering with the same result. Also I've been wondering about what to do with wiki.dovecot.org. It would be nice if it was the same as wiki2, except there are existing links that would break. But is that a real problem? Most links would still stay the same. Another possibility could be to just make wiki.dovecot.org redirect to wiki2.dovecot.org and wiki.dovecot.org/blah/ to wiki1.dovecot.org/blah/. Existing links would work and then wiki2 links would start showing up more and maybe some day in future it would be easy to do wiki3. But the problem with this is then that people who have a link to wiki.dovecot.org could be reading obsolete information. Ah OK. If I were to suggest anything meaningful, it would only be after much further pondering. Bill
Re: [Dovecot] kmail-error: can't upload folder (imap-account on dovecot-server)
On 20/09/2010 12:26, cool.chri...@web.de wrote: Everytime I try to create a folder under my imap-inbox, I get an error like can't upload folder..., but after this message I can see a new folder under my inbox-folder, but I can't use it ... With a thundermail-client I can create a subfolder without any erro and I can use it r (but only first level). My conf: # /etc/dovecot/dovecot.conf ... mail_location: mbox:~/mail Under the normal mbox storage layout, you cannot have mailboxes (folders) which contain both messages and child mailboxes (subfolders). The reason is explained in detail at the beginning of http://wiki2.dovecot.org/MboxChildFolders . So with your present set-up you won't be able to create a folder under INBOX. You can create folders at the top level, but you won't then be able to make subfolders in those. To be able to nest folders freely, you could: 1. Switch your mail storage to one of the other formats: Maildir (Dovecot 1.0 onwards), single-dbox (Dovecot 1.2 onwards), multi-dbox (Dovecot 2.0 onwards). 2. Use a specialist scheme (Dovecot 2.0 onwards) to allow free nesting under mbox - see http://wiki2.dovecot.org/MboxChildFolders Also worth noting that the current stable version of Dovecot is 2.0.x. To be able to get best help on the mailing list, I would say try to use at least version 1.2.x of Dovecot. Bill
Re: [Dovecot] moving 1.2.13 system to another hard drive
On 18/09/2010 01:15, Paul Scott wrote: I have just set up a new system on a new hard drive on the same computer. fetchmail is correctly putting mail in /var/mail/username. Whilst I am no expert on fetchmail, as far as I know fetchmail does not deliver mail itself but rather passes it on to an MTA. So I think it may be your MTA that is delivering mail to mbox files in /var/mail. I have copied my entire Maildir directory from the old hard drive. I have made what changes I understood to dovecot.conf. Dovecot was working on the other drive even though I'm not completely sure how I got it working before. How about looking at the old Dovecot configuration under /etc on the old drive? Having said that, having mail delivered to mbox files under /var/mail, but other folders under Maildir might not be the best configuration: * to get Dovecot to be able to handle that setup means having two different mailbox formats which means a namespace configuration, * your INBOX is going to an mbox under /var/mail, which is fraught with potential locking problems (unless this has somehow magically been taken care of for you). You may be better off getting all mail delivered straight to Maildir, thereby making everything Maildir. This would then make your Dovecot configuration simpler, and also remove the potential locking problems of using mbox. Any ideas for debugging this certainly simple problem for some of you. Please try to describe a specific symptom or specific symptoms you are experiencing. Please provide the output of dovecot -n. It might also be an idea to say what MTA you are using. For The Avoidance Of Doubt, I am not 'taking on your case', but merely providing one step of suggestions. Please reply to the list (i.e. not to me). Bill
Re: [Dovecot] Moving from MBOX to Maildir or DBox ?
On 16/09/2010 16:47, Frank Bonnet wrote: Actually we use MBOX format for all our IMAP access but users complain they cannot create subfolders in imap folders, of course they cannot because of MBOX format ... Actually you can, under mbox, do mailboxes which contain both messages and sub-mailboxes. Two approaches are outlined at http://wiki2.dovecot.org/MboxChildFolders Though applying to an existing site either of the two approaches outlined would require some reorganisation. That reorganisation may be sufficient trouble that it may be as well to switch to one of the other formats. dbox is not a format; it is a family of two formats: single-dbox and multi-dbox. See http://wiki2.dovecot.org/MailboxFormat Bill
Re: [Dovecot] Migrating mail from mbox to maildir using dovecot
On 14/09/2010 16:51, Donny Brooks wrote: I think I will have to stay with the 1.x branch since we have to stick to using approved rpm's (internal policy) and fedora 13 does not have a 2.x branch that I see yet. I agree sticking to the standard binary packages where possible is generally a good idea. But having a carefully chosen handful of packages built from source, where it offers a significant benefit, could be overall better than sticking slavishly to an overly-simplistic rule. If your organisation is only 160 people there can not be that many people (2 or 3?) involved in making that policy. You should be able to get them all in a meeting and sort it out. Rules are not usually written in stone. Rules may not be /wrong/ per se, rather they may benefit from some /refinement/. So maildir it is for now. I see my error on the inbox not getting the new mail. That was one of those all nighter errors that I just plain missed due to lack of sleep. I forgot to point postfix to the proper place to deliver the mail. So once I setup postfix to deliver the mail properly and the dovecot convert plugin is setup, is there a way to gradually migrate the users so I don't kill the server? We have about 220GB or so of mail between about 160+/- users. What would be the best way to migrate it all to maildir? Have mail location configured on a per-user basis via the userdb. You can then pull individual users mail over to Maildir and update their mail location configurations. Bill
Re: [Dovecot] Migrating mail from mbox to maildir using dovecot
On 11/09/2010 20:17, Donny Brooks wrote: On the old mail server it is: dovecot-1.2.11-3.fc11.x86_64 On the new mail server we are migrating to it is: dovecot-1.2.14-1.fc13.x86_64 currently Is there a repo out there that I can install 2.0 from? The only one I have found is atrpms and it is a pain to get conflict worked out with other packages. If you use Dovecot 2.0 you also get the choice of multi-dbox. http://wiki2.dovecot.org/MailboxFormat/dbox This would give you some advantages: * With multi-dbox, multiple messages are stored in the same file. But once a mail file contains 2 megabytes (configurable), Dovecot moves on to a new file and leaves the old files unchanging. This should be quite nice for your backup strategy because you would only backup the current file for each user, limited to 2 megabytes per user (or whatever amount you think appropriate). * With multi-dbox, if you have many small messages, these are all stored in the same file. This vastly reduces the number of files required to store mail, which means fewer inodes consumed, and I think backup systems often work better with a smaller number of larger files than a larger number of smaller files. If you use multi-dbox, you will need to use a Dovecot delivery software (e.g. dovecot-lda). Bill
Re: [Dovecot] nfs director
On 10/09/2010 07:50, Edward avanti wrote: On Fri, Sep 3, 2010 at 7:26 PM, Timo Sirainent...@iki.fi wrote: On 3.9.2010, at 7.00, Noel Butler wrote: I do take exception to be told this issue can be fixed, but NFS users are not worth it, which is essentially what he told us, I dare say if this list was flooded by dovecot NFS users asking he'd quickly change his mind, but as everyone here knows, there is only a few hundred I never said I don't care about NFS users or think there aren't enough of them. I guess I could have been a bit clearer: I don't consider the number of users who want to use Dovecot LDA without indexes to be worth the trouble to add extra complexity to maildir code. Why to Maildir code, is not easier to not call that part of code by command line -switch to deliver simple method and would this no be beneficial to all NFS user, not just the one who ask you. Writing messages to Maildir(++) (without indexes) is so straightforward that systems tend to have support for that built-in. Exim, Postfix, and Procmail have support for delivery to Maildir built-in. If you just want a program which does simple deliveries to Maildir then you can use Procmail. Bill
Re: [Dovecot] Question on Mail Formats
On 09/09/2010 14:49, Giovanni Giorgi wrote: I am still tuning my dovecot, but I find myself very confortable with it. I am going to structure my imap folder with a new namespace (somthing you cannot do with GMail :) and I can choose the mailbox format. What is the difference between the two mailbox format mbox and maildir? I know mbox is older, but there is a good reason to use maildir instead? I can get for instance some performance improvement? Better archiving? mbox stores all the messages for one mailbox (mail folder) in one file. Maildir stores each message in a separate file. - With mbox you need to be careful that everything which manipulates mbox files uses compatible locking methods, otherwise you risk scrambling your mail files. With Maildir this problem does not arise. - With mbox, deleting messages from the beginning of the mailbox is comparitively expensive. With Maildir, deleting messages is always cheap. - With mbox, reading a portion (e.g. header) from every message in a mailbox (mail folder) only requires opening one file. With Maildir, reading a portion (e.g. header) from every message in a mailbox (mail folder) requires opening many files. - If you are picking this issue up and looking at it, you may want to consider Dovecot's own native formats single-dbox and multi-dbox as well. See http://wiki2.dovecot.org/MailboxFormat Note that multi-dbox requires Dovecot 2. Then again if you aren't already using Dovecot 2, you might want to consider upgrading. Bill
Re: [Dovecot] Sub-Sub-Subfolders not shown after converting from maildir to mdbox
On 08/09/2010 21:17, Patrick Westenberg wrote: it seems to be a bug in Thunderbird and SeaMonkey: https://bugzilla.mozilla.org/show_bug.cgi?id=592633 Now confirmed. David Bienvenu replicated the problem with Thunderbird (involving connecting to my server running Dovecot 2.0.1), analysed it and found a problem with Thunderbird. They are now scratching their heads over how to fix it :-) So I think Dovecot is working correctly here. To tide people over until the bug is fixed, a couple of workarounds have surfaced: 1. You can configure Thunderbird to show all folders rather than just subcribed ones. In Server Settings / Advanced, untick the box Show only subscribed folders. This then exposes the third-level folders. 2. Make the folder(s) in question be listed in the server's subscribed folders list by some other means. For example using another e-mail client, or just adding the folder name(s) to the subscriptions file on the server. Bill
[Dovecot] What's %%h ?
What's %%h ? http://wiki2.dovecot.org/Variables says that %% expands to %, so according to that, %%h expands to %h. But I have seen people using %%h, so it must mean something else. Bill
Re: [Dovecot] What's %%h ?
On 08/09/2010 14:41, Timo Sirainen wrote: On Wed, 2010-09-08 at 09:22 +0100, William Blunn wrote: What's %%h ? http://wiki2.dovecot.org/Variables says that %% expands to %, so according to that, %%h expands to %h. It does. But I have seen people using %%h, so it must mean something else. With shared mailbox location and prefix the expansion is done twice. Ah OK thanks. It seems we have some documentation for this at http://wiki2.dovecot.org/SharedMailboxes/Shared I have updated http://wiki2.dovecot.org/Variables so that there is a link to [[SharedMailboxes/Shared]] from the bit about %%. Bill
Re: [Dovecot] Sub-Sub-Subfolders not shown after converting from maildir to mdbox
On 06/09/2010 23:54, Patrick Westenberg wrote: I just recognized a problem concerning subfolders after converting from maildir to mdbox. Thunderbird and SeaMonkey don´t show folders that are subfolders of subfolders. Using Thunderbird or Seamonkey, Folder1 and Folder2 are listed and can be subscribed to but Folder3 never gets listed. If I create Folder4 as a new subfolder from Folder2 it works, so the problem only exists with existing folders from converted maildirs. I can replicate this problem using Thunderbird 3.0.6 over Dovecot 2.0.1 using mdbox. If a third level folder (e.g. foo/bar/baz) appears on the server (i.e. not at the bidding of Thunderbird), then Thunderbird 3.0.6 will not notice it, even if you bring up the Subscribe dialog and click refresh. But if you create a third level folder through Thunderbird, then Thunderbird will see it. If the third level folder appears on the server, you can pursuade Thunderbird to see it by manually adding the folder name to the subscriptions file on the server and re-starting Thunderbird. But manual IMAP looks to be right. m LIST * * LIST (\HasNoChildren) / Trash * LIST (\HasNoChildren) / INBOX * LIST (\HasChildren) / foo * LIST (\HasChildren) / foo/bar * LIST (\HasNoChildren) / foo/bar/baz m OK List completed. Bill
Re: [Dovecot] Sub-Sub-Subfolders not shown after converting from maildir to mdbox
On 06/09/2010 23:54, Patrick Westenberg wrote: I just recognized a problem concerning subfolders after converting from maildir to mdbox. Thunderbird and SeaMonkey don´t show folders that are subfolders of subfolders. Using Thunderbird or Seamonkey, Folder1 and Folder2 are listed and can be subscribed to but Folder3 never gets listed. If I create Folder4 as a new subfolder from Folder2 it works, so the problem only exists with existing folders from converted maildirs. I've just run a test with a virgin Maildir setup on Dovecot 2.0.1. After raising three levels of folder on the server side (foo, foo.bar, and foo.bar.baz), Thunderbird 3.0.6 was only able to see into the first two levels. Listing folders through a manual IMAP looks OK. I also ran a test on a virgin mdbox setup with a Namespace to force the separator into a dot, to make it behave similarly to Maildir at the IMAP level). Same results; Thunderbird 3.0.6 can only see into the first two folder levels. Listing folders through a manual IMAP looks OK. So I don't think the problem is mdbox. I suspect there is a bug in Thunderbird 3.0.6 wherein it cannot subscribe to folders more than two levels deep. I think you didn't notice the problem before because all folders were already subscribed. I was able to come up with a sort-of workaround which is to manually add the folder name to the subscriptions file on the server side. Thunderbird is then able to see the folder (may need to restart Thunderbird). Maybe you could drag the subscriptions data over from the old Maildir folders over into the mdbox folders? If you took the default separators (dot under Maildir and slash under mdbox) then you'd need to change those in the subscriptions files (sed -e 's:\.:/:g' Maildir/subscriptions mdbox/subscriptionsperhaps) or set up a Namespace to force the new mdbox config to use a dot as the separator. Bill
[Dovecot] Bad HTML at http://wiki2.dovecot.org/
Bad HTML at http://wiki2.dovecot.org/ div style=padding: 0.2em; background-color: #50bead This documentation is forstrongDovecot v2.0/strong, seea href=http://wiki1.dovecot.org/ view-source:http://wiki1.dovecot.org/wiki1/a for v1.x documentation./a /div After documentation. there is a closing/a tag with no corresponding opening tag. A similar issue appears on http://wiki.dovecot.org/ Bill
Re: [Dovecot] mdbox: Cannot create subfolder called dbox-Mails (2.0beta5)
On 04/09/2010 16:37, Timo Sirainen wrote: On 4.9.2010, at 11.40, William Blunn wrote: OK, but then it occurred to me, if we can use DIRNAME with Maildir, how about LAYOUT with dbox? How about having the ability to specify Maildir++ folder layout under dbox? For example: You can. I've documented this at http://wiki2.dovecot.org/MailLocation/dbox#Directory_layout Bill
Re: [Dovecot] Documentation for altpath / altmove / ?Alternate storage
On 03/09/2010 11:13, William Blunn wrote: I was thinking about documentation for alternate storage. I have added a new section http://wiki2.dovecot.org/MailboxFormat/dbox#Alternate_storage and made various changes elsewhere http://wiki2.dovecot.org/MailLocation/dbox#Alternate_storage http://wiki2.dovecot.org/MailLocation#Format which should make it a bit easier to discover Alternate storage and have a go with it. Bill
Re: [Dovecot] mdbox: Cannot create subfolder called dbox-Mails (2.0beta5)
On 04/09/2010 16:37, Timo Sirainen wrote: On 4.9.2010, at 11.40, William Blunn wrote: OK, but then it occurred to me, if we can use DIRNAME with Maildir, how about LAYOUT with dbox? How about having the ability to specify Maildir++ folder layout under dbox? For example: You can. I tried :LAYOUT=maildir++ to work with dbox but it didn't work for me. I have configurations: lda_mailbox_autocreate = yes mail_location = mdbox:~/mdbox:LAYOUT=maildir++ If I try to deliver a message to a folder 'foo' using dovecot-lda ( echo 'Subject: test' ; echo ; echo 'test' ) | /usr/lib/dovecot/dovecot-lda -m foo I get an error in the logs: Sep 6 14:41:08 pod dovecot: lda(bill): Error: user bill: Initialization failed: Initializing mail storage from mail_location setting failed: Mailbox list driver maildir++: maildir_name not supported by this driver Sep 6 14:41:08 pod dovecot: lda(bill): Fatal: Invalid user settings. Refer to server log for more information. I am using 2.0.1 auto 28 downloaded from xi.rename-it.nl today. Bill
Re: [Dovecot] LAYOUT=maildir++ under mbox?
On 06/09/2010 15:07, Timo Sirainen wrote: On Mon, 2010-09-06 at 12:37 +0100, William Blunn wrote: Whilst documenting LAYOUT=maildir++ under dbox, that got me thinking: Can we specify :LAYOUT=maildir++ with mbox? Yes, ever since LAYOUT was added. If I have it right, this should then remove the problem of not being able to have messages and mail subfolders in the same mail folder. Yes. Also it might be possible to use DIRNAME with LAYOUT=fs to solve that problem, but I'm less sure about that. I anyway doubt most mbox users want to switch to a whole new layout. OK. Tried that. The results are interesting. If you use: mail_location = mbox:~/mail:DIRNAME=mail then INBOX mail gets put into a file at ~/mail/inbox with indexes at ~/mail/INBOX/mail/dovecot.* folder mail gets put into an mbox file at ~/mail/folder/mail. We don't get any indexes, presumably because Dovecot is trying to put the indexes at ~/mail/folder/mail/dovecot.* which of course can't work because there is already a file where it wants to put a directory. However we can also put mail into folder folder/subfolder, which goes into an mbox file ~/mail/folder/subfolder/mail. So we are now magically able to put both messages and subfolders into folders. Cool. But we don't have indexes. But we can fix the indexes by adding an INDEX parameter. mail_location = mbox:~/mail:DIRNAME=mail:INDEX=~/mail/.index This then seems to make everything work with indexes at: INBOX : ~/mail/.index/INBOX/dovecot.* folder : ~/mail/.index/folder/dovecot.* folder/subfolder : ~/mail/.index/folder/subfolder/dovecot.* So possibly an answer for people who want to use mbox format but also want to be able to put both messages and subfolders into folders. I may pop this into http://wiki2.dovecot.org/MailLocation/mbox So for example if we had mail location specified as: mail_location = mbox:~/mail:LAYOUT=maildir++ we would have files: ~/mail/inbox - file storing messages in INBOX ~/mail/.foo - file storing messages in mail folder foo ~/mail/.foo.bar - file storing messages in mail folder foo/bar and I think all of Dovecot's indexes would go under ~/mail/.imap I think it'll give an error (by trying to write to ~/mail/.foo/.imap/dovecot.index) unless you also specify :INDEX=directory separately. This doesn't work so well. Using mail_location = mbox:~/mail:LAYOUT=maildir++ Mail for INBOX goes to an mbox file ~/mail/inbox. Mail for folder folder goes to an mbox file ~/mail/.folder. But mail for folder folder/subfolder gets stuffed into ~/mail/inbox. And also we get no indexes. We can fix the indexes using the INDEX parameter, but this doesn't help not being able to deliver to any folder more than one level deep. Bill
Re: [Dovecot] LAYOUT=maildir++ under mbox?
On 06/09/2010 16:41, Timo Sirainen wrote:
On Mon, 2010-09-06 at 16:36 +0100, William Blunn wrote:
mail_location = mbox:~/mail:LAYOUT=maildir++
Mail for INBOX goes to an mbox file ~/mail/inbox.
Mail for folder folder goes to an mbox file ~/mail/.folder.
But mail for folder folder/subfolder gets stuffed into
~/mail/inbox.
Did you have a namespace defined? If not, the separator is '.' and not '/',
maybe that's the problem? Or anyway I guess there was some error logged why it
didn't go to where you wanted. In my test it works fine.
OK, no I didn't have a namespace defined.
I have now tried it with a namespace with an explicit separator of '/'
and it now all works.
namespace {
type = private
separator = /
location = mbox:~/mail:LAYOUT=maildir++:INDEX=~/mail/.index
inbox = yes
hidden = no
list = yes
subscriptions = yes
}
Mail for INBOX goes to an mbox file at ~/mail/inbox with indexes at
~/mail/.index/.INBOX/dovecot.*
Mail for folder goes to an mbox file at ~/mail/.folder with indexes
at ~/mail/.index/.folder/dovecot.*
Mail for folder/subfolder goes to an mbox file at
~/mail/.folder.subfolder with indexes at
~/mail/.index/.folder.subfolder/dovecot.*
I think what confused me was that it seems that under Maildir the
default separator is '/', so folder/subfolder gets mapped to
.folder.subfolder.
But under mbox the default separator is '.' (even if LAYOUT=maildir++ is
specified!), so folder/subfolder doesn't get mapped to
.folder.subfolder (perhaps it ends up as .folder/subfolder?) so it
doesn't work.
I suppose in theory perhaps the default separator should be based on the
LAYOUT rather than the mailbox format, viz.
Under LAYOUT=fs perhaps the default_separator ought to be '.', and
under LAYOUT=maildir++ perhaps the default_separator ought to be '/',
regardless of the mailbox format :-)
Bill
Re: [Dovecot] LAYOUT=maildir++ under mbox?
On 06/09/2010 17:30, Timo Sirainen wrote: On Mon, 2010-09-06 at 16:57 +0100, William Blunn wrote: I think what confused me I think you're still confused :) I think you're right. Under LAYOUT=fs perhaps the default_separator ought to be '.', and under LAYOUT=maildir++ perhaps the default_separator ought to be '/', regardless of the mailbox format :-) It works like that, except the opposite way. With LAYOUT=fs the default separator is '/' because the hierarchies are separated by the '/' directory separator. With Maildir++ it's '.', because the separator in disk is '.'. So only the layout determines what hierarchy separator is in use. Of course, each mailbox format has their default layout. OK. So it does. I'd been running tests targetting the folder foo/bar, always with a slash separator. For some reason I had it that with maildir this was mapping down to .foo.bar/, but I just tested that again and it doesn't --- the mail just ends up in INBOX. But if I target foo.bar undir Maildir it all works. OK, my mental world model updated to what you just said; now consistent with all test results. Thanks. Bill
Re: [Dovecot] mdbox: Cannot create subfolder called dbox-Mails (2.0beta5)
On 13/05/2010 10:14, William Blunn wrote:
I am trying out mdbox under Dovecot 2.0beta5.
Looking in the mailboxes directory under the mdbox storage root
(~/dbox in my case), I can see that the mail folders are mapped into
filesystem directories.
But Dovecot seems to put all the message list information
(dovecot.index.cache, dovecot.index.log) for any given mail folder
into a directory called dbox-Mails...
But this directory name exists in the same namespace as that used for
mail subfolders...
So this means we cannot create a mail subfolder whose name is
dbox-Mails!
Looking at some new (1 Sep 2010) documentation from Timo at
http://wiki2.dovecot.org/MailLocation, it looks like in the meantime we
have grown a new configuration directive DIRNAME which can be used in
the mailbox location specification to change the metadata directory name
to something other than the default dbox-Mails.
So if site mail admins are concerned about clashes with user mail
folders called dbox-Mails they can choose another name for the
metadata directory.
OK fine so far, but then I saw the next bit.
We can also use DIRNAME with Maildir (if we have also specified
LAYOUT=fs) to specify that {new,cur,tmp} folders should be stored in a
subdirectory named by DIRNAME. This prevents clashes between user mail
folder names and the {new,cur,tmp} folders. It is then up to the site
admin to choose a value for DIRNAME which they think won't clash with
user mail folder names.
OK, but then it occurred to me, if we can use DIRNAME with Maildir, how
about LAYOUT with dbox?
How about having the ability to specify Maildir++ folder layout under
dbox? For example:
# Note: Following configuration line is hypothetical
mail_location = mdbox:~/mdbox:LAYOUT=maildir++
~/mdbox/mailboxes/dbox-Mails (mail folder INBOX)
~/mdbox/mailboxes/.foo/dbox-Mails (mail folder foo)
~/mdbox/mailboxes/.foo.bar/dbox-Mails (mail folder foo/bar)
~/mdbox/mailboxes/.foo.bar.baz/dbox-Mails (mail folder foo/bar/baz)
One upshot of this would be that user folder names would be in a
different namespace to the DIRNAME folder.
Also for admins who prefer fewer filesystem directory levels, this would
make them happy because all the mail folder levels would be at a single
directory level in the filesystem.
I suppose another upshot would be that it would look more like
Maildir++, which admins may already be familiar with, and might provide
a smoother/easier (mental) transition to dbox for admins.
Bill
Re: [Dovecot] Problems with dovecot 2.0, sieve and mdbox
On 04/09/2010 14:27, Patrick Westenberg wrote: The log shows that the script is called and executed but it is not able to find or create the mailbox: Hello Patrick, I probably can't help you with this problem, but I can mention that oftentimes if you ask about a problem on this list you may be asked to provide the output of dovecot -n. Bill
Re: [Dovecot] mdbox: Cannot create subfolder called dbox-Mails (2.0beta5)
On 04/09/2010 16:37, Timo Sirainen wrote: On 4.9.2010, at 11.40, William Blunn wrote: OK, but then it occurred to me, if we can use DIRNAME with Maildir, how about LAYOUT with dbox? How about having the ability to specify Maildir++ folder layout under dbox? For example: You can. I had an idea you might say that :-) Bill
Re: [Dovecot] bogus fts percentage
On 02/09/2010 15:03, William Blunn wrote: On 01/09/2010 20:35, Timo Sirainen wrote: On Mon, 2010-08-30 at 12:54 -0500, Mike Abbott wrote: Sometimes dovecot-2.0 sends this untagged response to clients: * OK Indexed -2147483648% of the mailbox, ETA 0:00 I imagine there's a bug in there somewhere. Well, I guess this fixes it: http://hg.dovecot.org/dovecot-2.0/rev/1012052e2e85 (I have written a fix and sent the diff to Timo.) I see Timo has put a further revision into hg on this issue: http://hg.dovecot.org/dovecot-2.0/rev/d55d6a72a043 Bill
[Dovecot] Documentation for altpath / altmove / ?Alternate storage
I was thinking about documentation for alternate storage. We have a few mentions at: http://wiki2.dovecot.org/MailboxFormat/dbox http://wiki2.dovecot.org/Tools/Doveadm http://wiki2.dovecot.org/Tools/Doveadm/Altmove But I was thinking it would be helpful if there could be a page about alternate storage. I could write the page, but I currently have so many unknowns that I think it would be better to gather some more information before writing the first draft. Note that I don't necessarily fully understand all the surrounding concepts, so I could have written something below which is based on a (vague) belief. Please correct me if I am wrong, or even if it's sort-of right but doesn't quite hit the point squarely. We might want to have a name for the wiki page. Perhaps AlternateStorage? Of course if it only applies to dbox, then another idea is to make it a section on the page MailboxFormat/dbox. All suggestions gratefully received. I would be interested in an overview of what alternate storage is. It seems to be a way of transparently moving message data to alternare storage, with the idea that the alternate storage may be on a different filesystem which may be cheaper and/or slower than the main storage, which may be an economic way to store messages where the fastest access to them is less important. It is transparent in as much as IMAP/POP users will not normally be able to tell if any given message has been moved to alternate storage. A single mail folder can end up containing a mixture of messages stored in main storage and alternate storage. (Another question begged here of what consistent term should be used to refer to the main storage. Could be main storage, normal storage, ordinary storage.) Also I would be interested to know the development/stability status of alternate storage: experimental / alpha / beta / stable. Also I would be interested to know the applicability against mailbox formats: mbox / maildir / sdbox / mdbox / cydir. Also I would be interested to know which data gets moved to the alternate storage, and which data stays in the main storage: message-data / control-data / index-data / combined-control-and-index-data. Also I would be interested to know how data can be moved to alternate storage. Seems to be that is only done by invocation of doveadm altmove. There is a page for that already so we can link to that. Also it would be interesting to have some idea of how it works. For example there might be an alternate storage flag in the indexes, or Dovecot tries the main location first and if not found there then it tries the alternate storage. Just a brief overview, and any pertinent ramifications of that. Bill
[Dovecot] Suggested location for single-dbox
I've updated http://wiki2.dovecot.org/MailLocation regarding a typical mail_location entry for dbox. Previously it said: mail_location = dbox:~/dbox but of course dbox is now the old name for sdbox, so the example should be updated to say sdbox and there might/ought also to be an example for mdbox. In http://wiki2.dovecot.org/MailboxFormat/dbox the example mail_location for mdbox is given as mdbox:~/mdbox, so I have followed that for MailLocation. So I have changed it to say # single-dbox mail_location = sdbox:~/dbox or: # multi-dbox mail_location = mdbox:~/mdbox I didn't know whether to change the directory for sdbox to ~/sdbox or to leave it as it is. For the time being I have left it at ~/dbox --- following the example given should allow new installations of Dovecot 2 to be able to read any existing single-dbox data which used the historically-suggested ~/dbox location, whilst at the same time avoiding using the old mailbox format name of dbox. Bill
Re: [Dovecot] Documentation for altpath / altmove / ?Alternate storage
On 03/09/2010 15:01, Timo Sirainen wrote: With multi-dbox the moving is more complex, but still it only copies the data in m.* files. Dovecot always tries to look for the u.123 or m.123 file from primary storage and if it's not found there, it looks it up from alternate storage. The state isn't stored in indexes. Really simple. Thank-you for all your other comments by the way. That is all good stuff and appreciated. I think the only thing I had further questions on was how alternate storage works with mdbox. In http://wiki2.dovecot.org/MailboxFormat/dbox it says we have * dovecot.map.index* files contain the map index * m.* files contain the mail data I think I am not clear on the dovecot.map.index* files. Is that really just one file dovecot.map.index, and the globby asterisk just indicates that there may be may be old versions if the file has been updated by being re-written? dovecot.map.index* is always stored in the primary storage? (Sorry if it sounds like I am asking questions you've already answered. I want to make sure I understand it properly.) So if we are moving mail to alternate storage, we write them into a new m.* file in the alternate storage folder containing the messages we want to move. So that would mean it only really makes sense for any given numbered m.* file to exist in either the primary storage or the alternate storage but not both? So when Dovecot is wanting to find the next unused m.* file number, it needs to consider files in both the primary storage and alternate storage? Bill
Re: [Dovecot] bogus fts percentage
On 01/09/2010 20:35, Timo Sirainen wrote: On Mon, 2010-08-30 at 12:54 -0500, Mike Abbott wrote: Sometimes dovecot-2.0 sends this untagged response to clients: * OK Indexed -2147483648% of the mailbox, ETA 0:00 I imagine there's a bug in there somewhere. Well, I guess this fixes it: http://hg.dovecot.org/dovecot-2.0/rev/1012052e2e85 Inspection of code reveals a bug in this change. This bit: 1.22 -secs = (msecs / (percentage / 100.0) - msecs) / 1000; 1.23 +secs = (msecs*percentage / 100 - msecs) / 1000; changes the calculation from estimated_total_time = elapsed_time ÷ completed_fraction which seems to be correct, to estimated_total_time = elapsed_time × completed_fraction which seems to be incorrect. (I have written a fix and sent the diff to Timo.) Bill
Re: [Dovecot] Dovecot creating aditional folders?
On 01/09/2010 12:10, Pablo wrote: Thank you again. Yes, you're on the way :-) Problem was that in /etc/dovecot/dovecot.conf was: mail_location = maildir:/home/vmail/%u/ instead of my new line: mail_location = maildir:/home/vmail/%d/%u/ Are you sure that you want %d/%u and not %d/%n ? Bill
[Dovecot] Does Dovecot support the use of the INDEX directive for mdbox?
Does Dovecot support the use of the INDEX directive for mdbox? e.g. mail_location = mdbox:~/mdbox:INDEX=/var/indexes/%u Bill
Re: [Dovecot] Home directories
On 24/08/2010 15:57, Timo Sirainen wrote: I've noticed that a lot of people are using e.g.: mail_location = maildir:/var/vmail/%d/%n Then either they don't have home directory set, or their home directory is the same as the maildir. http://wiki.dovecot.org/VirtualUsers/Home explains all the problems of not separate home and mail directories. Also whenever I try to suggest using a separate home and mail directory, the answer is way too often: But I'm using virtual users. (They don't have home directories.) So I started wondering. Maybe simply renaming the home to something else would help here at least some. Make all of the documentation use only the new word, and add alias for userdb so that the new name and the home both work (I guess docs would need to keep using the home as field name for some more years). So far I've only come up with vhome as the replacement name. Other ideas? Note what follows is more a collection of ideas which jumps around a bit rather than a cogent coherent logical sequence. Is there a potential problem with the term virtual home in as much as for system users it is not virtual but the user's (actual) home directory? That being the case I'd avoid the word virtual. It seems we also want to avoid the word home. So I see logic in calling it the user state directory which could be userdir for short. -=- Is there a global configuration directive like mail_location wherein the two directives could be placed adjacently? # Note: Fictional example. Does not work. mail_location = maildir:/var/vmail/%d/%n/mail user_state_directory = /var/vmail/%d/%n -=- Could the documentation be re-structured to encourage the configuration of the two parts of the storage 1. Mail directory 2. User state directory ? Then to say words to the effect of: For virtual user environments, you need to set both of these aspects up. You may want to set up mail as a subdirectory off the user state directory. Alternatively you can put them in separate locations. For system user environments, you may want to have the user state directory go directly on to the user's home directory / a subdirectory of the user's home directory. -=- Another idea would be to say that, perhaps for Dovecot 2.1 (i.e. a suitably large version bump), that having a configuration which Dovecot could divine leaves things open to filesystem name clashes between the user state directory and the mail directory (or whatever is considered to be a bad outcome of not properly configuring the user state directory) would create a fatal error at daemon start time. Perhaps there could be a configuration directive to override this check, wrapped in suitably comprehensive documentation which means that people who absolutely insist can ice skate uphill, but the path of least resistance would be to configure Dovecot properly. Bill
Re: [Dovecot] IMAP connection timeout value?
On 19/08/2010 11:04, Tamas Kadar wrote: So we're having some ISP issues lately, meaning we have to reboot our cable modem like 2-3 times a day. An unfortunate side-effect I've found is, once the users max out their connection limit (which I've set to 10, and many people do), if we reboot the cable modem, they can't log in cause their connections get 'stuck' until I `doveadm kick` them, or wait for the connections to timeout which takes ??? minutes. Can I adjust that value to something like 30 seconds? Is it: (a) your server is on the Internet, and your clients are behind the dodgy cable modem, or (b) your mail server behind the dodgy cable modem and the clients are out on the Internet ? Either way I would suggest an improvement to your architecture would be to put the mail server on the same side of the dodgy cable modem as the majority of users. If you have a mix of office users and out-of-office users, I would say put the mail server on the Internet side. At least then the people struggling out in a hotel in the middle of nowhere won't have to fight your dodgy cable modem as well as their dodgy foreign internet connection. Bill
Re: [Dovecot] pigeonhole and utf-8 error
On 18/08/2010 08:38, Xavier Pons wrote: El 17/08/2010 18:57, Timo Sirainen escribió: On Tue, 2010-08-17 at 09:35 +0200, Xavier Pons wrote: Aug 17 09:22:40 imap1 dovecot: lmtp(19629,miel): Error: kea6K484akytTAAAJBW4rA: sieve: msgid= 1099311971.505.1282029699154.javamail.open-xcha...@o.uib.es: failed to store into mailbox 'atenció':mailbox name not utf-8: atenció dovecot it's working without problem on this folder. I suppose it's a misconfiguration, but I don't find where... I guess you wrote the script with ISO-8859-x charset or something instead of UTF-8. my default system LANG is 'en_US.UTF-8'. Also, I have tried to edit this filter with 'vi +set encoding=utf-8 sievefilter' , and the folder name it's correctly writed/displayed, but when it's executed from dovecot lmtp give me this error. To do an acid test, try viewing your filter using cat -A. If you get a sequence like atenciM-s, then your character ó is represented by byte 0xF3 and it's ISO-8859-1 (or 2/3/9/10/13/14/15/16). If you get a sequence like atenciM-CM-3, then your character ó is represented by bytes 0xC3, 0xB3 and it's UTF-8. Bill
Re: [Dovecot] Upgrade to 2.0 - Not so smooth
On 15/08/2010 22:49, Marc Perkel wrote: On 8/15/2010 2:32 PM, Marcus Rueckert wrote: On 2010-08-15 14:01:25 -0700, Marc Perkel wrote: Seems to me that it wouldn't take a lot of code to at lease find if they have adduser or useradd. that is 2 out of many solutions. and depending of the admin he might create the user in an ldap tree or a nis server. also packager dont really like users created from the buildsystem. darix Perhaps a better error message that says something like: Dovecot needs a user named dovenull to work. Please create user dovenull and try again. No. The first sentence of your proposed message is FALSE. On 15/08/2010 17:10, Timo Sirainen wrote: - Dovecot uses two internal users now by default: dovenull and dovecot. You need to create the dovenull user or change default_login_user setting. Dovecot does NOT need a user named dovenull to work. The second sentence is predicated on the first and as such also falls down. Dovecot needs a user named by the default_login_user setting in order to work. Whilst this defaults to dovenull, there is nothing to stop you setting it to something else (e.g. flibble). The point is that the answer is more of a commentary and the right solution depends on the situation. Rather than try to squeeze solution summaries into every error message, I would suggest having a link (perhaps into the Dovecot wiki) in the error message, e.g. Starting Dovecot Imap: Fatal: service(pop3-login) User doesn't exist: dovenull (see http://wiki2.dovecot.org/Errors/NoDefaultLoginUser) (Note that the above URL is hypothetical.) Then have a commentary and suggested solutions in the wiki. Alternatively, the link could rooted at a notional documentation root like: Starting Dovecot Imap: Fatal: service(pop3-login) User doesn't exist: dovenull (see documentation Errors/NoDefaultLoginUser) so that users could refer to a local copy of the documentation rather than encouraging load on the Dovecot wiki server(s). Bill
Re: [Dovecot] v2.0.0 released
On 16/08/2010 15:49, Timo Sirainen wrote: As promised last Friday, here's the v2.0.0 release finally. Brilliant work Timo! Bill
Re: [Dovecot] Subdomain Migration
On 16/08/2010 17:58, Jerrale G wrote: On 8/16/2010 3:44 AM, ramesh wrote: Hi All, I would like have suggestion for changing subdomain (belongs to ISP) to own domain, the scenario as below. Presently we have subdomain from ISP ( @xxx.isp.net) email id : ram...@xxx.isp.net ISP charges huge amount,thou others ISP charges less. so we have planned to migrate to our own registered domain and terminate existing ISP. Now my requirement is email coming to ram...@xxx.isp.net (Mail server connected to present ISP) should forward to ram...@mydomain.co.in (Mail server connected to new ISP) Please send me suggestion to follow or URL's explain briefly. Thanks. Regards, Ramesh They have to send mail to y...@yournewdomain.com unless you plan on keeping your isp's subdomain Is it just me or can anyone else NOT see the original message from ramesh? I've looked in my inbox, and viewed the mailing list archive both over the web and via the IMAP interface, and I can't see the original message. Bill
Re: [Dovecot] Upgrade to 2.0 - Not so smooth
On 15/08/2010 17:14, Dennis Clarke wrote: On 15.8.2010, at 17.03, Marc Perkel wrote: Starting Dovecot Imap: Fatal: service(pop3-login) User doesn't exist: dovenull Just some real time feedback. I don't know what dovenull user is or why it is necessary. I added now to http://wiki2.dovecot.org/Upgrading/2.0 : - Dovecot uses two internal users now by default: dovenull and dovecot. You need to create the dovenull user or change default_login_user setting. Dovecot 2.x seems to be very close to release grade. Could you provide a guess as to when it will be released so that I can plan downtime for the upgrade on my production servers? See Timo's comment of Friday 13/08/2010 19:29: http://dovecot.org/releases/2.0/rc/dovecot-2.0.rc6.tar.gz http://dovecot.org/releases/2.0/rc/dovecot-2.0.rc6.tar.gz.sig I expect this to be the last release candidate. Unless release critical bugs are reported, I'll update the version number to v2.0.0 on Monday morning without any other changes. Since rc5 there have been mainly some small fixes and some error message improvements. The only (somewhat) important fixes are: - dict quota didn't always decrease quota when messages were expunged - Shared INBOX wasn't always listed with FS layout I'll update the version number to v2.0.0 on Monday morning Bill
Re: [Dovecot] Outlook 2003 Client
On 10/08/2010 10:51, Richard Gliebe wrote: my dovecot IMAP Server (1.0.7-7.el5) is now up and running ;-) Congratulations. You just installed an old unsupported version. If you want help from the list, you need to be running 1.2.x or later. If you distro includes an older version, then that is not considered to be an acceptable excuse. You should take steps to mitigate that, for example sniffing around for a binary package for 1.2.x, or installing from source. Now I want that all clients have to save there sent messages in the IMAP folder on the server. no problem with the thunderbird clients. BUT, I can't configure the office 2003 clients to save there send messages to the imap folder. Some people told me, that outlook 2003 isn't able to do that. The send messages folder have to be a local folder and not a folder on the IMAP server. I can't believe. The only way on outlook 2003 is to create a messages filter very strange In my experience, Outlook support for IMAP is sucky generally. Looking at the landscape, it probably always will be. Microsoft wants you to pay them $$$ to run Exchange Server, so it is in their interest to only support IMAP as an afterthought. There will be just enough support so that people who happen to already be using Outlook won't be immediately prompted to switch to something else. They only need to make the IMAP support just good enough so that the pain of switching to another program is more than the pain of putting up with the poor IMAP support. Microsoft's thinking seems to be that if people are still using Outlook they *might* one day switch to Exchange Server, but if they have switched to some other client, they will likely never switch to Exchange Server. But they musn't make the IMAP support too good otherwise people won't have any reason to switch to Exchange Server. If you aren't even using Exchange Server, then there is little point using Outlook. Outlook has enough other suckiness as well --- it has no concept of no font, so will always stamp the author's font on to outgoing messages, even if the author wasn't intending to specify a font. Plus you will likely get several kilobytes of pointless stylesheet tacked on to every outgoing message. Plus the authors don't seem to have heard of format-flowed, and instead seem to think it is a good idea to join together separate lines based on heuristics rather than following the established standards. Altogether, I wouldn't touch Outlook with a bargepole. If you aren't using Exchange Server, then I see little point in using Outlook, given the easy availability of superior solutions, e.g. Thunderbird. Bill
Re: [Dovecot] (Single instance) attachment storage
Damon Atkins wrote: Just keep in mine Signed Emails, the email contents needs to be present back to the client as it came, so the client says the email has not been altered. Timo will presumably correct me if I am wrong: I believe it is already a design goal that messages going in to the mail store will come out byte-for-byte verbatim at the RFC5322 message stream level. I suppose the suggestion to come out of this is that if there is to be any partial or complete RFC2045-deconstruction of messages that this will suggest to some people the possibility of non-verbatim retrieval, and it might be an idea for the documentation to make it clear whether or not stored messages will be retrieved verbatim at the RFC5322 message stream level. It might be useful if the documentation gave confidence-building examples such as for example, blocks of base64 encoded data will only be stored in decoded form if, when re-encoded, the original base64 stream can be reconstructed byte-for-byte verbatim. Or if messages might not come back verbatim, it might be useful if the documentation were to explain what scenarios it might not be verbatim, and the nature of the differences which may occur. Bill
Re: [Dovecot] (Single instance) attachment storage
Timo Sirainen wrote: Now that v2.0.0 is only waiting for people to report bugs (and me to figure out how to fix them), I've finally had time to start doing what I actually came here (Portugal Telecom/SAPO) to do. :) The idea is to have dbox and mdbox support saving attachments (or MIME parts in general) to separate files, which with some magic gives a possibility to do single instance attachment storage. Comments welcome. Cool. Extra features -- The attachment files begin with an extensible header. This allows a couple of extra features to reduce disk space: 1) The attachment could be compressed (header contains compressed-flag) Cool. 2) If base64 attachment is in a standardized form that can be 100% reliably converted back to its original form, it could be stored decoded and then encoded back to original on the fly. Cool. I have thought about this issue in the past. What follows may be obvious to you already, but might as well mention rather than missing something. Presumably you want to be able to recreate the original base64 stream exactly verbatim? Under base64, the number of 4-byte (encoded) / 3-byte (decoded) cells per line is not fixed by the specs. I believe the optimal value is 19 cells per line, but I have seen some systems use 18 cells per line, and I think I have seen 15 as well. Once you have three possibilities, you might as well just store the number of cells per line. I would suggest considering the base64 format as (conceptually) having an (integer) parameter for the number of cells in each line (except for the last line). So base64(19) would have on each line 19 cells encoding 57 (19 × 3) bytes into 76 (19 × 4) bytes. Probably you would need to have a base64 matcher/decoder which is smarter than normal base64 decoders and checks to make sure that all lines (apart from the last) are encoded (a) canonically (e.g.. with no trailing whitespace), and (b) using the same number of cells per line. The base64 matcher/decoder needs to return information about the cell count as well as the decoded data. If any line is not canonical base64 or uses a different number of cells, then the base64 may still be valid but weird so would just be stored as the original base64 stream. When recovering message data, obviously your base64 encoder needs to use a parameter which is the number of cells per line to encode. Then you get back your original base64 stream verbatim. == Some systems finish the base64 stream with a newline (which in a multipart manifests as a blank line between the base64 stream and the '--' of the MIME boundary), whereas some systems finish the base64 stream at the end of final 4-byte cell (which in a multipart manifests as the '--' of the MIME boundary appearing on the line immediately following the base64 encoded data). Your encoding allows for arbitrary data between the objects, so you would have no problem store these two cases verbatim. But something to watch out for when storing. == Maybe it would be a good idea to have the ability to say that an object was base64 decoded AND compressed (i.e. to recover the original stream fragment you need to decompress and base64 encode (with the relevant number of base64 cells per line)) --- as well as options for just base64 decoded or just compressed. You could go nuts and say that it is an arbitrarily-sized filter stack, but my first guess would be that this would be too much flexibility. It might be better to say that there can be zero or one decode/encode layers (like base64 or something else), and zero or one compression layers (like gzip or bzip2 or xz/LZMA). Obviously whatever translations are required to recover the original stream should be encoded into the attachment file so that sysadmins can tune the storage algorithm without affecting previously stored attachments. Bill
Re: [Dovecot] (Single instance) attachment storage
Timo Sirainen wrote: X1442 2742784 94/b2/01f34a9def84372a440d7a103a159ac6c9fd752b 2744378 27423 27/c8/a1dccc34d0aaa40e413b449a18810f600b4ae77b So the format is: X 1*(offset byte count link path) ... Extra features -- The attachment files begin with an extensible header. This allows a couple of extra features to reduce disk space: 1) The attachment could be compressed (header contains compressed-flag) 2) If base64 attachment is in a standardized form that can be 100% reliably converted back to its original form, it could be stored decoded and then encoded back to original on the fly. Consider storing the recovery filter stack in the dbox metadata rather than the attachment file. e.g. so I put -b64_19 after the file path to indicate that it needs to be exploded to base64 with 19 cells per line before being incorporated in the message stream. X1442 2742784 94/b2/01f34a9def84372a440d7a103a159ac6c9fd752b -b64_19 2744378 27423 27/c8/a1dccc34d0aaa40e413b449a18810f600b4ae77b -b64_19 This means that the attachment file can be purely the attachment data. This has a couple of upshots: 1. If one person receives a message with an attachment which is encoded with base64 at say 19 cells (76 bytes) per line, and then re-sends the same file as an attachment to someone else but their MUA encodes base64 at say 18 cells (72 bytes) per line, the attachment file can contain exactly the same data, allowing for deduplication even in this case. 2. Assuming we have configured Dovecot to decode base64 but not to compress, then the file in which we store the attachment data contains literally the exact same byte stream as if the attachment were saved out from the MUA. I don't know what practical use this might be, but it /sounds/ cool :-) Perhaps a suitable filesystem or backup-system could deduplicate both a file *and* its instance as a message attachment. Bill
Re: [Dovecot] (Single instance) attachment storage
Timo Sirainen wrote: BTW. I was thinking about using number of characters per base64 line rather than number of cells. I don't think it's required that line ends with a complete cell. You're right. Looking at RFC2045, whitespace aside, the entire stream must be an integer quantity of 4 character cells. But the whitespace can appear anywhere. So yes, number of characters per line. So my base64(19) becomes base64(76). Bill
Re: [Dovecot] (Single instance) attachment storage
Timo Sirainen wrote: I was thinking it would be nice to be able to compress attachments after they've already been delivered. Like maybe keep the attachments decoded for a few weeks and then compress them. Similar to how some people do it with Maildir. This can't work without a small header, otherwise you can't know if the attachment was originally compressed or not. What about doing what people do with files and codify the compression status in the filename? Assume the attachment file has a base name of foo. If you want to compress it, create a file foo.gz (or foo.bz2 or foo.xz), and remove the original file foo. This assumes that if an open file is unlinked it will remain in existence until closed. Code which wishes to read attachment files should first try to open the file using the base name. If the base name does not exist then it can try suffixes until it finds a file which opens. The suffix which worked then determines the decompression algorithm to be used. The cost of an extra directory search (on messages which are understood to be historical in any case) should be dwarfed by the cost of decompressing the data. This also solves the problem of how you compress a file in place. By creating the compressed version alongside, you never upset any readers. This also helps out sysadmins because they would then be able to examine compressed attachment files straight off (zcat, bzcat, xzcat, et. al.) without having to think about any Dovecot-specific way of how the files might be laid out. Bill
Re: [Dovecot] Temporary files
1.
If know you are delivering to Maildir, and you know the folder you are
delivering to, then surely you have a temporary directory in the tmp
out of Maildir's {new,cur,tmp} ? And also the potential benefit of being
able to rename the resulting file into the new directory.
2.
I would like to have the temporary directory be configurable (but with a
sane default like /tmp or perhaps /tmp/dovecot).
In an installation where Dovecot is being used heavily, people might
want to assign specific resources for Dovecot operation. So someone
might decide that Dovecot should have a specific device (hard disk /
solid state disk / whatever) for its temporary files, other than the
default /tmp.
Bill
Re: [Dovecot] I can receive but not send
Dennis Clarke wrote: Am I missing something obvious here ? Dovecot isn't a SMTP-Server/MTA. See also: http://wiki.dovecot.org/MailServerOverview That figures ... it had to be my sendmail config of all things. Geez .. I hate sendmail configuration. I hate sendmail configuration sigh http://shearer.org/MTA_Comparison Bill
Re: [Dovecot] Dovecot 2.0 with LMTP
Thiago Henrique wrote: I'm testing Dovecot 2.0. I plan to use Dovecot 2.0 with thousands of domains per server. My user base is under virtual MySQL. Is there a way to make the LMTP not make query to MySQL for each message delivered ? I'm afraid that the MySQL server does not support the load. A SELECT query retrieving a single record on a MySQL database should be a cheap operation. How long are your queries taking? Your common queries should work principally by index scans. Your indexes should be entirely in RAM. So queries which retrieve a single row from a table should run in O(log N) time, which in my experience is usually measured in milliseconds. Bill
Re: [Dovecot] Dovecot 2.0 with LMTP
Charles Marcus wrote: On 2010-07-07 8:16 PM, Timo Sirainen wrote: On 8.7.2010, at 1.02, Thiago Henrique wrote: Is there a way to make the LMTP not make query to MySQL for each message delivered ? I'm afraid that the MySQL server does not support the load. b) If a) doesn't work, you can set auth_cache_size so Dovecot will cache recent lookups. What SMTP server do you use? Postfix has excellent support for address caching, including positive/negative cache settings that can be tuned for just such purposes: http://www.postfix.org/postconf.5.html#address_verify_map Exim also has excellent caching for recipient address verification. Bill
Re: [Dovecot] Manually creating folders from terminal
A. J. Giurato wrote:
I'm trying to use a script to create a mailbox structure. I'm aware
that the structure should look like:
~/.maildir/.INBOX/{cur,tmp,new}
~/.maildir/.INBOX.Subfolder1/{cur,tmp,new}
~/.maildir/.INBOX.Subfolder2/{cur,tmp,new}
~/.maildir/.INBOX.Subfolder2.Subsubfolder1/{cur,tmp,new}
...
I have tried manually making those directories and using the
maildirmake.dovecot command that my system has. I feel that in the
past, folders I have made this way worked. However, now none are
showing up in my clients.
In Thunderbird, they aren't even listed on the Subscribe window for
me to enable. Using Squirrelmail doesn't show them either.
Essentially what I am doing is taking my current IMAP dir structure,
and making a copy in a subfolder called .INBOX.Archive.year to
archive my old mail. Thus, .INBOX.Subfolder1.Subfolder2 becomes
.INBOX.Archive.2009.Subfolder1.Subfolder2.
My system:
Ubuntu 8.04
# 1.0.10: /etc/dovecot/dovecot.conf
log_timestamp: %Y-%m-%d %H:%M:%S
ssl_listen: *
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
mail_privileged_group: mail
mail_access_groups: mail
default_mail_env: ~/.maildir
mail_location: ~/.maildir
I am not a Dovecot expert, but I would wonder if it makes a difference
if mail_location has not specified the mailbox type, e.g.
mail_location = maildir:~/.maildir
Also worth noting that the de-facto standard location for Maildirs is
~/Maildir, which would be indicated with
mail_location = maildir:~/Maildir
Bill
Re: [Dovecot] Manually creating folders from terminal
A. J. Giurato wrote:
I'm trying to use a script to create a mailbox structure. I'm aware
that the structure should look like:
~/.maildir/.INBOX/{cur,tmp,new}
~/.maildir/.INBOX.Subfolder1/{cur,tmp,new}
~/.maildir/.INBOX.Subfolder2/{cur,tmp,new}
~/.maildir/.INBOX.Subfolder2.Subsubfolder1/{cur,tmp,new}
...
I have tried manually making those directories and using the
maildirmake.dovecot command that my system has. I feel that in the
past, folders I have made this way worked. However, now none are
showing up in my clients.
In Thunderbird, they aren't even listed on the Subscribe window for
me to enable. Using Squirrelmail doesn't show them either.
Essentially what I am doing is taking my current IMAP dir structure,
and making a copy in a subfolder called .INBOX.Archive.year to
archive my old mail. Thus, .INBOX.Subfolder1.Subfolder2 becomes
.INBOX.Archive.2009.Subfolder1.Subfolder2.
Since you have gotten as far as asking on the mailing list, it may be
worth just sanity checking that your folders are being created under the
correct user and group IDs.
Bill
