Re: [Dovecot] Coredump using virtual folder.
Hello,
On Wed, 8 Apr 2009, Timo Sirainen wrote:
On Wed, 2009-04-08 at 18:46 +0200, Matthias Rieber wrote:
I guess x-references2 has been renamed to refs. When I'm using I that, I
got a coredump again:
[New process 24135]
#0 0x080a3038 in index_header_lookup_init (box=0x9b05d28, headers=0x0) at
index-mail-headers.c:864
864 i_assert(*headers != NULL);
(gdb) bt
Fixed this and another bug:
http://hg.dovecot.org/dovecot-1.2/rev/e5633843c336
it partly fixes the bug. When I access the folder for the first time it
works now.
I've a virtual folder 'unseen' and one 'keyword'. When I mark some mails
seen that are in the search folders of unseen and I access the folder
unseen, the status will be updated and the messages disappear. So far so
good, but when I access the keyword folder, I get a coredump again:
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
[New process 22081]
#0 0x080a542b in search_index_arg (arg=0x973da68, ctx=0xa13b140) at
index-search.c:123
123 for (i = 0; i < search_kws->count; i++) {
(gdb) bt
#0 0x080a542b in search_index_arg (arg=0x973da68, ctx=0xa13b140) at
index-search.c:123
#1 0x080b0ea2 in search_arg_foreach (arg=0x973da68, callback=0x80a52e0
, context=0xa13b140) at mail-search.c:316
#2 0x080b0ff0 in mail_search_args_foreach (args=0x973da68, callback=0x80a52e0
, context=0xa13b140) at mail-search.c:329
#3 0x080a528a in index_storage_search_next_update_seq (_ctx=0xa13b140) at
index-search.c:1266
#4 0xb7f64666 in fts_mailbox_search_next_update_seq (ctx=0xa13b140) at
fts-storage.c:683
#5 0x080a5544 in index_storage_search_next_nonblock (_ctx=0xa13b140,
mail=0xa13b2b0, tryagain_r=0xbfaccbbb) at index-search.c:1189
#6 0xb7f64f02 in fts_mailbox_search_next_nonblock (ctx=0xa13b140,
mail=0xa13b2b0, tryagain_r=0xbfaccbbb) at fts-storage.c:631
#7 0x080b3d4d in mailbox_search_next_nonblock (ctx=0xa13b140, mail=0xa13b2b0,
tryagain_r=0xbfaccbbb) at mail-storage.c:751
#8 0x080b3da8 in mailbox_search_next (ctx=0xa13b140, mail=0xa13b2b0) at
mail-storage.c:737
#9 0x080af66a in index_search_result_update_flags (result=0xa139ff8,
changes=0xbfacce64) at index-search-result.c:78
#10 0xb7f5cd16 in virtual_storage_sync_init (box=0x97399d0, flags=65) at
virtual-sync.c:677
#11 0x080b3b02 in mailbox_sync (box=0x0, flags=65, status_items=239,
status_r=0xbfaccf48) at mail-storage.c:574
#12 0x08064708 in cmd_select_full (cmd=0x9731240, readonly=false) at
cmd-select.c:273
#13 0x08064e69 in cmd_select (cmd=0x9731240) at cmd-select.c:388
#14 0x0806700c in client_command_input (cmd=0x9731240) at client.c:603
#15 0x080670a9 in client_command_input (cmd=0x9731240) at client.c:652
#16 0x080676ed in client_handle_input (client=0x9730fb0) at client.c:693
#17 0x08067ba3 in client_input (client=0x9730fb0) at client.c:748
#18 0x080f7390 in io_loop_handler_run (ioloop=0x972c9b0) at ioloop-epoll.c:208
#19 0x080f6820 in io_loop_run (ioloop=0x972c9b0) at ioloop.c:338
#20 0x080704c5 in main (argc=Cannot access memory at address 0x0) at main.c:320
When I delete the dovecot.index.* files in the virtual folder it works
again, till the unseen messages change.
regards,
matthias
Re: [Dovecot] Upgrade from 0.99.x to 1.1.x
On Wed, 2009-04-08 at 15:32 +0200, Anders Melchiorsen wrote: > Wolfram Schlich wrote: > > > Do I understand it correctly that when directly upgrading from > > 0.99 to 1.1, Dovecot does the subscriptions renaming but not the > > keywords renaming and conversion, but that when I manually rename > > all .customflags files to dovecot-keywords, it does the format > > conversion of that file automatically? > > Yes, that is correct. I did this same conversion about a year ago: > > http://www.dovecot.org/list/dovecot/2008-March/029325.html > > > Is there anything else what's important to note for such an upgrade? > > I do not remember any big problems with the conversion. However, lots of > small problems with Dovecot just disappeared when getting rid of 0.99 ... > For what it's worth I am gradually moving users from an old 0.99 install to a new 1.1 install and there have been no problems as long as the subscriptions file is renamed. We deleted the other superseded files as they weren't required in our case. Karl.
Re: [Dovecot] different auth config for LDA
Timo Sirainen wrote: deliver doesn't use base_dir at all. Hmmm...looks like it came about due to needing a different authentication configuration between IMAP and deliver, which led to a different auth process and necessitated a separate base_dir. The two run directories are clearly different, and both used: /var/run/dovecot: auth-worker.25176= dict-server=login/ master.pid /var/run/dovecot-deliver: auth-master=auth-worker.13452= dict-server=login/ master.pid Perhaps there's a way to do that within a single config file. -Tom
[Dovecot] crashed with shared namespace
Hi,
I have a shared namespace, which works fine yesterday. Today I have just
updated my dovecot to the newest from hg.dovecot.org, and it crashed
when list the shared namespace.
namespace shared {
separator = /
prefix = shared/%%u/
location= maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u
list= children
subscriptions = no
}
cmd:
# telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS
AUTH=PLAIN AUTH=LOGIN] AMOS READY
a1 login te...@xueron.com **
a1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT
THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE
UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES
WITHIN CONTEXT=SEARCH ACL RIGHTS=texk] Logged in
a1 list "" "*"
* LIST (\HasNoChildren) "/" "Sent"
* LIST (\HasNoChildren) "/" "Spam"
* LIST (\HasChildren) "/" "virtual"
* LIST (\HasChildren) "/" "a"
* LIST (\HasNoChildren) "/" "a/aaa"
* LIST (\HasNoChildren) "/" "Junk"
* LIST (\HasNoChildren) "/" "Draft"
* LIST (\HasNoChildren) "/" "Trash"
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\Noselect \HasChildren) "/" "shared/xue...@xueron.com"
* LIST (\HasNoChildren) "/" "public/test2"
* LIST (\HasNoChildren) "/" "public/test4"
* LIST (\HasNoChildren) "/" "public/test1"
* LIST (\HasNoChildren) "/" "public/test3"
* LIST (\HasChildren) "/" "shared/xue...@xueron.com/mydir"
* LIST (\HasNoChildren) "/" "shared/xue...@xueron.com/mydir/subdir"
* LIST (\HasNoChildren) "/" "shared/xue...@xueron.com/newdir"
a1 OK List completed.
a1 list "shared/" "*"
Connection closed by foreign host.
maillog:
Apr 9 12:31:27 mail dovecot: Panic: IMAP(te...@xueron.com): file
mail-user.c: line 30 (mail_user_init): assertion failed: (*username !=
'\0')
Apr 9 12:31:27 mail dovecot: IMAP(te...@xueron.com): Raw backtrace:
imap [0x80e7800] -> imap [0x80e785a] -> imap [0x80e711c] -> imap
[0x80af7ab] -> imap(shared_storage_get_namespace+0x298) [0x8072708] ->
imap [0x8071eef] -> imap [0x80601ec] -> imap(cmd_list_full+0x4ad)
[0x8060bcd] -> imap(cmd_list+0x19) [0x8060ec9] -> imap [0x8063f9c] ->
imap [0x806404b] -> imap(client_handle_input+0x2f) [0x8064aff] ->
imap(client_input+0x63) [0x8064d33] -> imap(io_loop_handler_run+0x107)
[0x80effc7] -> imap(io_loop_run+0x28) [0x80ef0d8] -> imap(main+0x754)
[0x806d044] -> /lib/libc.so.6(__libc_start_main+0xdc) [0x901dec] -> imap
[0x805cf11]
Apr 9 12:31:27 mail dovecot: child 14971 (imap) killed with signal 6 (core
dumps disabled
btw:
yesterday, there was such logs when 'list "shared/" "*"':
Apr 8 17:03:37 mail dovecot: IMAP(te...@xueron.com): Invalid namespace
prefix %u/ vs
but no crash.
Thanks :)
--
Xueron Nee
http://www.xueron.com
Re: [Dovecot] deliver vs lda
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {}
section. This is getting annoying, any thoughts on what would be a good
unifying name?
c) dovecot-lda binary, protocol lda {}
I'm in favor of this ... outside of dovecot, explicitly saying dovecot is
important, whereas inside the config file, it's implicit we're talking about
Dovecot's LDA.
dovecot-lda also fits with the dovecot-auth precedent. Of course, saying
"dovecot-imap-login" is getting a bit too verbose :P
--
Curtis Maloney
cmalo...@cardgate.net
[Dovecot] why not install utils (idxview logview ...) with dovecot in bin/sbin dir?
Hi, I just found these useful tools :) they were installed in libexec dir :) -- Xueron Nee http://www.xueron.com
Re: [Dovecot] deliver vs lda
On Wed, 2009-04-08 at 19:32 -0400, Tom Metro wrote: > I found the combination of configuration for IMAP and LDA to be a bit > unnatural as well, with little to no overlap between the two. And so I > ended up splitting them up so that I could have each logging to > different places (IMAP to its own file, as it doesn't relate to mail > delivery), and their own base_dir. deliver doesn't use base_dir at all. Anyway the main problem I see with that setup is if you change some mail-related setting you might not remember to change it in both files. This is especially bad if you change a locking related setting. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] deliver vs lda
Daniel L. Miller wrote:
"deliver" has nothing to do with the listening daemons. So having the
"lda" configuration in the dovecot.conf file might be inappropriate - I
would suggest splitting that off to a "dovecot-lda.conf" file (or
whatever you change the delivery agent name to).
I found the combination of configuration for IMAP and LDA to be a bit
unnatural as well, with little to no overlap between the two. And so I
ended up splitting them up so that I could have each logging to
different places (IMAP to its own file, as it doesn't relate to mail
delivery), and their own base_dir.
I also created a separate init script (or more accurately, modified the
stock Debian init script so that I cold symlink to it, and it would load
a matching config from /etc/defaults to get the non-default config file
used by deliver).
Timo Sirainen wrote:
...inside protocol lda {} it can also override all settings from
dovecot.conf.
I might not have been aware of that at the time I set up deliver, or ran
into complications with it. I don't recall. In any case, I prefer the
logical separation. Delivery and access are related, but still quite
separate functions.
-Tom
Re: [Dovecot] Multiple use of the same LDAP attribute
Daniel L. Miller wrote: > I'll admit I don't understand what you're trying to do with the above > parameters, but let me share what I'm using and see if it helps. I > happen to be using a pure virtual configuration, with my mail users > logging in using their full email address as a username. So all I need > to store in LDAP is the email address and the password. This is the difference, here they can login either with their full email address (also aliases) or with their internal userid (which is 16 char hex). The home directory is derived from the latter, but since they can also login with the mailaddress I can't use anything from the supplied username to set the directory/mail location. Bernhard
Re: [Dovecot] Trying nonplaintext mech with LDAP password-hash
Hello Timo,
An mer., avr 08, 2009, Timo Sirainen schrieb:
>On Thu, 2009-04-09 at 00:31 +0200, dovecotl...@encambio.com wrote:
>> I've already verified that this works correctly with plaintext
>> (CLEARTEXT in slapd.conf), but I really want to store the passwords
>> in LDAP using some hash. Why doesn't LDAP-MD5 work as advertised?
>
>Because it's impossible to support it. Read
>http://wiki.dovecot.org/Authentication/Mechanisms
>
>> What did the author mean by 'properly hashed passwords'? Thanks.
>
>I made it a link now to
>http://wiki.dovecot.org/Authentication/PasswordSchemes#Non-plaintext_authentication_mechanisms
>
The new text clears up the confusion. Before, it sounded as at least
CRAM-MD5 could be implemented with MD5 encoded password stoarge. I
suppose if LDAP could store passwords in CRAM-MD5 format (whatever
that is) then this goal would be achievable. Reading slapd.conf(5),
it seems LDAP can only store {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT},
and {CLEARTEXT}. It's probably in the RFC, and CRAM-MD5 is missing
from the list.
How sad.
--
Eduard
Re: [Dovecot] Trying nonplaintext mech with LDAP password-hash
On Thu, 2009-04-09 at 00:31 +0200, dovecotl...@encambio.com wrote: > I've already verified that this works correctly with plaintext > (CLEARTEXT in slapd.conf), but I really want to store the passwords > in LDAP using some hash. Why doesn't LDAP-MD5 work as advertised? Because it's impossible to support it. Read http://wiki.dovecot.org/Authentication/Mechanisms > What did the author mean by 'properly hashed passwords'? Thanks. I made it a link now to http://wiki.dovecot.org/Authentication/PasswordSchemes#Non-plaintext_authentication_mechanisms signature.asc Description: This is a digitally signed message part
Re: [Dovecot] deliver vs lda
On Thu, 2009-04-09 at 08:29 +1000, Noel Butler wrote: > > Another thing I was thinking about previously was that in process lists > > they were prefixed with dovecot/. So the binary names could be lda, > > imap-login, etc. but they'd show up in process lists as dovecot/lda, > > dovecot/imap-login, etc. > > > > > seems like more work for no reason, just call the binary dovecot-lda > etc, makes it easier if you get someone not familiar with dovecot trying > to locate it, having a temper tantrum with dovecot-lda showing up but > unable to locate that binary :) If I used dovecot/lda process name, then there would be $lib/dovecot/lda binary also, not dovecot-lda. signature.asc Description: This is a digitally signed message part
[Dovecot] Trying nonplaintext mech with LDAP password-hash
Hello List,
The only passdb block in /pfx/etc/dovecot/dovecot.conf is:
passdb ldap {
args = /pfx/etc/dovecot/dovecot-ldap.conf
}
In /pfx/etc/dovecot/dovecot-ldap.conf:
auth_bind = no
dn = cn=mymgr,dc=host,dc=tld
dnpass =
default_pass_scheme = LDAP-MD5
In /pfx/etc/openldap/slapd.conf:
password-hash {MD5}
If I try:
$ /pfx/bin/ldapsearch <...> \
| grep '^userPassword' \
| sed -e 's;.*:: \(.*\)$;\1;' \
| mimencode -u
...I get the correct password (MD5 hashed.)
According to wiki.dovecot.org/AuthDatabase/LDAP/PasswordLookups this
should work, and indeed when starting dovecot it does not complain
about:
'CRAM-MD5 mechanism can't be supported with given passdbs'
Instead it starts right up, but when a thunderbird client
connects and tries authenticating with CRAM-MD5 it fails.
In the wiki page 'PasswordLookups' it mentions:
Supports non-plaintext authentication mechanisms (if
returning plaintext/properly hashed passwords).
I've already verified that this works correctly with plaintext
(CLEARTEXT in slapd.conf), but I really want to store the passwords
in LDAP using some hash. Why doesn't LDAP-MD5 work as advertised?
What did the author mean by 'properly hashed passwords'? Thanks.
--
Eduard
Re: [Dovecot] Coredump using virtual folder.
On Thu, 2009-04-09 at 00:09 +0200, Matthias Rieber wrote: > INBOX > INBOX.Some.Folder.* > KEYWORD $MAILING .. > #5 0x080b1def in mail_search_args_init_sub (args=0x9eee200, arg=0x9eee220, > change_uidsets=false, search_saved_uidset=0x0) at mail-search.c:86 > #6 0xb7f8f7e3 in virtual_storage_sync_init (box=0x9eea188, flags=65) at > virtual-sync.c:451 This fixes it (and hopefully doesn't break anything else..): http://hg.dovecot.org/dovecot-1.2/rev/99ecc7f748a8 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] deliver vs lda
On Thu, 2009-04-09 at 08:05, Timo Sirainen wrote: > Another thing I was thinking about previously was that in process lists > they were prefixed with dovecot/. So the binary names could be lda, > imap-login, etc. but they'd show up in process lists as dovecot/lda, > dovecot/imap-login, etc. > seems like more work for no reason, just call the binary dovecot-lda etc, makes it easier if you get someone not familiar with dovecot trying to locate it, having a temper tantrum with dovecot-lda showing up but unable to locate that binary :) It seems most the consensus is with option C which makes most sense. <>
Re: [Dovecot] deliver vs lda
Timo Sirainen wrote:
On Wed, 2009-04-08 at 14:38 -0700, Daniel L. Miller wrote:
Having a consistent name prefix for all the processes sounds nice - but
then you'd stick out as the exception to typical multi-process server
names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing
to deviate from accepted (poor) practices? Hmm
Other tradeoffs...more space consumed in logfiles. More screen width
consumed during listings. Not necessarily a Good Thing - not
necessarily a Bad Thing. But something to ponder on.
No, I wouldn't write the dovecot- prefix to log files. So while the
binary names would be dovecot-lda, dovecot-imap-login, etc. the logs
would contain only lda(user), imap-login(user), etc.
So the process name won't match the name in the log file? That sounds
like a Bad Thing.
Another thing I was thinking about previously was that in process lists
they were prefixed with dovecot/. So the binary names could be lda,
imap-login, etc. but they'd show up in process lists as dovecot/lda,
dovecot/imap-login, etc.
That I like.
I would also consider the Dovecot architecture. As I (mis)understand
it, the "dovecot" process spawns the necessary imap, pop3, and login
daemons. So having a "dovecot.conf" file for controlling these is quite
appropriate. However, unless I've missed something (quite likely) -
"deliver" has nothing to do with the listening daemons. So having the
"lda" configuration in the dovecot.conf file might be inappropriate - I
would suggest splitting that off to a "dovecot-lda.conf" file (or
whatever you change the delivery agent name to).
But deliver also reads dovecot.conf and inside protocol lda {} it can
also override all settings from dovecot.conf. So I don't really like the
idea of splitting the configuration. Also in v1.3+ the only thing that
reads dovecot.conf is doveconf binary, master and deliver and everything
else get their configuration from it.
Told you I didn't know what I was talking about!
--
Daniel
Re: [Dovecot] Coredump using virtual folder.
On Wed, 2009-04-08 at 18:46 +0200, Matthias Rieber wrote: > I guess x-references2 has been renamed to refs. When I'm using I that, I > got a coredump again: > > [New process 24135] > #0 0x080a3038 in index_header_lookup_init (box=0x9b05d28, headers=0x0) at > index-mail-headers.c:864 > 864 i_assert(*headers != NULL); > (gdb) bt Fixed this and another bug: http://hg.dovecot.org/dovecot-1.2/rev/e5633843c336 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Indexing of mails to speed up the IMAP SEARCH command
Nevermind, stupid question. I found it on the squat page. ;) David Halik wrote: Timo Sirainen wrote: For message body indexing there are a couple of choices: http://wiki.dovecot.org/Plugins/FTS Just curious, what is the average disk usage for FTS? I know it's usually around 10-15% of an inbox for standard indexing. I'm assuming FTS is considerably more. -- David Halik System Administrator OIT-CSS Rutgers University dha...@jla.rutgers.edu
Re: [Dovecot] Indexing of mails to speed up the IMAP SEARCH command
Timo Sirainen wrote: For message body indexing there are a couple of choices: http://wiki.dovecot.org/Plugins/FTS Just curious, what is the average disk usage for FTS? I know it's usually around 10-15% of an inbox for standard indexing. I'm assuming FTS is considerably more. -- David Halik System Administrator OIT-CSS Rutgers University dha...@jla.rutgers.edu
Re: [Dovecot] Indexing of mails to speed up the IMAP SEARCH command
On Wed, 2009-04-08 at 21:09 +0200, Tassilo Horn wrote: > I use a local dovecot server which is synchronized with my two imap > accounts using OfflineIMAP. This works very nice and is highly usable. > > But one thing I'd like to improve is the slow IMAP search. When I > search for a string in the subjects of all messages in a mailbox using > some mail client, dovecot seems to grep all the messages in there. Subject (or any other header) search should be fast, at least after the first one. The subjects should then (if not before) be stored in dovecot.index.cache file, and the search should be over in less than a second even with tens of thousands of messages. If this isn't happening with you, something's wrong. What Dovecot version are you using? For message body indexing there are a couple of choices: http://wiki.dovecot.org/Plugins/FTS signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Coredump using virtual folder.
Hi, another backtrace: dovecot-virtual: INBOX INBOX.Some.Folder.* KEYWORD $MAILING Core was generated by `imap'. Program terminated with signal 6, Aborted. [New process 20853] #0 0xb7fbe556 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7fbe556 in raise () from /lib/libc.so.6 #1 0xb7fbfd78 in abort () from /lib/libc.so.6 #2 0x080ee9a5 in default_fatal_finish (type=, status=0) at failures.c:161 #3 0x080eea12 in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=0x810632c "file %s: line %d (%s): assertion failed: (%s)", args=0xbf9f6b54 "\002") at failures.c:441 #4 0x080ee399 in i_panic (format=0x810632c "file %s: line %d (%s): assertion failed: (%s)") at failures.c:208 #5 0x080b1def in mail_search_args_init_sub (args=0x9eee200, arg=0x9eee220, change_uidsets=false, search_saved_uidset=0x0) at mail-search.c:86 #6 0xb7f8f7e3 in virtual_storage_sync_init (box=0x9eea188, flags=65) at virtual-sync.c:451 #7 0x080b3b12 in mailbox_sync (box=0x5175, flags=65, status_items=239, status_r=0xbf9f6e88) at mail-storage.c:574 #8 0x08064708 in cmd_select_full (cmd=0x9ee19f8, readonly=false) at cmd-select.c:273 #9 0x08064e69 in cmd_select (cmd=0x9ee19f8) at cmd-select.c:388 #10 0x0806700c in client_command_input (cmd=0x9ee19f8) at client.c:603 #11 0x080670a9 in client_command_input (cmd=0x9ee19f8) at client.c:652 #12 0x080676ed in client_handle_input (client=0x9ee1768) at client.c:693 #13 0x08067ba3 in client_input (client=0x9ee1768) at client.c:748 #14 0x080f73a0 in io_loop_handler_run (ioloop=0x9edd9b0) at ioloop-epoll.c:208 #15 0x080f6830 in io_loop_run (ioloop=0x9edd9b0) at ioloop.c:338 #16 0x080704c5 in main (argc=Cannot access memory at address 0x5175) at main.c:320 regards, matthias
Re: [Dovecot] deliver vs lda
On Wed, 2009-04-08 at 14:38 -0700, Daniel L. Miller wrote:
> Having a consistent name prefix for all the processes sounds nice - but
> then you'd stick out as the exception to typical multi-process server
> names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing
> to deviate from accepted (poor) practices? Hmm
>
> Other tradeoffs...more space consumed in logfiles. More screen width
> consumed during listings. Not necessarily a Good Thing - not
> necessarily a Bad Thing. But something to ponder on.
No, I wouldn't write the dovecot- prefix to log files. So while the
binary names would be dovecot-lda, dovecot-imap-login, etc. the logs
would contain only lda(user), imap-login(user), etc.
Another thing I was thinking about previously was that in process lists
they were prefixed with dovecot/. So the binary names could be lda,
imap-login, etc. but they'd show up in process lists as dovecot/lda,
dovecot/imap-login, etc.
> I would also consider the Dovecot architecture. As I (mis)understand
> it, the "dovecot" process spawns the necessary imap, pop3, and login
> daemons. So having a "dovecot.conf" file for controlling these is quite
> appropriate. However, unless I've missed something (quite likely) -
> "deliver" has nothing to do with the listening daemons. So having the
> "lda" configuration in the dovecot.conf file might be inappropriate - I
> would suggest splitting that off to a "dovecot-lda.conf" file (or
> whatever you change the delivery agent name to).
But deliver also reads dovecot.conf and inside protocol lda {} it can
also override all settings from dovecot.conf. So I don't really like the
idea of splitting the configuration. Also in v1.3+ the only thing that
reads dovecot.conf is doveconf binary, master and deliver and everything
else get their configuration from it.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] deliver vs lda
On mer., avr 08, 2009, Daniel L. Miller wrote:
> Timo Sirainen wrote:
>> deliver is the binary name. but it's configured inside protocol lda {}
>> section. This is getting annoying, any thoughts on what would be a good
>> unifying name?
>>
>> a) deliver binary, protocol deliver {}
>>
>> b) lda binary, protocol lda {}
>>
>> c) dovecot-lda binary, protocol lda {}
>>
>> d) mda binary, protocol mda {}
>>
>> e) dovecot-mda binary, protocol mda {}
>>
>> f) something else?
>>
>> In any case protocol lda {} would work for a while longer for backwards
>> compatibility.
>>
>> c) and e) choices also makes me think if e.g. imap and imap-login should
>> be called dovecot-imap and dovecot-imap-login instead. People have had
>> trouble finding them since ps|grep dovecot doesn't find them..
>>
>>
I like option c as well, however I don't like the idea of three
level binary and process names dovecot-this-that. Hopefully a
better solution to the imap/imap-login missing 'dovecot' will
be found.
--
Eduard
Re: [Dovecot] Multiple use of the same LDAP attribute
Bernhard Schmidt wrote:
On Wed, Apr 08, 2009 at 12:41:17PM -0400, Timo Sirainen wrote:
Of course there are several viable workarounds
(base mail location on home directory,
Come to think of it, any hint how I can implement the existing scheme?
user_attrs =
xxxMailbox=mail=maildir:/home/mailstore/%U$/Maildir:INDEX=/home/mailstore/indexes/%1U$/%U$,
xxxMailbox=home=/home/mailstore/%U$
the maildir location is easy (mail=maildir:~/Maildir), but the index is
hard, as I don't have the userid in any variable.
The only thing I can come up with atm is
user_attrs =
xxxMailbox=home=/home/mailstore/%U$,
xxxMailbox=mail=maildir:~/Maildir:INDEX=/home/mailstore/indexes/%16.1h/%16.99h
but I'm willing to bet that this is going to break at some point, the
latest point being when someone changes the mailstore path and forgets
to update the offset :-\
What happens when the width is larger than the length of the string
anyway?
Bernhard
I'll admit I don't understand what you're trying to do with the above
parameters, but let me share what I'm using and see if it helps. I
happen to be using a pure virtual configuration, with my mail users
logging in using their full email address as a username. So all I need
to store in LDAP is the email address and the password.
dovecot-ldap.conf
user_attrs = maildir:%d/%n/Maildir=mail,%d/%n=home
pass_attrs = mail=user,userPassword=password
dovecot.conf
[...]
mail_location = maildir:/var/mail/%d/%n/Maildir
[...]
userdb static {
args = uid=vmail gid=vmail home=/var/mail/%d/%n
mail=maildir:/var/mail/%d/%n allow_all_users=yes
}
[...]
This lets me store all mail under /var/mail/DOMAIN/USER/Maildir - with a
home of /var/mail/DOMAIN/USER.
I'm pretty sure at least some of the parameters I'm using are redundant
or unused, but thus far it works great.
--
Daniel
Re: [Dovecot] deliver vs lda
Eduardo M KALINOWSKI wrote: Charles Marcus wrote: heh... well, they would soon enough... Seriously though... why call it a 'local delivery agent', when its really more than that? Local suggests local/system users, and dovecot delivery agent works fine for both local and virtual users. Postfix calls its local delivery agent 'local', and its virtual delivery agent 'virtual' It's local because it stores e-mails somewhere in the local filesystem hierarchy, instead of sending it to a remote machine via SMTP (or any other protocol). I don't know postfix a lot, but I wonder why it needs two LDAs, one for real users and one for virtual ones, when the only conceptual difference should be where to store e-mails and where to lookup information on the existence of the user and his mail spool directory. Postfix's "local" and "virtual" exist because of specialized lookup mechanisms. Local just checks username portion of an address against the local password database, Virtual checks a configured mapping against the complete mail address. The choice of a multi-function agent vs multiple specialized agents is a matter of preference and always a subject of debate. For a Dovecot analogy, the current incarnation of "deliver" might be split up into "deliver-mbox", "deliver-maildir", and "deliver-dbox" - although that doesn't translate fully, as the Postfix delivery agents do both mbox & maildir. I guess a better comparison would be "deliver-local", "deliver-ldap", "deliver-sql", etc. -- Daniel
Re: [Dovecot] deliver vs lda
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {}
section. This is getting annoying, any thoughts on what would be a good
unifying name?
a) deliver binary, protocol deliver {}
b) lda binary, protocol lda {}
c) dovecot-lda binary, protocol lda {}
d) mda binary, protocol mda {}
e) dovecot-mda binary, protocol mda {}
f) something else?
In any case protocol lda {} would work for a while longer for backwards
compatibility.
c) and e) choices also makes me think if e.g. imap and imap-login should
be called dovecot-imap and dovecot-imap-login instead. People have had
trouble finding them since ps|grep dovecot doesn't find them..
Having a consistent name prefix for all the processes sounds nice - but
then you'd stick out as the exception to typical multi-process server
names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing
to deviate from accepted (poor) practices? Hmm
Other tradeoffs...more space consumed in logfiles. More screen width
consumed during listings. Not necessarily a Good Thing - not
necessarily a Bad Thing. But something to ponder on.
I would also consider the Dovecot architecture. As I (mis)understand
it, the "dovecot" process spawns the necessary imap, pop3, and login
daemons. So having a "dovecot.conf" file for controlling these is quite
appropriate. However, unless I've missed something (quite likely) -
"deliver" has nothing to do with the listening daemons. So having the
"lda" configuration in the dovecot.conf file might be inappropriate - I
would suggest splitting that off to a "dovecot-lda.conf" file (or
whatever you change the delivery agent name to).
I like option c.
--
Daniel
[Dovecot] Indexing of mails to speed up the IMAP SEARCH command
Hi all, I use a local dovecot server which is synchronized with my two imap accounts using OfflineIMAP. This works very nice and is highly usable. But one thing I'd like to improve is the slow IMAP search. When I search for a string in the subjects of all messages in a mailbox using some mail client, dovecot seems to grep all the messages in there. Is there a way to let dovecot index more informations which are then used to speed up the SEARCH command? Bye, Tassilo
Re: [Dovecot] deliver vs lda
Charles Marcus wrote: > On 4/8/2009, Eduardo M KALINOWSKI (edua...@kalinowski.com.br) wrote: > >> It's local because it stores e-mails somewhere in the local filesystem >> hierarchy, instead of sending it to a remote machine via SMTP (or any >> other protocol). >> > > But thats not the generally accepted meaning of local in context of > email servers. I don't know what is the generally accepted, but to me virtual users are just as local as real users, they just don't have a proper account (because there is no need to). > Besides, this isn't true if you're using NFS... > Not quite... in the point of view of a program, writing to a NFS share or a filesystem in the same machine is the same thing, the program doesn't even have to know that it's storing a file in another machine. And mail is not being "transported", which would involve another MTA that would further handle the e-mail. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: [Dovecot] deliver vs lda
On 4/8/2009, Eduardo M KALINOWSKI (edua...@kalinowski.com.br) wrote: > It's local because it stores e-mails somewhere in the local filesystem > hierarchy, instead of sending it to a remote machine via SMTP (or any > other protocol). But thats not the generally accepted meaning of local in context of email servers. Besides, this isn't true if you're using NFS... -- Best regards, Charles
Re: [Dovecot] deliver vs lda
Charles Marcus wrote: > heh... well, they would soon enough... > > Seriously though... why call it a 'local delivery agent', when its > really more than that? Local suggests local/system users, and dovecot > delivery agent works fine for both local and virtual users. Postfix > calls its local delivery agent 'local', and its virtual delivery agent > 'virtual' > It's local because it stores e-mails somewhere in the local filesystem hierarchy, instead of sending it to a remote machine via SMTP (or any other protocol). I don't know postfix a lot, but I wonder why it needs two LDAs, one for real users and one for virtual ones, when the only conceptual difference should be where to store e-mails and where to lookup information on the existence of the user and his mail spool directory. -- A lost ounce of gold may be found, a lost moment of time never. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: [Dovecot] deliver vs lda
On 4/8/2009 11:16 AM, Timo Sirainen wrote:
>>> Me. It makes my code ugly. It makes writing to wiki difficult when you
>>> never know if you should call it deliver or lda. Basically there's no
>>> consistency, which is annoying.
>> How about dda (dovecot delivery agent)?
> No one's going to have any idea what that is :)
heh... well, they would soon enough...
Seriously though... why call it a 'local delivery agent', when its
really more than that? Local suggests local/system users, and dovecot
delivery agent works fine for both local and virtual users. Postfix
calls its local delivery agent 'local', and its virtual delivery agent
'virtual'
:)
So, fwiw (about 2 cents, in current dollars), I'd just vote for:
dovecot-deliver binary, protocol-deliver {}...
--
Best regards,
Charles
Re: [Dovecot] Multiple use of the same LDAP attribute
On Wed, Apr 08, 2009 at 12:41:17PM -0400, Timo Sirainen wrote: > > So, it looks like there is an issue using the same LDAP attribute > > (xxxMailbox in this case) twice in variable expansion. > > Is this a known issue? > Yes. I was planning on rewriting LDAP configuration and getting it fixed > at the same time, but looks like it didn't happen yet for v1.2. Okay, thanks for the clarification. > > Of course there are several viable workarounds > > (base mail location on home directory, > This is what I would have suggested. Seems like a cleaner solution in > any case. Come to think of it, any hint how I can implement the existing scheme? user_attrs = xxxMailbox=mail=maildir:/home/mailstore/%U$/Maildir:INDEX=/home/mailstore/indexes/%1U$/%U$, xxxMailbox=home=/home/mailstore/%U$ the maildir location is easy (mail=maildir:~/Maildir), but the index is hard, as I don't have the userid in any variable. The only thing I can come up with atm is user_attrs = xxxMailbox=home=/home/mailstore/%U$, xxxMailbox=mail=maildir:~/Maildir:INDEX=/home/mailstore/indexes/%16.1h/%16.99h but I'm willing to bet that this is going to break at some point, the latest point being when someone changes the mailstore path and forgets to update the offset :-\ What happens when the width is larger than the length of the string anyway? Bernhard
Re: [Dovecot] Dovecot 1.1.11 failing to accept SSL/TLS connections
On Thu, 2009-03-19 at 16:56 +, Mike Brudenell wrote: > destroy_count = max_connections > CLIENT_DESTROY_OLDEST_COUNT*2 ? > CLIENT_DESTROY_OLDEST_COUNT : I_MIN(max_connections/2, 1); > > should set destroy_count to CLIENT_DESTROY_OLDEST_COUNT, which is 16. So I > was expecting to see 16 messages in the log saying "Disconnected: Connection > queue full": one as each client was disconnected, and that these would > therefore appear in very quick succession. > > Yet in reality although the message is logged frequently I wouldn't say it > was a quick burst of 16. I'm guessing that there just aren't many imap_clients. That most connections are SSL connections that are being proxied and there's probably just 1..few actual logging in clients. Wonder if this helps: http://hg.dovecot.org/dovecot-1.1/rev/c91b73564611 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Prohibit removing INBOX
On Sun, 2009-04-05 at 13:35 +0200, fl...@pbartels.info wrote: > The documentation says: > > If a mailbox has both global and per-mailbox ACL file, both of them > > are read and the ACLs are merged. If there are any conflicts: > > * v1.0 and v1.1: The per-mailbox ACL file overrides global ACL file. > > As far I can see it the documentation says nothing about merging ACLs > of subdirs. But it seems the given behavior is not wanted by the > dovecot design, because it seems it should be possible to override > ACLs for subdirs, also give more permissions than the upper dirs. I'm not really sure what you mean by this, but there isn't really any concept of subdirs or upper dirs, or any kind of recursively applied ACLs. The only exception i the +k (create) right, which specifies if mailboxes can be created directly under that mailbox. So if you have for example mailboxes box1 and box1/box2, their ACLs aren't merged in any way in any situation. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot, LVS and the issues I have with it.
On Mon, 2009-04-06 at 12:42 +0100, neil wrote: > We currently have two issues with this setup. One of which is NFS index > corruption issues we get due to NFS/dovecot locking. Basically the UUID > list or a .index gets corrupt. This causes a full re-indexing of the > mailbox / broken mailbox until i delete the indexes. In the UUID lists > case the symptom tends to effect use who use POP rather than IMAP and > insist on keeping messages on the server. Because it's corrupt it gets > rebuilt one way or the other and the users email client proceeds to > redownload the entire mailbox again until he remarks them to be saved. > This tends to annoy the user a lot. After a bit of testing we do however > expect this to be fixed by version 1.1. However if anyone has any > comments on this I would certainly be interested. v1.1 at least handles it much better. > 1. We obviously reach the auth thread cap eventually so any new auth > requests basically get refused by the server. Auth thread? Do you mean the max. number of login connections/processes? Do you have login_process_per_connection=no? That might help. http://wiki.dovecot.org/LoginProcess > 2. Now here's my real gripe. Dovecot does not handle running out > resources very gracefully at all in our setup. It does start killing > threads after a while. I get multiple *"dovecot: child 17989 (login) > killed with signal 9". Dovecot doesn't kill them, kernel kills them. > *I'm not exactly sure what's going on here > because after this all I can see is the machine totally out of memory > and the kernel starts killing absolutely everything. All services are > killed (including ssh etc..) and I plug a monitor into the server and > find the last few lines of the console listing init and other rather > important things having just been killed. At this point it is a case of > power cycling the server and all is back to normal again. Maybe it would help to change max_mail_processes to a lower number, those are probably the ones eating the memory. dovecot -n output might have been helpful also in giving some suggestions. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve rules in MySQL?
On Tue, 2009-04-07 at 11:36 +0100, David Reid wrote: > Has anyone looked at modifying the sieve implementation to allow the use > of MySQl to store the rules? Maybe instead of MySQL directly it could use lib-dict, which then could be configured to use MySQL or whatever. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] maximum number of channel in thunderbird
On Wed, 2009-04-08 at 15:53 +0200, Kakà wrote: > Does it helps ? Mm Your configuration looks fine, so I don't think the problem is with Dovecot. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Coredump using virtual folder.
Hi, I guess x-references2 has been renamed to refs. When I'm using I that, I got a coredump again: [New process 24135] #0 0x080a3038 in index_header_lookup_init (box=0x9b05d28, headers=0x0) at index-mail-headers.c:864 864 i_assert(*headers != NULL); (gdb) bt #0 0x080a3038 in index_header_lookup_init (box=0x9b05d28, headers=0x0) at index-mail-headers.c:864 #1 0xb7e9aad5 in virtual_mail_set_backend_mail (mail=0xa355230, bbox=0x9b058b0) at virtual-mail.c:89 #2 0xb7e9ac0e in virtual_mail_set_seq (mail=0xa355230, seq=1) at virtual-mail.c:116 #3 0xb7e9b1a6 in virtual_search_next_nonblock (ctx=0xa2792c8, mail=0xa355230, tryagain_r=0xbfb05b3b) at virtual-search.c:176 #4 0xb7e9b15a in virtual_search_next_nonblock (ctx=0xa2792c8, mail=0xa355230, tryagain_r=0xbfb05b3b) at virtual-search.c:155 #5 0x080b3dbd in mailbox_search_next_nonblock (ctx=0xa2792c8, mail=0xa355230, tryagain_r=0xbfb05b3b) at mail-storage.c:747 #6 0x080b3e18 in mailbox_search_next (ctx=0xa2792c8, mail=0xa355230) at mail-storage.c:733 #7 0x080acbca in mail_thread_init (box=0x9b056f0, args=0x0, ctx_r=0xa31e918) at index-thread.c:357 #8 0x080a6d31 in index_storage_search_init (_t=0xa392838, args=0x9b081f0, sort_program=0x0) at index-search.c:993 #9 0xb7e9b25d in virtual_search_init (t=0xa392838, args=0x9b081f0, sort_program=0x0) at virtual-search.c:115 #10 0xb7e9e7fd in virtual_storage_sync_init (box=0x9b04178, flags=65) at virtual-sync.c:452 #11 0x080b3b72 in mailbox_sync (box=0x3, flags=65, status_items=239, status_r=0xbfb05f98) at mail-storage.c:570 #12 0x08064708 in cmd_select_full (cmd=0x9afb9f8, readonly=false) at cmd-select.c:273 #13 0x08064e69 in cmd_select (cmd=0x9afb9f8) at cmd-select.c:388 #14 0x0806700c in client_command_input (cmd=0x9afb9f8) at client.c:603 #15 0x080670a9 in client_command_input (cmd=0x9afb9f8) at client.c:652 #16 0x080676ed in client_handle_input (client=0x9afb768) at client.c:693 #17 0x08067ba3 in client_input (client=0x9afb768) at client.c:748 #18 0x080f73f0 in io_loop_handler_run (ioloop=0x9af79b0) at ioloop-epoll.c:208 #19 0x080f6880 in io_loop_run (ioloop=0x9af79b0) at ioloop.c:338 #20 0x080704c5 in main (argc=Cannot access memory at address 0x3 using the dovecot-virtual: virtual.all inthread refs x-mailbox INBOX kind regards, matthias
Re: [Dovecot] Strange behavior of header_filter_callback
On Wed, 2009-04-08 at 14:05 +0400, Konstantin Lepa wrote:
You didn't say what the strange behavior was .. But:
if (hdr && hdr->eoh == TRUE) { *matched = FALSE; }
else { *matched = TRUE; }
Don't explicitly set matched always. Set it only when you know you want
to change its matching state. So the above code should be only:
if (hdr && hdr->eoh == TRUE) { *matched = FALSE; }
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Global Sieve File
Yes, it works using your solution:
dovecot.conf:
sieve_global_path = /usr/local/etc/sieve/global/default.sieve
/usr/local/etc/sieve/global/default.sieve:
keep;
Thanks,
Andrés Fernando Yacopino
Infraestructura - Dpto Sistemas
AcaSalud
Cooperativa de Prestaciones Médico Asistenciales Limitada
Tel: 0341-4208726
ayacop...@acasalud.com.ar
Stephan Bosch escribió:
Andrés Yacopino wrote:
I am testing yet this version of sieve with dovecot 1.2 beta
I have done in dovecot.conf:
protocols = imap imaps pop3 pop3s managesieve
mail_plugins = quota sieve
sieve_before = /usr/local/etc/sieve/global/.global.dovecot.sieve
more /usr/local/etc/sieve/global/.global.dovecot.sieve:
require "fileinto";
if exists "X-Spam-Flag" { fileinto "spam"; }
I have found that i need a personal script in the home directory to
execute this global script, if the user script isn't exists this
before script is not run.
Personal script:
more .dovecot.sieve:
require "include";
I am planning to use this to filter spam in a global script and
deploy managed sieve with avelsize plugin with squirrelmail to let
users configure their vacation messages
I would prefer to have independent global scripts from personal scripts.
Yes, this problem was pointed out before. For now, you can work around
this by setting a sieve_global_path= pointing to a script containing
only 'keep;'. This makes sure the global script is executed, because
then there is a default alternative for the personal script if it is
missing for a particular user.
I'll fix this in the course of this week.
Regards,
Stephan.
Re: [Dovecot] Multiple use of the same LDAP attribute
On Wed, 2009-04-08 at 13:07 +, Bernhard Schmidt wrote: > So, it looks like there is an issue using the same LDAP attribute > (xxxMailbox in this case) twice in variable expansion. > > Is this a known issue? Yes. I was planning on rewriting LDAP configuration and getting it fixed at the same time, but looks like it didn't happen yet for v1.2. > Of course there are several viable workarounds > (base mail location on home directory, This is what I would have suggested. Seems like a cleaner solution in any case. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot 1.2-rc2 doesn't build on Solaris 10
On Wed, 2009-04-08 at 21:47 +0800, Laurent Blume wrote: > Hi all, Timo, > > When trying to build 1.2 rc2 on Solaris 10, with the same options and > compiler as what works for 1.1.13, I get the following error: .. > "quota-fs.c", line 436: undefined symbol: GRPQUOTA Yeah, I noticed the same. This fixes it: http://hg.dovecot.org/dovecot-1.2/rev/7bfbbfd2c32a signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot doesnt see any emails
On Wed, 2009-04-08 at 11:44 -0400, alexus wrote: > > You didn't post your whole dovecot -n output, so I don't know what you're > > using as userdb. But this should work with userdb vpopmail and also vpopmail > > checkpassword: > > > > mail_location = maildir:~ > > > > > > sorry, i forgot to add that i dont have any system users, all my users > are vpopmail users so i dont think maildir:~ would work here... You're misunderstanding what ~ does. It's the home directory returned by userdb lookup. If your userdb is vpopmail, it expands to the home directory returned by vpopmail. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Global Sieve File
Andrés Yacopino wrote:
I am testing yet this version of sieve with dovecot 1.2 beta
I have done in dovecot.conf:
protocols = imap imaps pop3 pop3s managesieve
mail_plugins = quota sieve
sieve_before = /usr/local/etc/sieve/global/.global.dovecot.sieve
more /usr/local/etc/sieve/global/.global.dovecot.sieve:
require "fileinto";
if exists "X-Spam-Flag" { fileinto "spam"; }
I have found that i need a personal script in the home directory to
execute this global script, if the user script isn't exists this before
script is not run.
Personal script:
more .dovecot.sieve:
require "include";
I am planning to use this to filter spam in a global script and deploy
managed sieve with avelsize plugin with squirrelmail to let users
configure their vacation messages
I would prefer to have independent global scripts from personal scripts.
Yes, this problem was pointed out before. For now, you can work around
this by setting a sieve_global_path= pointing to a script containing
only 'keep;'. This makes sure the global script is executed, because
then there is a default alternative for the personal script if it is
missing for a particular user.
I'll fix this in the course of this week.
Regards,
Stephan.
Re: [Dovecot] Compiling v1.3 on different OSes
Timo, it is compiling well now in Solaris 10 for Sparc with gcc 3.4.3. I was compiling the old version (i was downloading from a proxy with the old version), sorry. Greetings, Andrés Fernando Yacopino Infraestructura - Dpto Sistemas AcaSalud Cooperativa de Prestaciones Médico Asistenciales Limitada Tel: 0341-4208726 ayacop...@acasalud.com.ar Andrés Yacopino escribió: Timo: I do it in Solaris 10 8/07 s10s_u4wos_12b SPARC with gcc (GCC) 3.4.3: CFLAGS='-mcpu=v9 -mtune=ultrasparc3 -O2 -pipe' CPPFLAGS=' -I/usr/local/include -I/usr/local/apache/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/include/openssl -I/usr/local/include/mutils -I/usr/sfw/include -I/usr/include' LDFLAGS='-L/usr/local/lib -R/usr/local/lib -L/usr/local/apache/lib -R/usr/local/apache/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB.4.2/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/lib -R/lib -L/usr/lib -R/usr/lib' ./configure --with-ldap make I get: Undefined first referenced symbol in file libiconv_close ../lib-dovecot/.libs/libdovecot.so libiconv_open ../lib-dovecot/.libs/libdovecot.so libiconv../lib-dovecot/.libs/libdovecot.so ld: fatal: Symbol referencing errors. No output written to .libs/dovecot-auth collect2: ld returned 1 exit status make[3]: *** [dovecot-auth] Error 1 make[3]: Leaving directory `/export/software/dovecot1.3/dovecot-1.3.UNSTABLE/src/auth' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/export/software/dovecot1.3/dovecot-1.3.UNSTABLE/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/software/dovecot1.3/dovecot-1.3.UNSTABLE' make: *** [all] Error 2 Is this the version which has been repaired from iconv problems? Look down your post, i downloaded it from there. Andrés Fernando Yacopino Infraestructura - Dpto Sistemas AcaSalud Cooperativa de Prestaciones Médico Asistenciales Limitada Tel: 0341-4208726 ayacop...@acasalud.com.ar Timo Sirainen escribió: On Mon, 2009-04-06 at 14:08 -0400, Timo Sirainen wrote: http://dovecot.org/tmp/dovecot-1.3.UNSTABLE.tar.gz OK, updated the URL once more. Now iconv problems should be gone? And everyone else is happy with it too? :)
Re: [Dovecot] dovecot doesnt see any emails
On Wed, Apr 8, 2009 at 12:15 AM, Timo Sirainen wrote: > On Apr 7, 2009, at 11:41 PM, alexus wrote: > >>> If you have deleted domains, or lost the file that controls directory >>> hashing, things can really get weird. The only safe way to locate >>> domains >>> and/or users with vpopmail is to ask vpopmail where they are located. >> >> okay, so what do you suggest then? > > You didn't post your whole dovecot -n output, so I don't know what you're > using as userdb. But this should work with userdb vpopmail and also vpopmail > checkpassword: > > mail_location = maildir:~ > > sorry, i forgot to add that i dont have any system users, all my users are vpopmail users so i dont think maildir:~ would work here... -- http://alexus.org/
[Dovecot] Global Sieve File
I am testing yet this version of sieve with dovecot 1.2 beta
I have done in dovecot.conf:
protocols = imap imaps pop3 pop3s managesieve
mail_plugins = quota sieve
sieve_before = /usr/local/etc/sieve/global/.global.dovecot.sieve
more /usr/local/etc/sieve/global/.global.dovecot.sieve:
require "fileinto";
if exists "X-Spam-Flag" { fileinto "spam"; }
I have found that i need a personal script in the home directory to
execute this global script, if the user script isn't exists this before
script is not run.
Personal script:
more .dovecot.sieve:
require "include";
I am planning to use this to filter spam in a global script and deploy
managed sieve with avelsize plugin with squirrelmail to let users
configure their vacation messages
I would prefer to have independent global scripts from personal scripts.
Greetings,
Andrés Fernando Yacopino
Infraestructura - Dpto Sistemas
AcaSalud
Cooperativa de Prestaciones Médico Asistenciales Limitada
Tel: 0341-4208726
ayacop...@acasalud.com.ar
James Butler escribió:
Is anyone here using a global Sieve file that handles messages for an
entire server with many users? I understand and use local Sieve files, but
I would like to learn more about how to set up Sieve to filter ALL
incoming messages using a single file. I would love to read about how you
managed to get it working.
I'm running Fedora 10 with Postfix 2.5.5 and Dovecot 1.2.rc2.
Thanks for any insight!
James
Re: [Dovecot] deliver vs lda
Jonathan wrote:
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {}
section. This is getting annoying, any thoughts on what would be a good
unifying name?
c) dovecot-lda binary, protocol lda {}
I'd vote for C as well.
++c
\\||/
Rod
--
Re: [Dovecot] deliver vs lda
On Apr 8, 2009, at 6:01 AM, Charles Marcus wrote: On 4/7/2009, Timo Sirainen (t...@iki.fi) wrote: Me. It makes my code ugly. It makes writing to wiki difficult when you never know if you should call it deliver or lda. Basically there's no consistency, which is annoying. How about dda (dovecot delivery agent)? No one's going to have any idea what that is :)
Re: [Dovecot] Compiling v1.3 on different OSes
Timo: I do it in Solaris 10 8/07 s10s_u4wos_12b SPARC with gcc (GCC) 3.4.3: CFLAGS='-mcpu=v9 -mtune=ultrasparc3 -O2 -pipe' CPPFLAGS=' -I/usr/local/include -I/usr/local/apache/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/include/openssl -I/usr/local/include/mutils -I/usr/sfw/include -I/usr/include' LDFLAGS='-L/usr/local/lib -R/usr/local/lib -L/usr/local/apache/lib -R/usr/local/apache/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB.4.2/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/lib -R/lib -L/usr/lib -R/usr/lib' ./configure --with-ldap make I get: Undefined first referenced symbol in file libiconv_close ../lib-dovecot/.libs/libdovecot.so libiconv_open ../lib-dovecot/.libs/libdovecot.so libiconv../lib-dovecot/.libs/libdovecot.so ld: fatal: Symbol referencing errors. No output written to .libs/dovecot-auth collect2: ld returned 1 exit status make[3]: *** [dovecot-auth] Error 1 make[3]: Leaving directory `/export/software/dovecot1.3/dovecot-1.3.UNSTABLE/src/auth' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/export/software/dovecot1.3/dovecot-1.3.UNSTABLE/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/software/dovecot1.3/dovecot-1.3.UNSTABLE' make: *** [all] Error 2 Is this the version which has been repaired from iconv problems? Look down your post, i downloaded it from there. Andrés Fernando Yacopino Infraestructura - Dpto Sistemas AcaSalud Cooperativa de Prestaciones Médico Asistenciales Limitada Tel: 0341-4208726 ayacop...@acasalud.com.ar Timo Sirainen escribió: On Mon, 2009-04-06 at 14:08 -0400, Timo Sirainen wrote: http://dovecot.org/tmp/dovecot-1.3.UNSTABLE.tar.gz OK, updated the URL once more. Now iconv problems should be gone? And everyone else is happy with it too? :)
Re: [Dovecot] maximum number of channel in thunderbird
Does it helps ? Mm # 1.1.7: /usr/local/etc/dovecot.conf # OS: Linux 2.6.18-92.1.22.el5 i686 CentOS release 5.2 (Final) ext3 base_dir: /var/run/dovecot/ log_path: /var/log/maillog log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap pop3 imaps pop3s ssl_listen: * ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot-login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login mail_max_userip_connections: 100 first_valid_uid: 150 last_valid_uid: 150 mail_access_groups: mail mail_location: maildir:/home/vmail/%d/%n/Maildir mail_debug: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes auth default: mechanisms: plain login debug_passwords: yes passdb: driver: sql args: /etc/dovecot-mysql.conf userdb: driver: passwd userdb: driver: static args: uid=150 gid=12 home=/home/vmail/%d/%n allow_all_users=yes userdb: driver: sql args: /etc/dovecot-mysql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot-auth-master mode: 384 user: vmail Timo Sirainen ha scritto: On Tue, 2009-04-07 at 13:05 -0400, Timo Sirainen wrote: mail_max_userip_connections=100; If that doesn't help, it's unlikely it's a Dovecot problem. Although it depends on where you put it.. Show your dovecot -n output.
[Dovecot] dovecot 1.2-rc2 doesn't build on Solaris 10
Hi all, Timo, When trying to build 1.2 rc2 on Solaris 10, with the same options and compiler as what works for 1.1.13, I get the following error: libtool: compile: cc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib-dict -I../../../src/lib-index -I../../../src/lib-mail -I../../../src/lib-storage -I../../../src/lib-storage/index -I../../../src/lib-storage/index/maildir -O -m64 -I/usr/sfw/include -c quota-fs.c -KPIC -DPIC -o .libs/quota-fs.o "quota-fs.c", line 436: undefined symbol: GRPQUOTA cc: acomp failed for quota-fs.c *** Error code 1 make: Fatal error: Command failed for target `quota-fs.lo' Current working directory /export/espace/apps/src/network/dovecot-1.2.rc2/src/plugins/quota *** Error code 1 The compiler is Studio 12 patched, and the options used were: CFLAGS='-O -m64' \ SSL_LIBS="-R/usr/sfw/lib/64 -L/usr/sfw/lib/64 -lssl -lcrypto" \ ./configure --prefix=/opt/dovecot-1.2-rc2 \ --sysconfdir=/etc/opt/dovecot-rc \ --localstatedir=/var/dovecot-rc \ --with-rundir=/var/run/dovecot-rc \ --with-statedir=/var/dovecot-rc/lib \ --with-ioloop=best \ --with-zlib \ --with-bzlib \ --with-ssl=openssl \ --with-ssldir=/etc/certs \ --with-shadow \ --with-pam \ --with-ldap \ --enable-header-install Thanks, Laurent -- / Leader de Projet & Communauté| I'm working, but not speaking for \ G11N http://fr.opensolaris.org | Bull Services http://www.bull.com / FOSUG http://guses.org |
Re: [Dovecot] Upgrade from 0.99.x to 1.1.x
Wolfram Schlich wrote: > Do I understand it correctly that when directly upgrading from > 0.99 to 1.1, Dovecot does the subscriptions renaming but not the > keywords renaming and conversion, but that when I manually rename > all .customflags files to dovecot-keywords, it does the format > conversion of that file automatically? Yes, that is correct. I did this same conversion about a year ago: http://www.dovecot.org/list/dovecot/2008-March/029325.html > Is there anything else what's important to note for such an upgrade? I do not remember any big problems with the conversion. However, lots of small problems with Dovecot just disappeared when getting rid of 0.99 ... Anders.
Re: [Dovecot] Multiple use of the same LDAP attribute
Charles Marcus wrote: >> we've found a weird bug (?) in Dovecot 1.1.11. > dovecot -n output is usually desired when asking for help, especially > when it is a likely config issue... I don't think it's a config issue, but here we go: lxmhs23: # dovecot -n # 1.1.11: /mnt/mail2/usr/etc/dovecot.conf # OS: Linux 2.6.5-7.308-bigsmp i686 SUSE LINUX Enterprise Server 9 # (i586) nfs listen: :143 ssl_listen: :993 disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable: /mnt/mail2/usr/libexec/dovecot/imap-login login_process_per_connection: no login_max_connections: 128 max_mail_processes: 2500 mail_uid: vmail mail_gid: vmail mail_location: maildir:/home/mailstore/%Uu/Maildir:INDEX=/home/mailstore/indexes/%1Un/%Un mmap_disable: yes mail_nfs_index: yes mail_plugins: quota imap_quota namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes auth default: username_format: %Lu worker_max_count: 500 passdb: driver: ldap args: /mnt/mail2/usr/etc/dovecot-ldap.conf userdb: driver: ldap args: /mnt/mail2/usr/etc/dovecot-ldap.conf userdb: driver: prefetch socket: type: listen master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail plugin: quota: maildir quota_rule: Trash:ignore quota_rule2: *:storage=256M quota_warning: storage=95%% /mnt/mail2/bin/quota-warning-95.sh quota_warning2: storage=85%% /mnt/mail2/bin/quota-warning-85.sh Bernhard
Re: [Dovecot] Multiple use of the same LDAP attribute
On 4/8/2009 9:07 AM, Bernhard Schmidt wrote: > Hi, > > we've found a weird bug (?) in Dovecot 1.1.11. dovecot -n output is usually desired when asking for help, especially when it is a likely config issue... -- Best regards, Charles
[Dovecot] Multiple use of the same LDAP attribute
Hi, we've found a weird bug (?) in Dovecot 1.1.11. Since day and age we've been running dovecot for our student mailserver, getting the location of the mailbox from a LDAP directory. We allow login and LDA with both full mail address and an internal username, so the mailbox directory is based on a LDAP attribute user_attrs = xxxMailbox=mail=maildir:/home/mailstore/%U$/Maildir:INDEX=/home/mailstore/indexes/%1U$/%U$, uidNumber=vmail, gidNumber=vmail, xxxMailQuota=quota_rule2=*:storage=%$B this worked just fine until we introduced sieve, which made us realize we did not have the home directory set at all. The obvious and easy fix (we thought) was to set the home directory based on the xxxMailbox variable as well: user_attrs = xxxMailbox=mail=maildir:/home/mailstore/%U$/Maildir:INDEX=/home/mailstore/indexes/%1U$/%U$, uidNumber=vmail, gidNumber=vmail, xxxMailQuota=quota_rule2=*:storage=%$B, xxxMailbox=home=/home/mailstore/%U$ unfortunately, after this trivial change hell froze over, because suddenly the mail variable was not set at all anymore, and since we had set mail_location = maildir:/home/mailstore/%Uu/Maildir:INDEX=/home/mailstore/indexes/%1Un/%Un (based on username) it was suddenly delivered into the wrong folder (based on the supplied username, not on the LDAP attribute). Debug from after the change: Apr 8 13:53:39 lxmhs23 dovecot: auth(default): ldap(usern...@xxx.de): user search: base= scope=onelevel filter= fields=xxxMailbox,uidNumber,gidNumber,xxxMailQuota,xxxMailbox Apr 8 13:53:39 lxmhs23 dovecot: auth(default): ldap(usern...@xxx.de): result: xxxMailQuota(quota_rule2=*:storage=%$B)=*:storage=1073741824B xxxMailbox(home=/home/mailstore/%U$)=/home/mailstore/1636D8B1D7916DEA/ [...] Apr 8 13:53:39 lxmhs23 deliver(usern...@xxx.de): maildir: data=/home/mailstore/usern...@xxx.de/Maildir:INDEX=/home/mailstore/indexes/U/USERNAME As you can see the mail variable wasn't set by LDAP at all. We did some more tests and found a workaround, when using another LDAP (mwnid) attribute that contains the same information it works just fine user_attrs = xxxMailbox=mail=maildir:/home/mailstore/%U$/Maildir:INDEX=/home/mailstore/indexes/%1U$/%U$, uidNumber=vmail, gidNumber=vmail, xxxMailQuota=quota_rule2=*:storage=%$B, mwnid=home=/home/mailstore/%U$ Apr 8 14:18:06 lxmhs23 dovecot: auth(default): ldap(usern...@xxx.de): user search: base= scope=onelevel filter= fields=xxxMailbox,uidNumber,gidNumber,xxxMailQuota,mwnid Apr 8 14:18:06 lxmhs23 dovecot: auth(default): ldap(usern...@xxx.de): result: xxxMailQuota(quota_rule2=*:storage=%$B)=*:storage=1073741824B xxxMailbox(mail=maildir:/home/mailstore/%U$/Maildir:INDEX=/home/mailstore/indexes/%1U$/%U$)=maildir:/home/mailstore/1636D8B1D7916DEA//Maildir:INDEX=/home/mailstore/indexes/1/1636D8B1D7916DEA/ mwnid(home=/home/mailstore/%U$)=/home/mailstore/1636D8B1D7916DEA Apr 8 14:18:06 lxmhs23 deliver(usern...@xxx.de): maildir: data=/home/mailstore/1636D8B1D7916DEA//Maildir:INDEX=/home/mailstore/indexes/1/1636D8B1D7916DEA/ So, it looks like there is an issue using the same LDAP attribute (xxxMailbox in this case) twice in variable expansion. Is this a known issue? Of course there are several viable workarounds (base mail location on home directory, use the second attribute), but this problem was pretty surprising. Bernhard
Re: [Dovecot] Segfault in ACL Plugin + user shared folders
Another one:
#0 0xb7fbf424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7e7a640 in raise () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb7e7c018 in abort () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#3 0x080ee9a5 in default_fatal_finish (type=, status=0)
at failures.c:161
backtrace = 0x8282480 "imap [0x80ee991] -> imap [0x80eea12] -> imap
[0x80ee399] -> imap [0x80b50eb] -> imap(shared_storage_get_namespace+0x2bf)
[0x8075fff] -> imap [0x80757d7] -> imap [0x8063034] ->
imap(cmd_list_full+0x514"...
#4 0x080eea12 in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0,
fmt=0x810632c "file %s: line %d (%s): assertion failed: (%s)",
args=0xbfbda674 "\017\v\021\b\036") at failures.c:441
No locals.
#5 0x080ee399 in i_panic (format=0x810632c "file %s: line %d (%s): assertion
failed: (%s)") at failures.c:208
No locals.
#6 0x080b50eb in mail_user_init (username=0x829854e "") at mail-user.c:30
user =
pool =
__PRETTY_FUNCTION__ = "mail_user_init"
#7 0x08075fff in shared_storage_get_namespace (_storage=0x82929d0,
_name=0xbfbda724, ns_r=0xbfbda728) at shared-storage.c:224
user = (struct mail_user *) 0x828e270
ns = (struct mail_namespace *) 0x0
owner =
domain = 0x0
username = 0x829854e ""
userdomain = 0x829854e ""
name = 0x810fc97 "INBOX"
p =
dest =
error =
prefix = (string_t *) 0x82823b0
location =
ret =
static_tab = {{key = 117 'u', value = 0x0, long_key = 0x8110b32
"user"}, {key = 110 'n', value = 0x0, long_key = 0x8109830 "username"}, {
key = 100 'd', value = 0x0, long_key = 0x8109839 "domain"}, {key = 104 'h',
value = 0x0, long_key = 0x8109807 "home"}, {key = 0 '\0', value = 0x0,
long_key = 0x0}}
__PRETTY_FUNCTION__ = "shared_storage_get_namespace"
#8 0x080757d7 in shared_list_join_refpattern (list=0x8292dd8, ref=0x8298548
"#User/", pattern=0x8298550 "*") at shared-list.c:148
ns =
ns_ref = 0x829854e ""
prefix = 0x8292998 "#User/"
#9 0x08063034 in cmd_list_continue (cmd=0x8293448) at cmd-list.c:672
_data_stack_cur_id = 4
ctx = (struct cmd_list_context *) 0x82934e0
#10 0x08063a04 in cmd_list_full (cmd=0x8293448, lsub=false) at cmd-list.c:903
client = (struct client *) 0x82931b8
args = (const struct imap_arg *) 0x82984e8
arg =
ctx = (struct cmd_list_context *) 0x82934e0
patterns = {arr = {buffer = 0x8293508, element_size = 4}, v =
0x8293508, v_modifiable = 0x8293508}
pattern = 0x8298550 "*"
#11 0x08063d09 in cmd_list (cmd=0x8293448) at cmd-list.c:918
No locals.
#12 0x0806700c in client_command_input (cmd=0x8293448) at client.c:603
client = (struct client *) 0x82931b8
command =
__PRETTY_FUNCTION__ = "client_command_input"
#13 0x080670a9 in client_command_input (cmd=0x8293448) at client.c:652
client = (struct client *) 0x82931b8
command =
__PRETTY_FUNCTION__ = "client_command_input"
#14 0x080676ed in client_handle_input (client=0x82931b8) at client.c:693
_data_stack_cur_id = 3
ret =
remove_io =
handled_commands = false
#15 0x08067ba3 in client_input (client=0x82931b8) at client.c:748
cmd =
output = (struct ostream *) 0x829336c
bytes =
__PRETTY_FUNCTION__ = "client_input"
#16 0x080f73a0 in io_loop_handler_run (ioloop=0x828aae0) at ioloop-epoll.c:208
ctx = (struct ioloop_handler_context *) 0x828abe8
event = (const struct epoll_event *) 0x828ac28
list = (struct io_list *) 0x82933f0
io = (struct io_file *) 0x82933c8
tv = {tv_sec = 1799, tv_usec = 999778}
t_id = 2
msecs =
ret = 1
i = 0
j = 0
call =
#17 0x080f6830 in io_loop_run (ioloop=0x828aae0) at ioloop.c:338
No locals.
#18 0x080704c5 in main (argc=Cannot access memory at address 0x4c2f
) at main.c:320
Re: [Dovecot] Upgrade from 0.99.x to 1.1.x
* Timo Sirainen [2009-04-07 17:51]: > On Apr 7, 2009, at 11:02 AM, Wolfram Schlich wrote: > > > Do I understand it correctly that when directly upgrading from > > 0.99 to 1.1, Dovecot does the subscriptions renaming but not the > > keywords renaming and conversion, but that when I manually rename > > all .customflags files to dovecot-keywords, it does the format > > conversion of that file automatically? > > All 0.99 .customflags conversion code has been removed from v1.1. If > you want to make things easier, upgrade to v1.0 first. Or if you don't > actually use any IMAP keywords (find ~/Maildir -name '*:2,*[a-z]*'), > you might just as well delete the files. Well, I'd have to make all users open all folders once to make Dovecot convert the files :( Not a solution. I guess I'll just delete the files, although the users actually have some customflags (Thunderbird stuff). -- Regards, Wolfram Schlich Gentoo Linux * http://dev.gentoo.org/~wschlich/
[Dovecot] Strange behavior of header_filter_callback
example.tgz Description: Binary data
Re: [Dovecot] deliver vs lda
On 4/7/2009, Timo Sirainen (t...@iki.fi) wrote: > Me. It makes my code ugly. It makes writing to wiki difficult when you > never know if you should call it deliver or lda. Basically there's no > consistency, which is annoying. How about dda (dovecot delivery agent)? -- Best regards, Charles
[Dovecot] Postfix + Dovecot + Sieve + SpamAssassin
Hello Until now I used Postfix in combination with Procmail and Dovecot. I am convinced that the Dovecot Sieve plugin is a much more elegant solution. So I changed to Postfix + Dovcecot Deliver + Dovecot + Sieve. If I understood correctly I cannot call other applications within a Sieve script. Until now I used Procmail to filter Spam Messages with SpamAssassin. Is there a possibility to filter spam messages before/after Dovecot deliver. I want to use the users .spammassassin user_prefs located in their home folder. I suppose if I use a content filter in Postfix this is to early, since the user is not known at that moment. Or am I wrong? Any help is highly appreciated. Best regards, Sascha
