> Related to PIPE_BUF, yes, but problem was in the sending part. Fixed:
> http://hg.dovecot.org/dovecot-2.0/rev/5ede18fe35fa
Yes, that fixes it. Thanks.
> Is OSX's PIPE_BUF really only 512 bytes
Yes.
2.0.beta6 assert-fails for me when:
- using mdbox (maildir is OK)
- my authentication module returns the mail= and mail_location= attributes
(relying on mail_location from 10-mail.conf is OK)
- a user logs in for the first time and selects his nonexistent INBOX
The error is:
Panic: file mailbox-l
>> Panic: file mailbox-list.c: line 318 (mailbox_list_get_unexpanded_path):
>> assertion failed: (*location == '0')
>
> Fixed: http://hg.dovecot.org/dovecot-2.0/rev/6e1247609440
Yes. Thanks.
Dovecot-2.0.beta6 sometimes terminates client connections and reports these
errors:
Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
offset=6216579): msg header has bad magic value
Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
offset=6216579): uid=0 points to b
The "imap" process of dovecot-2.0.beta[5,6] grows very large (I impose no
system limits), e.g. exceeding 4.8GB on a 64-bit system. These messages appear
in the logs:
Warning: Growing pool 'imap client' with: 2048
Warning: Growing pool 'Cache fields' with: 2048
Warning: Growing data stack with: 3
>> 6 imap0x000105867333
>> imap_refresh_proctitle + 218 ->
>> 7 imap0x0001058666ce cmd_sync_continue
>> + 199 ->
>
> But how does this happen? Did it optimize away some functions
Yeah optimized out tail-calls, e.g. clie
> Is it complete garbage or 0xde character? (Or if you don't use
> --with-devel-checks then 0xde shouldn't be appearing.)
It is often 0xde with devel-checks on.
> I couldn't find anything obviously wrong in the code.
Figured it out. The t_pop in client_handle_input was clobbering
imap_clients->command_queue->name. This is because cmd_uid allocated the name
from the wrong pool. Here is a patch to fix it. Forget my other patch (to
imap_refresh_procti
>> Dovecot-2.0.beta6 sometimes terminates client connections and reports these
>> errors:
>> Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
>> offset=6216579): msg header has bad magic value
>> Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
>> offset=6216579):
The quota plugin in 2.0.beta6 leaks 2KB "quota settings" pools. Here is a
patch to plug this leak, assuming you intended the caller of quota_init to
retain ownership of the quota_set. If on the other hand you intended for
quota_init to assume ownership of the quota_set, then the quota_settings
> Current implementation checks how many hard links are left for the hash
I haven't followed all the details and speculation, but this talk of
hard-linking makes me wonder how SIS will work with mail stores spread across
multiple file systems.
> That being the case I'd avoid the word "virtual". It seems we also want to
> avoid the word "home".
+1. "Virtual" implies it's only for virtual users. "Home" means $HOME.
> So I see logic in calling it the "user state directory" which could be
> "userdir" for short.
"Userdir" may still imp
> attachments/ha/sh/hash-guid, which is a hard link to:
> attachments/ha/sh/hashes/hash
If I store, say, all students' mail directories on one file system, and all
teachers' mail on another, will your SIS store one copy of each attachment, or
one copy per file system?
> 1. What hash algorithm to use?
> 2. Should I add support for trusting hash uniqueness
Use two hash functions and concatenate the hashes. While both hash systems may
eventually be hacked it is unlikely that hacking them will result in a targeted
alias.
There is a roff typo in pigeonhole's sievec.1.in. Roff treats the leading
apostrophe on line 54 as an invalid command and produces bad output:
dump to be written to stdout. The out-file argument may
also be omitted, which has the same effect as for a com-
Sometimes dovecot-2.0 sends this untagged response to clients:
* OK Indexed -2147483648% of the mailbox, ETA 0:00
I imagine there's a bug in there somewhere.
When might deduplication of attachments work with maildir?
How can a dovecot-2 plugin safely use file-locks or file-dotlocks when the
processes into which it plugs handle multiple connections? (Via, e.g.,
service imap {
client_limit = N
service_count = 0
})
Dovecot's file-locks and file-dotlocks do not appear to support
nesting/recursion.
For insta
Dovecot-2.0.3 reported:
Error: Maildir: Found unwanted directory /path/to/mail/user/cur/:2,FST, but
rmdir() failed: Directory not empty
and sure enough, this directory really does exist and contain a valid message
file:
# cd /path/to/mail/user/cur/
# ls -lR
total 384
drwx-- 8 vmail vmai
Hm, I found more revealing errors after sending that message. These are
scrubbed a little differently, to show two user names:
imap(pid 5720 user user1): Error:
open(/path/to/mail/user2/tmp/1285336854.M157825P5720.my.mail.server) failed: No
such file or directory
imap(pid 5720 user user1): Err
Perhaps related to the other errors I just reported, I also see a few of these
in the dovecot-2.0.3 logs:
lda(pid 8212 user user3): Error: Opening INBOX failed: Mailbox doesn't exist:
INBOX
lda(pid 8212 user user3): msgid=<201009240906510365.1gj1fpfhrh...@mail>: save
failed to INBOX: Mailbox doe
> So are you saying that this directory was actually created by Dovecot?
Yes. No migration, no Courier.
> Are these easy to reproduce?
Yes, on my system. I'll try imaptest.
> user1 is accessing user2's INBOX?
Not intentionally. User1 and user2 happen to be logged in at the same time and
w
>> lda(pid 8212 user user3): Error: Opening INBOX failed: Mailbox doesn't
>> exist: INBOX
>> [...]
>> tag NO Mailbox doesn't exist: INBOX
>
> For newly created users that don't have the Maildir directory created
> yet?
No, for users who already have their Maildir.
> This is with Maildir++ quota
> imaptest logout=1 clients=4
> imaptest logout=1 user=tss2 box=shared/tss/INBOX clients=4
Yes, I can reproduce this assertion failure:
Panic: file maildir-save.c: line 79 (maildir_file_move): assertion failed:
(*mf->tmp_name != '\0')
with:
imaptest clients=60 user=user\%d pass=test no_tracking l
> I'll try to narrow it down further (nix the search, turn off quotas, etc.).
imaptest clients=60 user=user\%d pass=test no_tracking logout=25 copybox=Copies
does it too... (no search commands)
And it happens with zero mail_plugins everywhere.
But this does not trip that assertion:
imaptest clie
Seems related to maildir_copy_hardlink(). No crashes with
maildir_copy_with_hardlinks=no.
> What about just:
>
> imaptest clients=10 user=user1 pass=test no_tracking logout=0 copybox=Copies
No crashes this way. It seems to need the different users.
> This is with v2.0.3 release, not hg?
Correct, 2.0.3 plus your asserts from this thread.
> --enable-devel-checks
Doh, that's what I
> Oh, interesting.. What about if you run it with two users?
With two users that same assertion trips. One user runs fine.
> Wonder if attached patch fixes it.
Yes. Thanks!
Dovecot-1.1.15 assert-fails frequently. Attached are some errors from
the logs, and a stack trace from the common panic. Hope you can fix
these soon. Thanks.
0 libSystem.B.dylib 0x7fff8825e606 __kill + 10
1 libSystem.B.dylib 0x7fff882e1c92 ab
Enclosed please find a patch to dovecot-1.1.16 that fixes a common
problem we see under load on Mac OS X and HFS+.
The symptom is that sometimes readdir() returns EINVAL. The problem
is that readdir() and rename() don't mix well, and maildir_scan_dir()
renames messages from new/ to cur/.
Either there's a bit stranger bug
It appears to be related to the readdir()-returns-EINVAL issue.
Fixing that stopped the assertion from failing.
There is still lots of "noise" in the log though. The attached perl
script just sends and retrieves mail over and over:
$ ./dere.pl --iteratio
Is that a normal HFS+ filesystem?
Yup.
Anything special done to it?
Nope.
With case-insensitive filenames?
Yup.
Have you tried my imaptest tool (http://imapwiki.org/ImapTest) to
see if it gives errors?
I'll try that soon and let you know.
BTW. Is there some really easy way to get
Moving a large number of messages into an IMAP folder on a dovecot
server takes quite a long time. This is a popular operation for users
migrating their stored messages from their old mail servers through a
mail user agent, and it causes a poor first impression of dovecot.
I'd like your h
did you already try maildir_very_dirty_syncs=yes
Yes. It has no effect on the behavior I observe.
What can be done to make maildir_uidlist_refresh_fast_init() choose
the fast path more often?
Pretty simple bug. Fixed:
http://hg.dovecot.org/dovecot-1.2/rev/ebdba086e3b1
This makes the performance pretty good when appending to maildirs with
large number of messages.
Sure does! Thanks, that
Howdy, dovecot-2.0.alpha2 doesn't compile on Mac OS X.
First, trivially, there's a typo in array.h:
--- a/src/lib/array.h 2009-10-08 10:04:35.0 -0500
+++ b/src/lib/array.h 2009-10-27 10:35:58.0 -0500
@@ -72,7 +72,7 @@
(elem)++)
# define array_foreach_modifiable(
Thanks, fixed. But why is your compiler taking that code path?
#if (defined(__STDC__) && __STDC_VERSION__ >= 199901L)
For whatever reason, __STDC_VERSION__ isn't defined. __STDC__ is
though.
Second, Mac OS X can't link loadable modules against other loadable
modules (http://www.finkproje
1. My earlier patch to fix a typo in array.h was not good enough.
Here's one that not only compiles, but also doesn't crash:
--- dovecot-2.0.alpha2/src/lib/array.h 2009-10-08 10:04:35.0
-0500
+++ dovecot/src/lib/array.h 2009-10-29 20:47:47.0 -0500
@@ -72,8 +72,7 @@
This time using maildir instead of mdbox.
Fri Oct 30 21:08:16 server dovecot[27407]: lda(pid 27407 user userW):
Panic: file istream.c: line 104 (i_stream_read): assertion failed:
((size_t)ret+old_size == _stream->pos - _stream->skip)
0 libSystem.B.dylib 0x7fff875f4eba
Fri Oct 30 21:08:16 server dovecot[27407]: lda(pid 27407 user
userW): Panic: file istream.c: line 104 (i_stream_read): assertion
failed: ((size_t)ret+old_size == _stream->pos - _stream->skip)
i.e. was the input stream seekable?
Postfix's pipe process invoked dovecot-lda so no, the input str
Just saw this new twist to an issue I reported last week with
dovecot-2.0.alpha2. I logged into an IMAP account using telnet to
port 143. After 30 seconds dovecot closed the connection.
Mon Nov 2 16:00:07 server dovecot[52355]: imap: dup2(-1, 5) failed:
Bad file descriptor
Mon Nov 2 16:
When playing with large numbers of IMAP keywords on dovecot-1.2.6 imap
crashed:
Panic: pool_data_stack_realloc(): stack frame changed
Looks like either maildir_file_do() shouldn't T_BEGIN/T_END or the
keywords array should start larger.
0 libSystem.B.dylib 0x7fff875
Or 3) don't use data stack for them at all:
http://hg.dovecot.org/dovecot-1.2/rev/939edf3ed09b
Yeah, that works too :). Thanks.
The mdbox_rotate_size and mdbox_rotate_min_size parameters are
specified in bytes not kilobytes.
doc/example-config/conf.d/mail.conf:
# Maximum dbox file size in kilobytes until it's rotated.
#mdbox_rotate_size = 2048
# Minimum dbox file size in kilobytes before it's rotated
# (overrides mdbox
Dovecot-2.0.alpha3 crashes on startup for me on Mac OS X. It hits a
segmentation fault at:
0 libdovecot.0.dylib 0x000100025e9f
master_service_set_die_with_master + 10
1 libdovecot.0.dylib 0x000100025d93
master_service_settings_read + 1818
2 libdo
When I set this in master.conf:
service imap {
service_count = 5
}
I see this error when two imap users log in:
Nov 11 16:54:16 server dovecot[5432]: imap-login: Login: user=,
method=PLAIN, rip=10.100.0.84, lip=10.80.0.163, pid=5573
Nov 11 16:54:31 server dovecot[5432]: imap-login: L
Dovecot-2.0.alpha3's imap-login segfaulted with this backtrace:
0 hex_to_binary
1 master_send_request
2 anvil_input
3 io_loop_handler_run
4 io_loop_run
5 master_service_run
6 main
7 start
Looks to me like auth_client_get_cookie() returned NULL in
master_send_request().
>> 3. imap crashed when using mdbox:
>> Fri Oct 30 14:54:49 server dovecot[11491]: imap(pid 11938 user userZ):
>> dbox /Volumes/Mail/userZ/mailboxes/INBOX/Sent/dbox-Mails: map
>> uidvalidity mismatch (1256918863 vs 1256919073)
>
> I'll look at this later. Although could it be HFS+ related pro
In dovecot-2.0.alpha3, setting "ssl_ca_file = /path/to/file" in conf.d/ssl.conf
does not work, because imap-login chroots before opening the ca_file. Perhaps
this parameter could be replaced with "ssl_ca =
> Hmm. How do people use the ssl_ca_file in general? Does it have only a
> single CA (or a couple) or does is it some huge file?
I don't know about other people, but I have only ever used single-entry CA
files.
--- a/src/lib-storage/mail-storage-service.c
+++ b/src/lib-storage/mail-storage-service.c
@@ -269,7 +269,7 @@
}
}
if (*set->mail_privileged_group != '\0') {
- if (!parse_uid(set->mail_privileged_group,
&rset.privileged_gid))
+ if (!parse_
I'm pleased to see that dovecot-2.2 includes support for RFCs 4467 and 4469
(URLAUTH and CATENATE). I have begun testing these features (in dovecot-2.2.1)
and comparing their functionality against Apple's implementation. So far I
have discovered a few inconsistencies. I will report each of th
Dovecot-2.2.1 does not appear to support URLs specified via non-synchronizing
literals (RFC 2088 LITERAL+), and also does not read and discard the literal+
input after reporting the error. This results in the literal+ input being
interpreted as IMAP commands, which could alter the user's mail s
Dovecot-2.2.1 allows empty messages to be APPENDed when using CATENATE:
b1 append inbox catenate (text {0+}
)
b1 OK [APPENDUID 1366726248 12] Append completed.
Contrast this with regular APPEND:
b2 append inbox {0+}
b2 NO Can't save a zero byte message.
Note that zero-size literals are OK bu
Something ate an important leading space from my message.
> b3 append inbox catenate (text {0+}
> text {8+}
> foobar
> )
> b3 OK [APPENDUID 1366726248 13] Append completed.
There was and should be a single space before the "text {8+}" above.
> Dovecot-2.2.1 does not appear to support URLs specified via non-synchronizing
> literals
Or synchronizing literals either:
b2 append inbox catenate (url {8}
b2 BAD Error in IMAP command APPEND: Invalid arguments.
Although the consequences of this are less severe since clients should send no
In dovecot-2.2.1 neither the SELECT nor the EXAMINE commands include an
untagged URLMECH reply. (Note, this is not the one mandated by the RESETKEY
command.)
AFAICT RFC 4467 does not require an URLMECH reply to SELECT or EXAMINE but
without it clients have no way of knowing about authorization
Dovecot-2.2.1's imap processes crash reliably when they use an IMAP URL with an
invalid access specifier. A backtrace and some debug output follows. The
crash is likely caused by imap_urlauth_fetch_parsed() returning 0 without
having set *mpurl_r to NULL, and then imap_urlauth_fetch_local() fr
It's the inconsistency that bothers me. Plain old APPEND doesn't allow empty
messages but CATENATE does?
Testing URLAUTH in dovecot-2.2.1 plus Timo's recent CATENATE and URLAUTH fixes
eventually trips some assertions. No simple sequence of commands always hits
these; they appear to be timing-dependent.
The first one is:
May 02 17:47:17 imap(pid 50490 user submit): Panic: file imap-client.c: line
Dovecot-2.2.1 plus Timo's recent CATENATE and URLAUTH fixes mishandles literals
after bad URLs. (As before remember that the "foobar" text below is really
"foobarCRLF" hence the length of 8. Also, last time some MTA discarded an
important single leading space character in the snippet I quoted
Dovecot-2.2.1 does not appear to support URLs specified via
non-synchronizing literals
>
> http://hg.dovecot.org/dovecot-2.2/rev/8e5ff6809d75 should fix this
Looks better, thanks.
>> CATENATE with no message parts works but, IMO, shouldn't:
>>
> Changed: http://hg.dovecot.org/dovecot-2.2/rev/5e2fa592c268
Confirmed. Thanks.
>> without having set *mpurl_r to NULL
>
> Right, fixed: http://hg.dovecot.org/dovecot-2.2/rev/24aa10efe132
That fixes it, thanks, but I wonder if it's incomplete? I notice that these
also sometimes don't set *mpurl_r:
imap_msgpart_url_create()
imap_msgpart_url_parse()
imap_urlauth_fetch()
Tha
> Both of these are fixed in hg.
Confirmed. Thanks. I have no more major issues with URLAUTH at this time.
> I fixed the most obvious places in hg
Thanks. Unfortunately CATENATE still fails for me in various ways. I'm trying
to isolate test cases.
Attached please find a perl script which tests the CATENATE support in dovecot.
I used this to test my CATENATE implementation a few years ago and it runs
fine against dovecot in OS X Server. When run against dovecot-2.2.4 though it
always fails or hangs, which in some cases means we interpret
> Do you think you might re-submit the matching BURL support to Postfix?
I don't think re-submitting is a good idea unless Wietse & co. request it,
which I doubt will happen.
> x append inbox catenate (url ;invalid; url {5}
>
> Dovecot replies with "+ OK" because it wants to read all the URLs into memory
> before parsing them, while catenate.pl expects an error message immediately.
I see that Example 4 in Appendix A of RFC 4469 explicitly allows both models.
Here's
In 2.2.5 and earlier it appears that mailbox_keywords_unref(&keywords) is not
called in some return paths from cmd_append_handle_args(). Should it be?
> default_fields = home=/Library/Server/Mail/Data/mail/%u
Try:
default_fields = home=/Library/Server/Mail/Data/mail/users/%u
> (You don't you have any thoughts only getting replication to ignore the
> “submit” user, do you?)
Just remove it from your config and disable urlauth. That will also fix the
security hole you opened when you sent your submit user's password to the list
:).
> how [FTS indexing] could be improved for everyone in future
For sites which set client_limit > 1 it would help performance not to stall for
INDEXER_WAIT_MSECS when polling the indexer for input. Currently dovecot
unwinds back out to the main command loop repeatedly to allow other clients to
> Do you think [moving IMAP IDLE connections to a separate imap-idle process]
> would work for you also?
Probably. It always depends on the details. Forking a new imap process every
time there's a little input to read or output to send might perform poorly
under load. Having a pool of ready
In traversing this thread I see a few different issues being reported. In no
particular order I see:
[Nicholas Riley]
> iOS Mail still opens lots of simultaneous IMAP connections, eventually
> complains about not being able to contact the server, and doesn't seem to do
> anything that uses Dov
101 - 176 of 176 matches
Mail list logo
