Re: [Dovecot] Global fields for passwd-file database
And no hope it'll be implemented ever? -- Best regards, Sergey Urushkin Timo Sirainen t...@iki.fi wrote: On Fri, 2011-05-20 at 09:37 +0400, Sergey Urushkin wrote: Is there a way to specify global fields for passwd-file DB? No.
Re: [Dovecot] How to stop mail_executable from cwd to ~home
On Thu, 19 May 2011, I wrote:
Gary Duncan gdun...@engr.uvic.ca writes:
Works well except that dovecot still wants to cd to the real home
triggering a useless and potentially hindering automount when it
invokes the imap or pop3 process specified by mail_executable, ie an
lsof of the process shows cwd of /home/user and the automounted
home.
I see the same behaviour in 2.0.13, which process tracing of imap
shows more clearly (/nfs/user is per user mount, /nfs/home/user
is user home bundle)
This appears to be done (v2.0.13) in mail-storage-service.c in an attempt to
make sure core files are dumped into a user's home directory
if ((user-flags MAIL_STORAGE_SERVICE_FLAG_TEMP_PRIV_DROP) != 0
(user-flags MAIL_STORAGE_SERVICE_FLAG_ENABLE_CORE_DUMPS) == 0) {
/* we don't want to write core files to any users' home
directories since they could contain information about other
users' mails as well. so do no chdiring to home. */
} else if (*home != '\0'
(user-flags MAIL_STORAGE_SERVICE_FLAG_NO_CHDIR) == 0) {
/* If possible chdir to home directory, so that core file
could be written in case we crash. */
if (chdir(home) 0) {
... debug diagnostics ...
}
}
As to how to stop the mail process from chdir'ing to a home directory
rather than putting core files somewhere else, I don't know how to do it
without altering the source code or wrapping these processes in something
that alters the HOME environment variable.
I also can't find how user-flags sets MAIL_STORAGE_SERVICE_FLAG_NO_CHDIR or
MAIL_STORAGE_SERVICE_FLAG_ENABLE_CORE_DUMPS that could influence this
behaviour.
Joseph Tam jtam.h...@gmail.com
Re: [Dovecot] How to stop mail_executable from cwd to ~home
On 21.5.2011, at 10.51, Joseph Tam wrote: On Thu, 19 May 2011, I wrote: Gary Duncan gdun...@engr.uvic.ca writes: Works well except that dovecot still wants to cd to the real home triggering a useless and potentially hindering automount when it invokes the imap or pop3 process specified by mail_executable, ie an lsof of the process shows cwd of /home/user and the automounted home. I see the same behaviour in 2.0.13, which process tracing of imap shows more clearly (/nfs/user is per user mount, /nfs/home/user is user home bundle) This appears to be done (v2.0.13) in mail-storage-service.c in an attempt to make sure core files are dumped into a user's home directory That's one reason, yes. It's also needed when doing chrooting. And in general it's cleaner.. As to how to stop the mail process from chdir'ing to a home directory If you don't want Dovecot to use a home directory, don't tell it a home directory.
Re: [Dovecot] Dovecot stops with Fatal: kevent(): Invalid argument
On 21.5.2011, at 2.51, Henrik Larsson wrote: That patch doesn't fix anything. It only changes the error message to be more informative so I could figure out what is causing it. If you haven't seen any more errors, it's just a coincidence. I have for some reason not seen the error since applying the above patch. But wouldn't it make sense to include the patch in the stable release so others can give input in the rare case they experience the same issue? At least until the issue has been resolved. I don't say that this is a Dovecot issue, and I admit that it have to be a rare case, but when two independent people experience the same error, there have to be a problem somewhere. Is there a problem adding a patch like this to the stable code? Annoying to add ugly debug code for a problem that happens so rarely.. Should I ask the FreeBSD dovecot2 port maintainer to add it to the FreeBSD port instead? I wouldn't mind them adding it.
Re: [Dovecot] IMAP COMPRESS not announced while using imap_zlib plugin
On 21.5.2011, at 2.31, Henrik Larsson wrote: Is there any way I can see in the logs if IMAP COMPRESS is used? Not currently. Would be nice in the logout message I guess.
Re: [Dovecot] Global fields for passwd-file database
On 21.5.2011, at 10.23, Sergey Urushkin wrote:
And no hope it'll be implemented ever?
I guess a generic implementation could be added:
passdb {
# overridden by passdb entries
extra_fields_defaults = uid=1000 gid=1000
# these override the passdb entries
extra_fields_overrides = home=/home/%u
}
And the same for userdb. Although I don't really like those setting names.
Wonder if there are some better ones.
Re: [Dovecot] Behavior difference in mbox versus Maildir listing
On 21.5.2011, at 23.16, Bruno Prémont wrote: The resulting IMAPv4 session is: mb1 LIST #mbox.% * LIST (\Noselect \HasChildren) . #mbox.folder mb1 OK List completed. mb2 LIST #mbox.folder.% * LIST (\Noselect \HasChildren) . #mbox.folder. * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1a * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1b * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1c mb2 OK List completed. md1 LIST #maildir.% * LIST (\HasChildren) . #maildir.folder md1 OK List completed. md2 LIST #maildir.folder.% * LIST (\HasNoChildren) . #maildir.folder.folder1a * LIST (\HasNoChildren) . #maildir.folder.folder1b * LIST (\HasNoChildren) . #maildir.folder.folder1c md2 OK List completed. Notice the extra presence of listed folder itself with trailing . in mb2 that has no equivalent in md2! Is this expected listing behavior? If so, why the differing behavior between both storage engines? It's expected, although maybe not the best behavior. I'm basically copying UW-IMAP behavior for mbox and Courier/Cyrus behavior for Maildir. There are more detailed reasons for why the #mbox.folder. should be listed, which are described by Mark Crispin somewhere in imap-protocol mailing list archives I think. I've been thinking about making dbox and Maildir (and maybe mbox) behavior identical though..
[Dovecot] Behavior difference in mbox versus Maildir listing
Hi, My MUA (claws-mail) is having a hard time listing directories for a mail account with two namespaces, one of which using mbox and the other one using maildir to store mails. Let's call the namespaces #mbox. and #maildir. and have . as separator. Assume I have the following folder hierarchy: $namespace $namespace folder $namespace folder folder1a $namespace folder folder1b $namespace folder folder1c The resulting IMAPv4 session is: mb1 LIST #mbox.% * LIST (\Noselect \HasChildren) . #mbox.folder mb1 OK List completed. mb2 LIST #mbox.folder.% * LIST (\Noselect \HasChildren) . #mbox.folder. * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1a * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1b * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1c mb2 OK List completed. md1 LIST #maildir.% * LIST (\HasChildren) . #maildir.folder md1 OK List completed. md2 LIST #maildir.folder.% * LIST (\HasNoChildren) . #maildir.folder.folder1a * LIST (\HasNoChildren) . #maildir.folder.folder1b * LIST (\HasNoChildren) . #maildir.folder.folder1c md2 OK List completed. Notice the extra presence of listed folder itself with trailing . in mb2 that has no equivalent in md2! Is this expected listing behavior? If so, why the differing behavior between both storage engines? Affected dovecot versions: at least 1.1.16 and 2.0.11 (installed from Gentoo packages) System is x86 on XFS Thanks, Bruno signature.asc Description: PGP signature
Re: [Dovecot] Behavior difference in mbox versus Maildir listing
On Sat, 21 May 2011 Timo Sirainen t...@iki.fi wrote: On 21.5.2011, at 23.16, Bruno Prémont wrote: The resulting IMAPv4 session is: mb1 LIST #mbox.% * LIST (\Noselect \HasChildren) . #mbox.folder mb1 OK List completed. mb2 LIST #mbox.folder.% * LIST (\Noselect \HasChildren) . #mbox.folder. * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1a * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1b * LIST (\NoInferiors \UnMarked) . #mbox.folder.folder1c mb2 OK List completed. md1 LIST #maildir.% * LIST (\HasChildren) . #maildir.folder md1 OK List completed. md2 LIST #maildir.folder.% * LIST (\HasNoChildren) . #maildir.folder.folder1a * LIST (\HasNoChildren) . #maildir.folder.folder1b * LIST (\HasNoChildren) . #maildir.folder.folder1c md2 OK List completed. Notice the extra presence of listed folder itself with trailing . in mb2 that has no equivalent in md2! Is this expected listing behavior? If so, why the differing behavior between both storage engines? It's expected, although maybe not the best behavior. I'm basically copying UW-IMAP behavior for mbox and Courier/Cyrus behavior for Maildir. There are more detailed reasons for why the #mbox.folder. should be listed, which are described by Mark Crispin somewhere in imap-protocol mailing list archives I think. I've been thinking about making dbox and Maildir (and maybe mbox) behavior identical though.. Hm, at least claws-mail (it uses libetpan) does not survive listing the #mbox namespace here, it loops listing the same folder until it crashes. The mbox behavior must have changed during 1.1.* series as some time ago I could refresh the folder list (unless claws-mail/libetpan changed their approach of listing folders recently) Reporting bug over there as crashing/infinite-looping MUA is bad. If you have a pointer to the detailed reasons for the differing behavior I would appreciate so I could add it to the bug report. Thanks, Bruno signature.asc Description: PGP signature
Re: [Dovecot] Behavior difference in mbox versus Maildir listing
On 21.5.2011, at 23.35, Bruno Prémont wrote: It's expected, although maybe not the best behavior. I'm basically copying UW-IMAP behavior for mbox and Courier/Cyrus behavior for Maildir. There are more detailed reasons for why the #mbox.folder. should be listed, which are described by Mark Crispin somewhere in imap-protocol mailing list archives I think. I've been thinking about making dbox and Maildir (and maybe mbox) behavior identical though.. Hm, at least claws-mail (it uses libetpan) does not survive listing the #mbox namespace here, it loops listing the same folder until it crashes. Well, then I'd think it always crashes when listing mailboxes with UW-IMAP? If not, it has some special UW-IMAP specific crash-avoidance code.. If you have a pointer to the detailed reasons for the differing behavior I would appreciate so I could add it to the bug report. Well, one such link is http://marc.info/?l=imapm=104561252904979w=2 but there are probably better.
Re: [Dovecot] Behavior difference in mbox versus Maildir listing
On Sat, 21 May 2011 Timo Sirainen t...@iki.fi wrote: On 21.5.2011, at 23.35, Bruno Prémont wrote: It's expected, although maybe not the best behavior. I'm basically copying UW-IMAP behavior for mbox and Courier/Cyrus behavior for Maildir. There are more detailed reasons for why the #mbox.folder. should be listed, which are described by Mark Crispin somewhere in imap-protocol mailing list archives I think. I've been thinking about making dbox and Maildir (and maybe mbox) behavior identical though.. Hm, at least claws-mail (it uses libetpan) does not survive listing the #mbox namespace here, it loops listing the same folder until it crashes. Well, then I'd think it always crashes when listing mailboxes with UW-IMAP? If not, it has some special UW-IMAP specific crash-avoidance code.. Don't know if it has heuristics (grepping whole source e.g. for UW-IMAP yields not hit) but it proceeds as one would expect when separator is '/' instead of '.'... (going to check with another separator char just to see!) If you have a pointer to the detailed reasons for the differing behavior I would appreciate so I could add it to the bug report. Well, one such link is http://marc.info/?l=imapm=104561252904979w=2 but there are probably better. Ok, so this would mean that the Maildir storage should also list the parent folder as is done for mbox? If other MTAs show trouble it might be worth having a config flag in dovecot tell if parent folder should be listed or not (for all engines)... Bruno signature.asc Description: PGP signature
Re: [Dovecot] fts squat index file not appearing
On 5/20/2011 1:37 PM, Timo Sirainen wrote:
On 20.5.2011, at 23.33, Daniel L. Miller wrote:..
protocol imap {
mail_plugins = fts fts_squat imap_zlib zlib
}
You've enabled fts for imap protocol, nothing else. Same with zlib, which can
cause trouble. Make them global:
mail_plugins = fts fts_squat zlib
protocol imap {
mail_plugins = $mail_plugins imap_zlib
}
Amazing - that works! Now...WHY does that work?! I thought I was doing
the RIGHT thing by using the individual protocol plugin variables - not
including plugins in areas that I THOUGHT were unnecessary.
If there are plugins that need to be global (and there obviously are) -
please indicate so in the wiki.
--
Daniel
[Dovecot] fts crash
I've completed my mailbox rebuild - theoretically I should be free of corruption. I used dsync to export from mdbox to maildir (so should be clean) then used a virtual machine with Dovecot to import back to mdbox in another location. So...theoretically I should be free of all corruption now... Running an fts update - doveadm search text -u u...@domain.com xyzzyx works on some users - other mailboxes crash with: doveadm(dmil...@amfes.com): Panic: file squat-trie.c: line 876 (squat_build_word): assertion failed: (i + bytelen = size) doveadm(dmil...@amfes.com): Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x3ccca) [0x7ffee92b6cca] - /usr/local/lib/dovecot/libdovecot.so.0(default_fatal_handler+0x32) [0x7ffee92b6db2] - /usr/local/lib/dovecot/libdovecot.so.0(+0x16dda) [0x7ffee9290dda] - /usr/local/lib/dovecot/lib21_fts_squat_plugin.so(+0x5bbd) [0x7ffee6607bbd] - /usr/local/lib/dovecot/lib21_fts_squat_plugin.so(squat_trie_build_more+0x153) [0x7ffee6607d13] - /usr/local/lib/dovecot/lib20_fts_plugin.so(+0x59bc) [0x7ffee68159bc] - /usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x20) [0x7ffee99ac180] - /usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next+0x26) [0x7ffee99ac1d6] - doveadm() [0x40ce47] - doveadm() [0x409304] - doveadm(doveadm_mail_single_user+0x8c) [0x40961c] - doveadm() [0x409817] - doveadm(doveadm_mail_try_run+0x141) [0x409c31] - doveadm(main+0x3b1) [0x40dfd1] - /lib/libc.so.6(__libc_start_main+0xfe) [0x7ffee8b09d8e] - doveadm() [0x408c09] Aborted -- Daniel
Re: [Dovecot] fts crash
On 5/21/2011 8:04 PM, Daniel L. Miller wrote: I've completed my mailbox rebuild - theoretically I should be free of corruption. I used dsync to export from mdbox to maildir (so should be clean) then used a virtual machine with Dovecot to import back to mdbox in another location. So...theoretically I should be free of all corruption now... Perhaps I spoke too soon... May 21 20:13:38 bubba dovecot: imap(emil...@amfes.com): Error: FETCH [] for mailbox INBOX UID 1274 got too little data: 4443 vs 5253 May 21 20:13:38 bubba dovecot: imap(emil...@amfes.com): Error: Corrupted index cache file /var/mail/amfes.com/emiller/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache: Broken virtual size for mail UID 1274 May 21 20:13:38 bubba dovecot: imap(emil...@amfes.com): Disconnected: FETCH failed bytes=103/5395 -- Daniel
Re: [Dovecot] fts crash
On 5/21/2011 8:17 PM, Daniel L. Miller wrote: On 5/21/2011 8:04 PM, Daniel L. Miller wrote: I've completed my mailbox rebuild - theoretically I should be free of corruption. I used dsync to export from mdbox to maildir (so should be clean) then used a virtual machine with Dovecot to import back to mdbox in another location. So...theoretically I should be free of all corruption now... Perhaps I spoke too soon... May 21 20:13:38 bubba dovecot: imap(emil...@amfes.com): Error: FETCH [] for mailbox INBOX UID 1274 got too little data: 4443 vs 5253 May 21 20:13:38 bubba dovecot: imap(emil...@amfes.com): Error: Corrupted index cache file /var/mail/amfes.com/emiller/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache: Broken virtual size for mail UID 1274 May 21 20:13:38 bubba dovecot: imap(emil...@amfes.com): Disconnected: FETCH failed bytes=103/5395 Note that the above logged error appears from a MUA accessing the mailbox - no log entries from a doveadm search text command. -- Daniel
Re: [Dovecot] Crash test :)
Timo Sirainen t...@iki.fi writes: On 21.5.2011, at 1.21, Kamil Jońca wrote: 2. when I move dbox-Mails to proper place I got: doveadm(kjonca): Error: sdbox /home/kjonca/Mail/dbox-temp/spamcop/reports/mailboxes/INBOX/dbox-Mails: Invalid dbox header size What Dovecot version? I think this is fixed already. Um. :( Files were created about 2 months ago. It was certainly 1.x, but now it is hard to say, what exactly version it was. But question is open: Can I (and how) restore mails from so old backup? Dovecot v2.0 should be able to read v1.x's dbox files. If it can, it can restore the backups. The only difference I can think of is that in some version I changed the default to have dbox save everything under mailboxes/ directory. If your backups don't use that directory, you can use something like: doveadm import sdbox:~/Mail/dbox-temp:MAILBOXDIR= #Dbox mailbox spamcop/reports Unfortunately neither debian 2.0.12 nor 2.0.13 version can import these. Strange thing is that message Invalid dbox header size is printed after creating dovecot-uidvalidity and dovecot-index* files for source dbox, u.* files are not read at all. KJ -- http://blogdebart.pl/2010/03/17/dalsze-przygody-swinki-w-new-jersey/ Nie można wlecieć w trzecie tysiaclecie na drzwiach od stodoły - biskup polowy WP Sławoj Leszek Głódź.
[Dovecot] hardluck w/ sieve
I've followed the docs here:
http://wiki.dovecot.org/LDA/Sieve/Dovecot
... in particular, the 'Per-user Sieve script location' scenario.
However, I'm unable to get any behavior that indicates that
sieve is functioning correctly - well, functioning _at_all_ would
be more accurate.
Relevant dovecot.conf:
protocol lda {
...
mail_plugins = sieve
}
auth default {
...
passdb passwd-file {
args = /var/vmail/passwd
}
userdb static {
args = uid=vmail gid=vmail home=/var/vmail/%d/%u
}
}
plugin {
sieve = /var/sieve-scripts/%d/%u.sieve
}
ls -l /var/sieve-scripts/domain.com/user.sieve
-rw-r--r-- 1 vmail vmail 224 May 22 00:18 /var/sieve-scripts/domain/user.sieve
I of course have an extremely simple rule in the example 'user.sieve' file; but
for whatever reasons, no filtering is occurring.
Is there anything obvious in my configuration that's broke? How best to
debug?
Thankyou!
