- dovecot - dovecot.org

[Dovecot] Accessing a strange mailbox
by Micah Anderson 07 Nov '11

07 Nov '11

I have a user who has a mailbox called: A----->B It seemed to work in courier fine, they managed to create it, and there are mails in it. However, dovecot is not letting the user access it, the IMAP server gives an error. I tried to rename it but I would also get an error: # doveadm mailbox rename A-----\>B AtoB doveadm(root): Error: Can't rename mailbox A----->B to AtoB: Mailbox doesn't exist: A----->B # doveadm mailbox rename A----->B AtoB doveadm(root): Error: Can't rename mailbox A----- to AtoB: Mailbox doesn't exist: A----- # doveadm mailbox rename 'A----->B' AtoB doveadm(root): Error: Can't rename mailbox A----->B to AtoB: Mailbox doesn't exist: A----->B # doveadm mailbox rename "A----->B" AtoB doveadm(root): Error: Can't rename mailbox A----->B to AtoB: Mailbox doesn't exist: A----->B # How can I deal with this mailbox (using mdbox here)? Thanks! --

3 2

[Dovecot] Problems with password verification on a BSD box against PAM
by Michael Schinhammer 06 Nov '11

06 Nov '11

Spam detection software, running on the system "ns.089.at", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi ML, i want to use my local users database on my Freebsd 8.2 box and got the following error in the maillog. The password is ok and it working on the console. i can establish the ssl connection after login "a login ux password" the error occures i cant login. [...] Content analysis details: (6.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 MR_NOT_ATTRIBUTED_IP Beta rule: an non-attributed IPv4 found in headers 0.6 J_CHICKENPOX_65 BODY: 6alpha-pock-5alpha 0.6 J_CHICKENPOX_73 BODY: 7alpha-pock-3alpha 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 NO_RDNS2 Sending MTA has no reverse DNS 3.5 TO_NO_BRKTS_DIRECT To: misformatted and direct-to-MX

1 0

[Dovecot] Converting from 1.12 to 2.0 questions about mail location?
by Knute Johnson 05 Nov '11

05 Nov '11

I'm building a new server and using a newer version of ubuntu server that uses Dovecot 2.0. I thought I would like to use Maildir instead of the mbox that was used in the previous server. What do I have to do to convert my mbox mail to Maildir? Or should I just use mbox and copy it over :-)? Thanks, -- Knute Johnson

2 1

[Dovecot] Safely restoring backups
by Micah Anderson 05 Nov '11

05 Nov '11

I'm trying to determine what the best way to restore mail with mdbox is. Restoring using maildir was trivial, I just used rsync --ignore-existing which wrote any mails that were removed and didn't touch things that already existed[1]. With mdbox things have become more complicated, and I haven't found a way to restore mail that doesn't result in many message duplicates. My backup setup is simple, I'm doing daily rsync backups of user's mailstores, as well as weekly backups, so I end up having on my backup server daily.1, daily.2, daily.3, daily.4, weekly.1, weekly.2... each containing the entire contents of the user's mdbox. The different restore methods I've tried are: 1. I tried rsyncing the different backup directories back to the mail storage host, and then doing: 'dsync -R backup -u $user mdbox:/path/to/to/daily.1/mdbox'[2] 'dsync -R backup -u $user mdbox:/path/to/to/daily.2/mdbox' This works ok, but it gives duplicates of every mail that already exists for every daily/weekly I dsync. This is what the rsync --ignore-existing avoided. This is particularly annoying if I restore the weekly, and multiple daily directories, because then you get a copy for every one you restore. I had thought that the individual message's GIDs would keep them from being duplicated? 2. I also tried to use 'doveadm import' in two different ways. The first way I created a 'restored_from_backups' folder and then import each of the daily.#, weekly.# mdboxes into their own subfolder within that folder, for example: 'doveadm import -u $username mdbox:/path/to/daily.1/mdbox restored_from_backups/daily1 all' 'doveadm import -u $username mdbox:/path/to/daily.2/mdbox restored_from_backups/daily2 all' ... etc. I then go through and subscribe the new folders[3] and the user ends up with a folder structure like this: restored_from_backups/ daily.1/ INBOX Trash folder1 folder2 daily.2 INBOX Trash folder1 folder2 etc. This works fine, except that it results in the user having a entire duplicate copies of their mailbox for each daily/weekly that I restore. That will quickly bring people over quota. 3. I also tried to use 'doveadm import' to import all the different directories all into the same restored_from_backups directory, so there are no subdirectories for each daily/weekly under restored_from_backups, like so: 'doveadm mailbox create -u $user -s restored_from_backups' 'doveadm -v -D import -u $user mdbox:/path/to/daily.1/mdbox restored_from_backups all' I then go through and subscribe the folders[3]. Using this method, the 'restored_from_backups' mailbox is created, and populated with the folders. The only problem with this method is the same as method #1: for every backup I restore, mails are duplicated. Is there a way I can restore things from backup and avoid duplicates? Is there another method I should try? thanks for any ideas, pointers, suggestions for improvement, etc. micah 1. this would of course bring back mails that were deleted, but that was fine as the user could deal with that. 2. yes, I know I could setup dsync on the backup server, and use dsync directly to pull the mails from there, but this is complicated in my situation due to how the backupserver works. 3. why doesn't doveadm import have a -s option to subscribe? --

2 1

[Dovecot] Newbie Question/Feature Request
by Michael Papet 05 Nov '11

05 Nov '11

Hi, I'm working on a plugin for qpsmtpd (a perl smtp frontend) that delivers mail via dovecot's LDA. I can only get mail delivered by writing the email to file, then calling 'deliver -d someone -f someone-else < /path/to/temp/email' All good, expected behavior. A perl snippet: local $/=undef; open FH, "< ./demo.mail"; my $stringified = <FH>; # this is roughly equivalent to how other LDA queues work. close FH; open (CMD_OUT, " /usr/lib/dovecot/deliver -f somedude\(a)someplace.com -d anotherdude\(a)destination.dom $stringified |"); my $test = <CMD_OUT>; print $test; The above code errors out because the expected behavior is $stringified is supposed to be a file name. It would be great if deliver could be fed the email as a string so I don't have to add a step of writing to file. Or, maybe there's an undocumented method? Thanks. mpapet

2 1

[Dovecot] dsync with quotas
by Micah Anderson 05 Nov '11

05 Nov '11

I have been working on converting people from courier maildir -> dovecot mdbox and during some of the dsync runs I'm seeing the quota_exceeded_message be printed as an Error: dsync(<user>): Error: Can't save message to mailbox INBOX: You are over quota. To avoid losing mail, immediately empty your Trash and Sent folders and \ delete emails with large attachments. dsync(<user>): Info: INBOX: Couldn't keep all uids^M Its possible the user was over quota on the originating courier side, but I would still like to migrate their mail proprely to mdbox, but it seems like being over quota is inhibiting that. Are the quota calculations including both the maildir files as well as the converted mdbox files, resulting in a double counting? I'm not entirely sure if the messages above indicate that the migration failed for that user or not, so I've been manually increasing their quota, then redoing the dsync mirror until it works properly. I wonder if it would be better if I turned off quota entirely during migration so I don't run into this problem? thanks, micah --

2 2

[Dovecot] Group ACL
by Daniel L. Miller 05 Nov '11

05 Nov '11

Using Dovecot 2.0, LDAP userdb & passdb, with prefetch: hosts = myhost.mydomain dn = cn=x,cn=y dnpass = xyz123 auth_bind = yes auth_bind_userdn = uid=%n,ou=users,dc=x ldap_version = 3 base = ou=Users, dc=x user_attrs = =home=/var/mail/%d/%n, \ =mail=mdbox:/var/mail/%d/%n/mdbox, \ =uid=vmail, \ =gid=mail user_filter = (&(objectClass=inetOrgPerson)(mail=%u)) pass_attrs = mail=user, \ userPassword=password, \ =userdb_home=/var/mail/%d/%n, \ =userdb_mail=mdbox:/var/mail/%d/%n/mdbox, \ =userdb_uid=vmail, \ =userdb_gid=mail, \ =userdb_acl_groups='allshared' pass_filter = (&(objectClass=inetOrgPerson)(mail=%u)) iterate_attrs = mail=user iterate_filter = (&(objectClass=inetOrgPerson)(mail=*)) default_pass_scheme = plain I have added permissions for "$allshared" to a mailbox's Inbox. It does not appear in the shared folders list. Other mailboxes, with explicit permission for a given username, work fine. What am I doing wrong? -- Daniel

2 1

Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
by Maria Arrea 05 Nov '11

05 Nov '11

Timo, we are not using NFS, we use remote iSCSI volumes with ext4. Regards Maria ----- Original Message ----- From: Timo Sirainen Sent: 11/04/11 09:59 PM To: Maria Arrea Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube On Thu, 2011-11-03 at 10:54 +0100, Maria Arrea wrote: > Hello. > > We are running dovecot 2.0.13 with mdbox+zlib on RHEL 5.7 x64, ext4. We use NTP. Indexes are in a iSCSI raid 10, mailboxes in raid5. No NFS. We have detected that sometimes all users get disconnected from roundcube at the same time. In dovecot logs we hundreds of lines like this: > > Nov 3 09:23:07 buzon dovecot: imap(mcrivero@mydomain): Warning: Created dotlock file's timestamp is different than current time (1320308587 vs 1320308542): /buzones/mydomain/03/67/mcrivero/subscriptions I did several fixes related to this, but they were already in v2.0.10. Note the time difference of 45 seconds. > Nov 3 09:23:07 buzon dovecot: imap(mcrivero@mydomain): Connection closed bytes=0/295 The dotlock warning isn't related to this. My guess: NFS was being extremely slow here, some operation took 45 seconds and Roundcube decided to abort before that. The "timestamp is different" check doesn't work 100% correctly if the filesystem operations take more than a second.

2 1

[Dovecot] Bad creation timestamp of migrated mails (maildir format)?
by Lukas Weiß 05 Nov '11

05 Nov '11

Hello everybody, ive just switched to dovecot imap because dbmail i used before is not developed any further and sql storage is difficult to backup. Ive done that, by setting up dovecot with maildir format and copy mails from old dbmail to new dovecot imap server with my mail client (thunderbird). Unfortunately migrating to dovecot brought me some problems with my Android K9 Mail client: Sync with IMAP-Server shows me only the oldest mails. I think the problem is, that K9 only fetches the newest mails (25) from the server (to save memory etc). Which mail is "new" is probably determined by creation timestamp of the email-files in my mailbox, which was copied newest first on migration from dbmail to dovecot. So the older mails have the newer creation timestamp on file system. Do you have any suggestions how to fix that problem? Maybe migrate to dbox mailbox format? BTW: New mails show up correctly, as the creation timestamp is new. Thanks Lukas

3 6

[Dovecot] fts-lucene vs SEARCH header Re: 2.1: problems compiling fts-lucene - CLucene git version necessary?
by Lutz Preßler 05 Nov '11

05 Nov '11

On Tue, 20 Sep 2011, Lutz Preßler wrote: > On Mo, 19 Sep 2011, Timo Sirainen wrote: > > > On Sun, 2011-09-18 at 13:27 +0200, Lutz Preßler wrote: > > > Hello, > > > On So, 11 Sep 2011, Timo Sirainen wrote: > > > dovecot: imap(...): Error: fts_lucene: default_language set, but Dovecot built without stemmer support > > > > Fixed: http://hg.dovecot.org/dovecot-2.1/rev/02c84406c661 > Without stemmer support it works nicely now though. Next problem :-) side effect: my test setup (some commits ago) with fts = lucene in plugin section (ftps_lucene plugin without stemmer support): SEARCH header is not working (empty result sets, no logging). Tested in different circumstances (and also happening with virtual folders). Simply disable fts option (while module is still loaded) or use fts=sqat to have header search working correctly again. Lutz

2 1