Re: [Dovecot] Disable/patch iOS7 Full Body Search
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 Dovecot's search indexes. This seems to have nothing to do with searching per se but it's hard to tell anything without thorough steps to reproduce the issue and/or detailed activity logs. Packet traces capturing all traffic between the client and the server during such an episode would be helpful. (Limited to the issue at hand though. A huge dump of hours of traffic would not be useful. Beware revealing private information.) And if you suspect that your clients are hitting your mail_max_userip_connections setting why not just increase it? [http://blog.fastmail.fm/2013/09/17/ios-7-mail-app-uses-multi-folder-body-searches-by-default/] Depending on your IMAP server, your message bodies may or may not be indexed in a way that allows sub-string searching. RFC 3501 section 6.4.4 unequivocally requires substring matches: In all search keys that use strings, a message matches the key if the string is a substring of the field. I would suggest that an IMAP server whose search indexes don't support efficient substring matches is misconfigured. Imagine a server which indexes only occurrences of the word potato. Would you be surprised when it performs poorly when searching for other foods? [https://discussions.apple.com/thread/5323188] Apple turned all server-side email searching into a slow and inefficient entire msgs substring search Personally I consider searching message bodies a feature. Anecdotally it works great for me with my iOS device and personal mail accounts. But again, server-side searching is only slow and inefficient in the absence of a properly configured search subsystem. Note these (dated, but still relevant) documents: [http://wiki2.dovecot.org/Plugins/FTS/Solr] * break-imap-search : Use Solr also for indexing TEXT and BODY searches. This makes your server non-IMAP-compliant. (This is always enabled in v2.1+) [http://wiki2.dovecot.org/Plugins/FTS/Squat] By strictly reading the IMAP RFC it requires substring matching, so to optimize regular TEXT and BODY searches you must use Squat with Dovecot v2.0.
Re: [Dovecot] Full text search improvements
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 use the process but it also stalls the whole process for INDEXER_WAIT_MSECS every time it finds no input from the indexer, which hurts responsiveness for those other clients. This can be avoided by removing the client's I/O from the main ioloop and adding the indexer's instead, or perhaps by leveraging CLIENT_COMMAND_STATE_WAIT_EXTERNAL. Third-party FTS implementations may benefit from having the NOT/AND/OR seq_range_array merging logic in squat_lookup_arg() generalized and made available to all. It would also be helpful if FTS expunge were asynchronous, but this is not critical.
Re: [Dovecot] Full text search improvements
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 imap processes could help that, when the configuration permits (e.g. all mail owned by one uid). It would be interesting to compare client_limit 1 vs. an idle connection aggregator. What's so evil about client_limit 1 besides requiring one uid, the indexer polling I mentioned, and broken fcntl-style file locks? Or is that enough?
Re: [Dovecot] Replication (Mac OS X)
(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 :).
[Dovecot] keywords leak in cmd_append_handle_args()
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?
Re: [Dovecot] script to test CATENATE
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 a patch to catenate.pl to expect dovecot-2.2's behavior.
catenate-patch
Description: Binary data
Re: [Dovecot] script to test CATENATE
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.
[Dovecot] script to test CATENATE
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 interpreted RFCs
differently and in other cases means it's finding bugs; both conditions are
worthy of scrutiny. (It's random-number driven so every run is different.) A
couple months ago I reported a few simple bugs which this script found and you
fixed them; thanks. Then it started finding problems for which it's harder to
isolate simple reproducible test cases. Vacations and other work interceded
but now Apple is pleased to give you the script itself to allow you to iterate
faster.
Here are some examples of it running. One time only, pass the --init argument
to store some template messages used by the real tests:
$ ./catenate.pl --host your.test.server --user testuser --password 1234 --init
connecting (imaps)...
capability...
logging in...
deleting old templates mailbox...
creating templates mailbox...
append1...
Append succeeded
append2...
Append succeeded
logout...
success
$ ./catenate.pl --host your.test.server --user testuser --password 1234
connecting (imaps)...
capability...
logging in...
append1...
Append failed as it should have (bad url): append1 NO [BADURL ;invalid;]
Invalid IMAP URL: Unexpected IMAP URL path segment: `;invalid;'.
append2...
Append failed as it should have (bad url): append2 NO [BADURL
/inbox/;uid=] Message not found.
append3...
Append succeeded
[...]
All tests passed.
$
If it concludes with anything other than All tests passed or hangs then it
found something that it didn't expect and that should be examined. Use the
--verbose option to see the entire client-server conversation.
We hope that you find this script helpful to harden your CATENATE code. I will
be happy to answer any questions.
#!/usr/bin/perl
# Test CATENATE support in dovecot.
# Use --init to initialize the template files in the mail store.
# Copyright (c) 2013 Apple Inc. All Rights Reserved.
#
# @APPLE_LICENSE_HEADER_START@
#
# This file contains Original Code and/or Modifications of Original Code
# as defined in and that are subject to the Apple Public Source License
# Version 2.0 (the 'License'). You may not use this file except in
# compliance with the License. Please obtain a copy of the License at
# http://www.opensource.apple.com/apsl/ and read it before using this
# file.
#
# The Original Code and all software distributed under the License are
# distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT. Please
# see the License for the specific language governing rights and
# limitations under the License.
#
# @APPLE_LICENSE_HEADER_END@
use strict;
use IO::Socket::INET;
use Getopt::Long;
use IPC::Open3;
use Digest::HMAC_MD5;
use APR::Base64;
use feature 'state';
sub usage
{
die EOT;
Usage: $0 --host imap-server --user name --password pw
Options:
--appends n number of APPENDs
--bufsiz n output buffer size
--buftag tag output buffer flushes
--init initialize template messages
--mailbox box append messages to this mailbox
--messages n messages per MULTIAPPEND
--parts n parts per message
--quiet
--select box select this mailbox before appending
--select-size n virtual size of message with UID=1 in selected mailbox
--store path path to mail store for the user
--verbose
EOT
}
my %opts;
GetOptions(\%opts,
'appends=i',
'bufsiz=i',
'buftag',
'host=s',
'init',
'mailbox=s',
'messages=i',
'parts=i',
'password=s',
'quiet',
'select=s',
'select-size=i',
'store=s',
'user=s',
'verbose',
) || usage();
$opts{appends} = 1000 unless defined($opts{appends});
usage() unless $opts{host};
$opts{mailbox} = INBOX unless defined($opts{mailbox});
usage() unless $opts{user};
usage() unless $opts{password};
if (defined($opts{select}) !defined($opts{'select-size'})) {
print STDERR --select needs --select-size\n;
usage();
}
my $checksizes = 0;
if (defined($opts{store})) {
my $myhost = `hostname`;
chomp $myhost;
if ($opts{host} eq 'localhost' or $opts{host} eq $myhost) {
$checksizes = 1;
} else {
die must run on server to check sizes\n;
}
}
$| = 1;
# These must match the constants in cmd-append.c (dovecot 2.2).
# Change both copies (cmd-append.c and here) for better testing coverage.
# Not sure if these apply to dovecot = 2.2.
my $MAX_URL_LITERAL_SIZE = 2048; # for testing: 20
my $MAX_CATENATE_MSG_SIZE = 4294967295; # for testing: 800
my $MAX_CATENATE_PARTS = 50; # for testing: 6
my $smallbody ='EOT';
Subject: small test message
Date: Thu, 03 Sep 2009 21:37:10 -0500 (CDT)
From:
Re: [Dovecot] URLAUTH assertion failures in 2.2.1
Both of these are fixed in hg. Confirmed. Thanks. I have no more major issues with URLAUTH at this time.
Re: [Dovecot] CATENATE mis-reads literal after bad URL
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.
Re: [Dovecot] CATENATE allows empty messages
It's the inconsistency that bothers me. Plain old APPEND doesn't allow empty messages but CATENATE does?
[Dovecot] URLAUTH assertion failures in 2.2.1
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 643 (client_command_free): assertion failed: (client-output_cmd_lock == NULL) The line number doesn't match dovecot-2.2.1 due to Apple's unrelated modifications. 0 libsystem_kernel.dylib 0x7fff8a9f7d4a __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff8f728705 pthread_kill + 92 2 libsystem_c.dylib 0x7fff8f48b17b abort + 125 3 libdovecot.0.dylib 0x00010db8d2bb default_fatal_finish + 68 4 libdovecot.0.dylib 0x00010db8df66 i_internal_error_handler + 0 5 libdovecot.0.dylib 0x00010db8d53d i_panic + 158 6 imap0x00010da468fe client_command_free + 446 7 imap0x00010da47a33 client_output_cmd + 37 8 imap0x00010da46497 client_output + 143 9 libdovecot.0.dylib 0x00010dba5610 stream_send_io + 53 10 libdovecot.0.dylib 0x00010db9bc74 io_loop_call_io + 46 11 libdovecot.0.dylib 0x00010db9cc85 io_loop_handler_run + 214 12 libdovecot.0.dylib 0x00010db9be1f io_loop_run + 77 13 libdovecot.0.dylib 0x00010db5b0c6 master_service_run + 24 14 imap0x00010da4fa66 main + 1010 15 libdyld.dylib 0x7fff8f7887bd start + 1 The second one is: May 02 19:23:29 imap(pid 60229 user mja): Panic: file index-mail.c: line 1274 (index_mail_close_streams_full): assertion failed: (!mail-data.destroying_stream) 0 libsystem_kernel.dylib 0x7fff8a9f7d4a __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff8f728705 pthread_kill + 92 2 libsystem_c.dylib 0x7fff8f48b17b abort + 125 3 libdovecot.0.dylib 0x0001054c42bb default_fatal_finish + 68 4 libdovecot.0.dylib 0x0001054c4f66 i_internal_error_handler + 0 5 libdovecot.0.dylib 0x0001054c453d i_panic + 158 6 libdovecot-storage.0.dylib 0x0001053aaebb index_mail_close_streams_full + 199 7 libdovecot-storage.0.dylib 0x0001053aaf29 index_mail_close + 44 8 libdovecot-storage.0.dylib 0x0001053ab6bd index_mail_free + 48 9 libdovecot-storage.0.dylib 0x00010538a19a mail_free + 15 10 libdovecot-storage.0.dylib 0x0001053dd3b3 imap_msgpart_url_free + 65 11 imap0x00010532d563 imap_urlauth_fetch_abort_local + 30 12 imap0x00010532cb96 imap_urlauth_fetch_abort + 38 13 imap0x00010532cb54 imap_urlauth_fetch_deinit + 24 14 imap0x0001053218bd cmd_urlfetch_finish + 45 15 imap0x000105321aa3 cmd_urlfetch_continue + 167 16 imap0x000105323ef8 command_exec + 55 17 imap0x000105323a20 client_output_cmd + 18 18 imap0x000105322497 client_output + 143 19 libdovecot.0.dylib 0x0001054dc610 stream_send_io + 53 20 libdovecot.0.dylib 0x0001054d2c74 io_loop_call_io + 46 21 libdovecot.0.dylib 0x0001054d3c85 io_loop_handler_run + 214 22 libdovecot.0.dylib 0x0001054d2e1f io_loop_run + 77 23 libdovecot.0.dylib 0x0001054920c6 master_service_run + 24 24 imap0x00010532ba66 main + 1010 25 libdyld.dylib 0x7fff8f7887bd start + 1
[Dovecot] CATENATE mis-reads literal after bad URL
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 so this time
I'm prefixing all the lines to avoid that. In case it's lost again, there's a
space before the word url below.)
| b append inbox catenate (text {8}
| + OK
| foobar
| url /a-bad-url text {8}
| b NO [BADURL /a-bad-url] Invalid messagepart IMAP URL.
| c noop
| d noop
| d OK NOOP completed.
| e logout
| * BYE Logging out
| e OK Logout completed.
Note that the command with tag c is lost. I think it shouldn't be, because
the NO was reported to the client without sending a continuation (+ OK) so the
client knows not to send the literal. Plus it appears only one line is
discarded regardless of the size of the literal.
Re: [Dovecot] CATENATE doesn't support literal+ url
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.
Re: [Dovecot] CATENATE allows zero parts
CATENATE with no message parts works but, IMO, shouldn't: Changed: http://hg.dovecot.org/dovecot-2.2/rev/5e2fa592c268 Confirmed. Thanks.
Re: [Dovecot] imap crash during URLFETCH
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() That last one in particular is called from imap_urlauth_fetch_local() in the same way as the one you fixed.
[Dovecot] CATENATE allows zero parts
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 these, and any more that I may find, in separate threads. The first issue is that using CATENATE with no message parts works but, IMO, shouldn't: a2 append inbox catenate () a2 OK [APPENDUID 1366726248 9] Append completed. For comparison this is how Apple's enhanced dovecot in OS X Server handles this request: a2 append inbox catenate () a2 BAD Invalid arguments. According to RFC 4469 section 3 CATENATE requires one or more message parts. This is formalized in section 5: append-data =/ CATENATE SP ( cat-part *(SP cat-part) ) and in RFC 3501 section 9 which states that [ABNF] rules MUST be followed strictly. I believe that permitting zero cat-parts is contrary to the RFC, although I can understand permitting it under the general doctrine of servers should be liberal in what they accept, and clients strict in what they send. Is accepting zero cat-parts an intentional exception to the RFC or an oversight?
[Dovecot] CATENATE doesn't support literal+ url
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 store in
unexpected ways and/or lead to the abrupt disconnection of the client for
exceeding the maximum number of bad IMAP commands.
Example using dovecot-2.2.1 (note that the text nonsync literal includes the
invisible CRLFs: foobarCRLFbarbazCRLF):
a3 append inbox catenate (url {9+}
/some-url text {16+}
foobar
barbaz
)
a4 noop
a3 BAD Error in IMAP command APPEND: Invalid arguments.
foobar BAD Error in IMAP command : Unknown command.
barbaz BAD Error in IMAP command : Unknown command.
) BAD Error in IMAP command : Unknown command.
a4 OK NOOP completed.
Example using Apple's enhanced dovecot in OS X Server:
a3 append inbox catenate (url {9+}
/some-url text {16+}
foobar
barbaz
)
a4 noop
a3 NO [BADURL /some-url] missing or invalid uid
a4 OK NOOP completed.
I believe the RFCs indicate that nonsync literal URLs should be permitted.
RFC 4469 section 5:
append-data =/ CATENATE SP ( cat-part *(SP cat-part) )
cat-part = text-literal / url
url = URL SP astring
RFC 3501 section 9:
astring = 1*ASTRING-CHAR / string
string = quoted / literal
RFC 2088 section 4:
literal ::= { number [+] } CRLF *CHAR8
[Dovecot] CATENATE allows empty messages
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 but zero-size messages are not. So while
b1 above should fail like b2, this should continue to succeed:
b3 append inbox catenate (text {0+}
text {8+}
foobar
)
b3 OK [APPENDUID 1366726248 13] Append completed.
Re: [Dovecot] CATENATE allows empty messages
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.
Re: [Dovecot] CATENATE doesn't support literal+ url
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
more data for that command after receiving the tagged response.
[Dovecot] SELECT/EXAMINE don't report URLMECH
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 mechanisms other than INTERNAL. Now I know dovecot-2.2 supports only the INTERNAL mechanism at present so this is probably harmless, but still I think it's worthwhile to ask: Is the absence of the URLMECH reply intentional or an oversight? For comparison Apple's enhanced dovecot replies: c1 select inbox [...] * OK [URLMECH INTERNAL] Mechanisms supported c1 OK [READ-WRITE] Select completed.
[Dovecot] imap crash during URLFETCH
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() freeing an uninitialized pointer. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x1059 0 libdovecot-storage.0.dylib 0x00010b06a383 imap_msgpart_url_free + 17 1 imap0x00010afc71cc imap_urlauth_fetch_local + 770 2 imap0x00010afc6dcf imap_urlauth_fetch_url + 439 3 imap0x00010afbb489 cmd_urlfetch + 580 4 imap0x00010afbdf4d command_exec + 55 5 imap0x00010afbdabb client_command_input + 34 6 imap0x00010afbdc7c client_command_input + 483 7 imap0x00010afbd351 client_handle_input + 239 8 imap0x00010afbc613 client_input + 119 9 libdovecot.0.dylib 0x00010b111c74 io_loop_call_io + 46 10 libdovecot.0.dylib 0x00010b112c85 io_loop_handler_run + 214 11 libdovecot.0.dylib 0x00010b111e1f io_loop_run + 77 12 libdovecot.0.dylib 0x00010b0d10c6 master_service_run + 24 13 imap0x00010afc5aba main + 1010 14 libdyld.dylib 0x7fff89e5f7bd start + 1 Apr 29 20:00:31 imap(pid 82429 user mja): Debug: Fetching local URLAUTH imap://m...@duck.example.com/INBOX;uidvalidity=1366726248/;uid=19;urlauth=submit+mja:internal:012c9c6a3d74db6509e4a3802a0f5edf64546608b8 Apr 29 20:00:31 imap(pid 82429 user mja): Debug: Failed to fetch URLAUTH imap://m...@duck.example.com/INBOX;uidvalidity=1366726248/;uid=19;urlauth=submit+mja:internal:012c9c6a3d74db6509e4a3802a0f5edf64546608b8: No 'submit+mja' access allowed for user mja Apr 29 20:00:31 imap(pid 82429 user mja): Fatal: master: service(imap): child 82429 killed with signal 11 (core dumps disabled)
[Dovecot] patch for crash while FTS-searching through virtual mailbox
FTS-searching through a virtual mailbox crashes dovecot-2.1.15 when the FTS
backend does not support lookup_multi.
src/plugins/fts/fts-api.h says for fts_backend_lookup() that The arrays in
result must be initialized by caller. FTS backends can therefore assume that
the arrays are initialized by their caller. However,
fts_backend_lookup_multi() does not initialize the per-box arrays before
calling the FTS backend’s lookup function. This patch fixes the resulting
crash.
--- dovecot-2.1.15/src/plugins/fts/fts-api.c2012-08-03 09:09:28.0
-0500
+++ dovecot/src/plugins/fts/fts-api.c 2013-02-28 14:35:43.0 -0600
@@ -337,8 +337,12 @@
result-box_results = p_new(result-pool, struct fts_result, i+1);
for (i = 0; boxes[i] != NULL; i++) {
+ struct fts_result *box_result = result-box_results[i];
+ p_array_init(box_result-definite_uids, result-pool, 32);
+ p_array_init(box_result-maybe_uids, result-pool, 32);
+ p_array_init(box_result-scores, result-pool, 32);
if (backend-v.lookup(backend, boxes[i], args,
- and_args, result-box_results[i]) 0)
+ and_args, box_result) 0)
return -1;
}
return 0;
Re: [Dovecot] error running indexer-worker as non-root user
http://hg.dovecot.org/dovecot-2.1/rev/6d45b9bd1cff fixes it Yes it does. Thanks.
Re: [Dovecot] patch to fix binary attachment indexing
Applied basically the same logic: http://hg.dovecot.org/dovecot-2.1/rev/b0e68c53771e Cool, thanks. I guess you're building a new fts backend? Just maintaining the one I already have.
[Dovecot] patch to fix binary attachment indexing
FTS indexing of binary attachments is broken in dovecot-2.1.15: the binary data which fts_build_mail_real() sends to fts_build_body_block() (which sends it to fts_backend_update_build_more()) is garbled. This patch ungarbles it but I’m not positive it’s the best fix. --- dovecot-2.1.15/src/plugins/fts/fts-build-mail.c 2012-11-27 02:07:27.0 -0600 +++ dovecot/src/plugins/fts/fts-build-mail.c2013-02-21 19:48:15.0 -0600 @@ -178,7 +178,8 @@ *binary_body_r = TRUE; key.type = FTS_BACKEND_BUILD_KEY_BODY_PART_BINARY; } - if (ctx-body_parser == NULL) + if (ctx-body_parser == NULL + key.type != FTS_BACKEND_BUILD_KEY_BODY_PART_BINARY) ctx-body_parser = fts_parser_text_init(); key.body_content_type = content_type; key.body_content_disposition = ctx-content_disposition;
[Dovecot] Ping re: error running indexer-worker as non-root user
Any hints about the issue I wrote about on Feb. 11? http://markmail.org/message/6g7itsu2u3fdnfkd Thanks.
[Dovecot] error running indexer-worker as non-root user
Using dovecot-2.1.15 if I run indexer-worker as a non-root user it fails with
an error:
Feb 11 13:06:47 indexer-worker: Error: user foobar: Error reading
configuration: net_connect_unix(/var/run/dovecot/config) failed: Permission
denied
This is what I added to 10-master.conf:
service indexer-worker {
user = _dovecot
}
The wiki says it should work:
http://wiki2.dovecot.org/Services
indexer-worker
[...]
• user=root, but the privileges are (temporarily) dropped to the mail
user's privileges after userdb lookup. If only a single UID is used, user can
be set to the mail UID for higher security, because the process can't gain root
privileges anymore.
And the code says it should work:
src/indexer/indexer-worker.c
static void drop_privileges(void)
{
[...]
if (set.uid != 0) {
/* open config connection before dropping privileges */
Of course the config socket is locked down as it should be:
srw--- 1 root daemon 0 Feb 11 13:06 /var/run/dovecot/config
Here's where the error comes from:
2 libdovecot.0.dylib 0x0001019612a0
master_service_settings_read + 2168
3 libdovecot.0.dylib 0x00010196193e
master_service_settings_cache_read + 294
4 libdovecot-storage.0.dylib 0x00010185d9ad
mail_storage_service_read_settings + 510
5 libdovecot-storage.0.dylib 0x00010185da5d
mail_storage_service_lookup + 96
6 libdovecot-storage.0.dylib 0x00010185f06a
mail_storage_service_lookup_next + 42
7 indexer-worker 0x0001018101a1
master_connection_input + 335
8 libdovecot.0.dylib 0x000101972455 io_loop_call_io + 46
9 libdovecot.0.dylib 0x00010197343e io_loop_handler_run
+ 214
10 libdovecot.0.dylib 0x000101972600 io_loop_run + 77
11 libdovecot.0.dylib 0x0001019601ef master_service_run +
24
12 indexer-worker 0x00010180ff17 main + 490
13 libdyld.dylib 0x7fff89d2f7b5 start + 1
Is this a bug or am I configuring it incorrectly? Thanks.
[Dovecot] MASTER_AUTH_MAX_DATA_SIZE
In 2.0.17 you increased LOGIN_MAX_INBUF_SIZE from 1024 to 4096. Should you also have increased MASTER_AUTH_MAX_DATA_SIZE from (1024*2) to (4096*2)? /* This should be kept in sync with LOGIN_MAX_INBUF_SIZE. Multiply it by two to make sure there's space to transfer the command tag */
[Dovecot] proxying, SSL, and client certificate
How do I configure dovecot-2.0.x to present a client SSL certificate when
proxying?
If dovecot on server1.example.com has:
passdb {
driver = static
args = proxy=y host=server2.example.com nopassword=y ssl=yes
}
and dovecot on server2.example.com has:
ssl_verify_client_cert = yes
auth_ssl_require_client_cert = yes
then when a client connects to server1 and authenticates, a connection is
established to server2 but the SSL handshake fails because server1 doesn't
present a client certificate. I don't see where ssl_client_ctx is tied to a
client certificate in ssl-proxy-openssl.c.
Thanks.
[Dovecot] another sizeof tweak
Line 776 of dovecot-2.0.15/src/lib-storage/index/maildir/maildir-sync-index.c
reads:
memcmp(old_rec, new_rec, sizeof(old_rec)) != 0) {
Should that be sizeof(*old_rec)?
[Dovecot] two little fixes for 2.0.14
--- a/dovecot/src/lib-index/mail-index-view.c
+++ b/dovecot/src/lib-index/mail-index-view.c
@@ -9,7 +9,7 @@
void mail_index_view_clone(struct mail_index_view *dest,
const struct mail_index_view *src)
{
- memset(dest, 0, sizeof(dest));
+ memset(dest, 0, sizeof(*dest));
dest-refcount = 1;
dest-v = src-v;
dest-index = src-index;
--- a/dovecot/src/lib-storage/mail-storage-service.c
+++ b/dovecot/src/lib-storage/mail-storage-service.c
@@ -870,7 +870,7 @@
}
user = p_new(user_pool, struct mail_storage_service_user, 1);
- memset(user_r, 0, sizeof(user_r));
+ memset(user_r, 0, sizeof(*user_r));
user-pool = user_pool;
user-input = *input;
user-input.userdb_fields = NULL;
Re: [Dovecot] URLAUTH-patch, BSD specific?
The file src/plugins/urlauth/urlauth-keys.c uses open(2) with O_EXLOCK, which to my knowledge is BSD specific. Thanks for catching that. I guess that code should change to open the file first and then lock it.
Re: [Dovecot] [Dovecot-news] v2.0.13 released
Compiling dovecot-2.0.13 on OS X emits these warnings:
user-directory.c: In function user_directory_add:
user-directory.c:79: warning: comparison between signed and unsigned
user-directory.c:84: warning: comparison between signed and unsigned
Casting the left hand sides of the comparisons to time_t, as you do in other
places, silences them:
--- a/src/director/user-directory.c 2011-05-11 09:35:21.0 -0500
+++ b/src/director/user-directory.c 2011-05-11 16:55:45.0 -0500
@@ -76,12 +76,12 @@
user-host-user_count++;
user-timestamp = timestamp;
- if (dir-tail == NULL || dir-tail-timestamp = timestamp)
+ if (dir-tail == NULL || (time_t) dir-tail-timestamp = timestamp)
DLLIST2_APPEND(dir-head, dir-tail, user);
else {
/* need to insert to correct position */
for (pos = dir-tail; pos != NULL; pos = pos-prev) {
- if (pos-timestamp = timestamp)
+ if ((time_t) pos-timestamp = timestamp)
break;
}
if (pos == NULL)
Re: [Dovecot] imaptest assertion failure
$ ./imaptest user=foo pass=bar host=localhost test=tests Error: connect() failed: No route to host I can't reproduce this connect() failure. Not in OSX or Linux. It has something to do with IPv6 or multiple aliases of localhost, for if I comment out this line in client_new() like so it runs fine: // if (++conf.ip_idx == conf.ips_count) FYI my /etc/hosts says: 127.0.0.1 localhost ::1 localhost fe80::1%lo0 localhost Anyway, I was trying to use imaptest to make a reproducible case for you to troubleshoot the dovecot-uidlist: Duplicate file entry warnings but with no joy yet. Do you have any hints as to what I should try next?
Re: [Dovecot] warnings from 2.0.11
imaptest logout=0 copybox=foo delete=10 expunge=10 clients=2 imaptest logout=0 copybox=INBOX box=foo delete=10 expunge=10 clients=2 Does that fail with you either? Ran both commands simultaneously for hours. No duplicate uid warnings.
Re: [Dovecot] warnings from 2.0.11
Well, saving a copy of dovecot-uidlist file would be useful in such situation. I added your patch to preserve dovecot-uidlist when reporting duplicate uids. Here are two examples with uidlist files attached. Mar 14 17:59:39 server dovecot[6698]: imap(pid 80181 user user272): Warning: /Volumes/Mail/user272/dovecot-uidlist: Duplicate file entry at line 110: 1300128056.M669920P7588.server.home.domain,S=970,W=993 (uid 93 - 193) Mar 14 18:41:41 server dovecot[6698]: imap(pid 80095 user user165): Warning: /Volumes/Mail/user165/dovecot-uidlist: Duplicate file entry at line 397: 1300132484.M237861P14283.server.home.domain,S=10873,W=11071 (uid 77 - 409) Also interesting would be to see if it makes a difference that uidlist is always rewritten rather than appended to. I did not apply that patch but can if you still think it would be interesting or helpful. uidlist.0165.80095.1300146100.938647 Description: Binary data uidlist.0272.80181.1300143579.258975 Description: Binary data
Re: [Dovecot] warnings from 2.0.11
Maybe it has to do with the number of mails in the mailbox? Clever thought, but while some of the users receiving the warnings have 30k messages, others have only a few hundred. msgs=1 delete=10 expunge=10 Five hours running, no warnings. Any other thoughts?
Re: [Dovecot] warnings from 2.0.11
What kind of a test are you doing that causes these warnings? A stress test which manipulates messages via IMAP fetch, copy, search, append, store flags, expunge, etc. and also sends mail via SMTP. I'll try to narrow down if there's a specific command which triggers it, or if dovecot-lda does, or what. Meanwhile I would welcome your educated guesses as to where to look.
Re: [Dovecot] warnings from 2.0.11
Can you easily reproduce this by running imaptest against a single user? Nope. Any special imaptest arguments other than user=... pass=... host=... mbox=...? I ran it for a few hours with none of the warnings.
[Dovecot] warnings from 2.0.11
During a stress test dovecot-2.0.11 logs many warnings: Mar 8 06:19:52 gromit dovecot[59204]: imap(pid 68864 user user15): Warning: /Volumes/Mail/user15/dovecot-uidlist: Duplicate file entry at line 183: 1299556557.M571530P31883.gromit.example.com,S=21175,W=21549 (uid 67 - 250) Mar 8 06:20:10 gromit dovecot[59204]: imap(pid 68865 user user34): Warning: /Volumes/Mail/user34/dovecot-uidlist: Duplicate file entry at line 230: 1299535329.M679065P61136.gromit.example.com,S=11040,W=11247 (uid 17 - 240) Mar 8 06:20:10 gromit dovecot[59204]: imap(pid 68865 user user34): Warning: /Volumes/Mail/user34/dovecot-uidlist: Duplicate file entry at line 240: 1299535329.M902424P61136.gromit.example.com,S=12843,W=13075 (uid 30 - 250) Mar 8 06:20:10 gromit dovecot[59204]: imap(pid 68865 user user34): Warning: /Volumes/Mail/user34/dovecot-uidlist: Duplicate file entry at line 266: 1299547358.M587728P69303.gromit.example.com,S=13637,W=13772 (uid 108 - 276) Mar 8 06:20:10 gromit dovecot[59204]: imap(pid 68865 user user34): Warning: /Volumes/Mail/user34/dovecot-uidlist: Duplicate file entry at line 275: 1299558462.M498819P35210.gromit.example.com,S=15495,W=15663 (uid 160 - 285) Mar 8 06:20:11 gromit dovecot[59204]: imap(pid 68864 user user36): Warning: /Volumes/Mail/user36/dovecot-uidlist: Duplicate file entry at line 281: 1299535339.M353973P61136.gromit.example.com,S=4498,W=4581 (uid 360 - 604) Mar 8 06:21:00 gromit dovecot[59204]: imap(pid 68864 user user239): Warning: /Volumes/Mail/user239/dovecot-uidlist: Duplicate file entry at line 105: 1299547390.M813768P69393.gromit.example.com,S=4773,W=4861 (uid 22 - 164) Mar 8 06:21:00 gromit dovecot[59204]: imap(pid 68864 user user239): Warning: /Volumes/Mail/user239/dovecot-uidlist: Duplicate file entry at line 106: 1299570075.M267312P49194.gromit.example.com,S=8041,W=8181 (uid 115 - 165) Mar 8 06:28:24 gromit dovecot[59204]: imap(pid 69295 user user274): Warning: /Volumes/Mail/user274/dovecot-uidlist: Duplicate file entry at line 2020: 1299548064.M880781P67832.gromit.example.com,S=4976,W=5076 (uid 247 - 2500) Mar 8 06:29:23 gromit dovecot[59204]: imap(pid 68973 user user115): Warning: /Volumes/Mail/user115/dovecot-uidlist: Duplicate file entry at line 526: 1299537039.M676050P61136.gromit.example.com,S=2485,W=2534 (uid 8 - 1082) Mar 8 06:31:37 gromit dovecot[59204]: imap(pid 68971 user user114): Warning: /Volumes/Mail/user114/dovecot-uidlist: Duplicate file entry at line 667: 1299564058.M124508P40871.gromit.example.com,S=1187940,W=1207707 (uid 229 - 780) - retrying by re-reading from beginning Mar 8 06:32:14 gromit dovecot[59204]: imap(pid 68971 user user114): Warning: Maildir /Volumes/Mail/user114: Expunged message reappeared, giving a new UID (old uid=229, file=1299564058.M124508P40871.gromit.example.com,S=1187940,W=1207707:2,S) Mar 8 06:39:22 gromit dovecot[59204]: imap(pid 68911 user user105): Warning: Maildir /Volumes/Mail/user105: Synchronization took 155 seconds (0 new msgs, 0 flag change attempts, 585 expunge attempts) Is there anything I need to reconfigure to prevent these? Thanks.
Re: [Dovecot] Panic in 2.0.9 imap-client
Jan 17 12:06:20 server dovecot: imap(@YYY): Panic: file imap-client.c: line 570 (client_continue_pending_input): assertion failed: (!client-handling_input) I can reproduce this every time by sending any data in the same packet after the tag IDLECRLF. For instance using nc: $ nc localhost 143 ... login, etc ... x idle^M^Jfoo Where I generate ^M^J by typing ctrl-V ctrl-M ctrl-V ctrl-J.
Re: [Dovecot] Panic in 2.0.9 imap-client
I can't think of why any client would send IDLE+DONE in the same TCP packet. Maybe not in the same packet, but network congestion or server overloading could cause the IDLE and DONE to queue up together. Oh, that's nice. Glad to help. Fixed now: http://hg.dovecot.org/dovecot-2.0/rev/4741f1b4f9b3 Yes that does fix the crash. Thanks.
Re: [Dovecot] Panic in 2.0.9 imap-client
Jan 17 12:06:20 server dovecot: imap(@YYY): Panic: file imap-client.c: line 570 (client_continue_pending_input): assertion failed: (!client-handling_input) I just saw this with 2.0.8 too. Backtrace is: 0 __kill + 10 1abort + 177 20x10d928000 + 143594 30x10d928000 + 139194 4i_panic + 159 5client_continue_pending_input + 196 6cmd_idle + 188 7client_command_input + 36 8client_command_input + 416 9client_handle_input + 134 10 client_input + 118 11 io_loop_call_io + 70 12 io_loop_handler_run + 227 13 io_loop_run + 72 14 master_service_run + 27 15 main + 703 16 start + 52
Re: [Dovecot] Patch: 2.0 support for URLAUTH, BURL, CATENATE
On Dec 5, 2010, at 11:17 PM, Timo Sirainen wrote: I don't think there's any need to send anonymous_username to imap process? It just seems to want to know if the current user is anonymous or not. That same thing has been in my TODO list for a while already because ManageSieve could use that information too. So committed now: http://hg.dovecot.org/dovecot-2.0/rev/c41ba33b8e16 I just tried out this change and it does not replace the need for the anonymous_username field. I only now fully understand the comment: /* this is an anonymous login, either via ANONYMOUS SASL mechanism or simply logging in as the anonymous user via another mechanism */ Since the change does not distinguish between those two cases it breaks the authuser access identifier for the anonymous user when he is logged in non-anonymously. I would not really care about this edge case except that the contributed implementation requires that the username in the IMAP URL matches the authenticated user's username even for the anonymous and authuser access identifiers, in violation of RFC 4467 section 4. (The implementation requires a match because Dovecot does not (can not) reach into another user's mail storage.) This means that the anonymous and authuser access identifiers only work for the anonymous user in the implementation; your change makes the authuser access identifier always fail for the anonymous user. The anonymous_username field in the original contributed patch does distinguish between SASL ANONYMOUS and logging in as the anonymous user via another mechanism, so the anonymous and authuser access identifiers work properly for the anonymous user (but not for any other user). If you can teach me how to make urlfetch_url() access any user's mail storage from an IMAP process logged in as a different user (subject to OS uid/gid permission constraints), I can make anonymous and authuser work for all users and use your change instead of the anonymous_username field. Alternatively, you could edit your change to add the anonymous indication to the auth reply only for SASL ANONYMOUS authentications rather than for all anonymous-user authentications, unless that would cause trouble for ManageSieve.
Re: [Dovecot] Patch: 2.0 support for URLAUTH, BURL, CATENATE
It just seems to want to know if the current user is anonymous or not. http://hg.dovecot.org/dovecot-2.0/rev/c41ba33b8e16 OK, this looks plausible. Something similar could be done about submit_user too. Instead of sending submit_user=x, send both master_user=x and submit. We chose not to overload master_user=x in this way so that code/plugins that check master_user without knowing about or checking the submit flag don't behave incorrectly. Accidentally granting a mere submit user all of a master user's powers would be unsafe. We will be pleased to see these features added to 2.1.
Re: [Dovecot] Patch: 2.0 support for URLAUTH, BURL, CATENATE
when ACL plugin is loaded the master user by default has no permissions to any mailbox. But without the ACL plugin a master user has all of the regular user's access, including unlimited read/write/delete powers. Submit users don't because of COMMAND_FLAG_OK_FOR_SUBMIT_USER. So if some part of the code doesn't check for submit_user, it assumes the user itself logged in, which could be worse than assuming a master user logged in. Touché. Maybe master user should have been named something more neutral, like authentication user or something.. Please no, not that. Do you know how messy it is already to grep through the code for the words master and user? If you do change this name make it something new to dovecot, like chameleon or usurper or something.
[Dovecot] typo
Typo on line 292 of src/lib-master/master-login-auth.c in 2.0.8: tuah.
Re: [Dovecot] version_ignore=yes
Also note that because of a change in how (upcoming) v2.0.8 checks if imap/pop3/lmtp has been started from command line, version_ignore=yes is effectively always enabled for them when older master process is running. I don't understand this. Can you please elaborate? Thanks.
[Dovecot] auth crash in 2.0.3
Here's another one-off crash in dovecot-2.0.3's auth process. Looks like request-mech == NULL in auth_request_initial(). I don't see any obvious fixes to this code between 2.0.3 and 2.0.6 so it may still be present in 2.0.6. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0018 0 auth0x00010d89381b auth_request_initial + 85 1 auth0x00010d891844 auth_penalty_anvil_callback + 207 2 libdovecot.0.dylib 0x00010d8ea44f anvil_client_connect + 364 3 libdovecot.0.dylib 0x00010d8f77e9 io_loop_handler_run + 234 4 libdovecot.0.dylib 0x00010d8f82bb io_loop_run + 56 5 libdovecot.0.dylib 0x00010d8edf98 master_service_run + 27 6 auth0x00010d89b18a main + 674 7 auth0x00010d88ec14 start + 52 There were several Timeout waiting for handshake from auth server errors from imap-login and pop3-login in the minutes before this crash.
[Dovecot] imap can't reconnect to auth-master after setuid
With service imap { client_limit = 5, service_count = 0 }, when the auth
process crashes the existing imap processes cannot reconnect to the auth-master
socket because they have long ago dropped root privileges. Is the right
solution to this:
(1) change the perms on the auth-master socket so processes running as
vmail:vmail can connect to it, or
(2) change the code so that multi-client imap processes stop accepting new
clients when they notice an auth bounce?
If (1), the wiki should be updated to mention this.
Thanks.
[Dovecot] stats plugin + UID command continuation
When using the stats plugin for dovecot-2.0, UID commands that continue cause
infinite recursion and crash. For example, A22 UID FETCH 151 BODY[] when the
body is 3MB or so always crashes. For smaller messages, this command logs the
duration twice. Here is a patch to fix it:
--- stats-plugin.c.orig 2010-10-26 20:18:13.0 -0500
+++ stats-plugin.c 2010-10-26 20:19:10.0 -0500
@@ -197,6 +197,9 @@
commands = array_get_modifiable(imap_commands, count);
for (i = 0; i count; i++) {
+ if (strcasecmp(commands[i].name, UID) == 0)
+ continue;
+
hash_table_insert(orig_cmds, (char *)commands[i].name,
commands[i].func);
commands[i].func = stats_command;
[Dovecot] assertion failed: (auth_request_state_count[request-state] 0)
First time I've seen this with dovecot-2.0.5. At 10:05 my auth server was having problems and I saw this: Thu Oct 14 10:05:32 server dovecot[3536]: lda: Error: userdb lookup(userX): Request timed out Thu Oct 14 10:05:32 server dovecot[3536]: lda: Fatal: Internal error occurred. Refer to server log for more information. OK, no problem there. But a few minutes later this crash that may or may not be related: Thu Oct 14 10:09:39 server dovecot[150]: auth: Panic: file auth-request.c: line 78 (auth_request_set_state): assertion failed: (auth_request_state_count[request-state] 0) Here is a backtrace, unfortunately somewhat obfuscated by compiler optimization. 0 __pthread_kill + 10 1 pthread_kill + 95 2 abort + 143 3 i_set_failure_file + 274 4 i_set_failure_internal + 103 5 i_debug + 0 6 auth_request_initial + 0 7 auth_request_initial + 71 8 auth_penalty_anvil_callback + 207 9 anvil_client_connect + 364 10 io_loop_handler_run + 234 11 io_loop_run + 56 12 master_service_run + 27 13 main + 674 14 start + 52
[Dovecot] patch for mysterious maildir symlink error
This may resolve the mysterious Maildir: Symlink destination doesn't exist
errors.
--- a/src/lib-storage/index/maildir/maildir-util.c
+++ b/src/lib-storage/index/maildir/maildir-util.c
@@ -91,7 +91,7 @@
{
struct stat st;
- if (lstat(path, st) == 0 (st.st_mode S_IFLNK) != 0) {
+ if (lstat(path, st) == 0 (st.st_mode S_IFMT) == S_IFLNK) {
/* most likely a symlink pointing to a nonexistent file */
mail_storage_set_critical(mbox-storage-storage,
Maildir: Symlink destination doesn't exist: %s, path);
[Dovecot] unwanted maildir directory
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 vmail272 Sep 24 09:06 . drwx-- 13 vmail vmail442 Sep 24 09:06 .. -rw--- 5 vmail vmail 41045 Sep 24 08:44 1285336100.M879758P1166.my.mail.server,S=41045,W=41755:2,RST -rw--- 5 vmail vmail 41045 Sep 24 08:44 1285336100.M910424P1166.my.mail.server,S=41045,W=41755:2,RST -rw--- 5 vmail vmail 41045 Sep 24 08:44 1285336337.M656599P1166.my.mail.server,S=41045,W=41755:2,ST -rw--- 5 vmail vmail 41045 Sep 24 08:44 1285336355.M88818P1164.my.mail.server,S=41045,W=41755:2,FS -rw--- 1 vmail vmail 14953 Sep 24 09:00 1285336838.M483116P5720.my.mail.server,S=14953,W=15225:2, drwx-- 3 vmail vmail102 Sep 24 09:00 :2,FST ./:2,FST: total 88 drwx-- 3 vmail vmail102 Sep 24 09:00 . drwx-- 8 vmail vmail272 Sep 24 09:06 .. -rw--- 5 vmail vmail 41045 Sep 24 08:44 1285335855.M242128P1165.my.mail.server,S=41045,W=41755 # Dovecot must have created this non-Maildir++-ish directory, but why, why in cur/ not tmp/, and why didn't it clean it up? (Not the Directory not empty error specifically; I mean in the larger sense.)
Re: [Dovecot] unwanted maildir directory
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): Error: Maildir: Symlink destination doesn't exist:
/path/to/mail/user2/cur/1285336100.M879758P1166.my.mail.server,S=41045,W=41755:2,FS
imap(pid 5720 user user1): Error:
open(/path/to/mail/user2/tmp/1285335855.M242128P1165.my.mail.server,S=41045,W=41755)
failed: No such file or directory
imap(pid 5720 user user1): Error: Maildir: Symlink destination doesn't exist:
/path/to/mail/user2/cur/1285336337.M656599P1166.my.mail.server,S=41045,W=41755:2,FST
imap(pid 5720 user user1): Error:
open(/path/to/mail/user2/tmp/1285335855.M242128P1165.my.mail.server,S=41045,W=41755)
failed: No such file or directory
imap(pid 5720 user user1): Error: Maildir: Symlink destination doesn't exist:
/path/to/mail/user2/cur/1285336337.M656599P1166.my.mail.server,S=41045,W=41755:2,FST
imap(pid 5720 user user1): Error:
open(/path/to/mail/user2/tmp/1285335855.M242128P1165.my.mail.server,S=41045,W=41755)
failed: No such file or directory
imap(pid 5721 user user2): Error: Maildir: Found unwanted directory
/path/to/mail/user2/cur/:2,FST, but rmdir() failed: Directory not empty
imap(pid 5721 user user2): Disconnected: Internal error occurred. Refer to
server log for more information. [2010-09-24 09:07:23] bytes=1268/173293
Note that user1 != user2. Seems like this might be caused by having:
service imap {
client_limit = 5
service_count = 0
}
[Dovecot] inbox doesn't exist, and quota calculation error
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 doesn't exist: INBOX lda(pid 8212 user user3): Error: BUG: Saving failed to unknown storage and some clients report receiving this IMAP error: tag NO Mailbox doesn't exist: INBOX although in general mail delivery and IMAP work, and these users' Maildir++ directories do exist and look OK. This error did not occur for the user1 or user2 in the other report. And here's a third kind of error: imap(pid 5722 user user4): Error: stat(/path/to/mail/user4/tmp/ͼ) failed: No such file or directory imap(pid 5722 user user4): Error: Internal quota calculation error That path looks like a memory munge.
Re: [Dovecot] unwanted maildir directory
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 were assigned to the same imap process, that's all. They know nothing about each other and there are no namespaces or public folders or any of that. Does one of these asserts catch it? imap(pid 72709 user specmail773): Panic: file maildir-save.c: line 79 (maildir_file_move): assertion failed: (*mf-tmp_name != '\0') imap(pid 72770 user specmail52): Panic: file maildir-save.c: line 79 (maildir_file_move): assertion failed: (*mf-tmp_name != '\0')
Re: [Dovecot] inbox doesn't exist, and quota calculation error
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? Yes. Did OSX have valgrind yet? Dunno.
Re: [Dovecot] unwanted maildir directory
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 clients=60 user=user\%d pass=test no_tracking logout=25 (no copy commands) Here's a backtrace: 0 __kill + 10 1 abort + 177 2 default_fatal_finish + 68 3 i_internal_error_handler + 0 4 i_debug + 0 5 maildir_transaction_save_commit_pre + 2585 6 index_transaction_index_commit + 164 7 mail_index_transaction_commit_full + 155 8 index_transaction_commit + 131 9 mailbox_transaction_commit_get_changes + 56 10 cmd_copy + 848 (cmd-copy.c:157) 11 client_command_input + 36 (imap-client.c:687) 12 client_command_input + 416 (imap-client.c:752) 13 client_handle_input + 134 (imap-client.c:793) 14 client_input + 118 (imap-client.c:844) 15 io_loop_handler_run + 234 16 io_loop_run + 56 17 master_service_run + 27 18 main + 689 (main.c:359) 19 start + 52 FWIW I also turned on maintainer mode, but it made no difference. What else would you like me to try?
Re: [Dovecot] unwanted maildir directory
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 meant to use instead of maintainer-mode. But it makes no difference, except being more verbose.
Re: [Dovecot] unwanted maildir directory
Wonder if attached patch fixes it. Yes. Thanks!
[Dovecot] recursive locks
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 instance, squat_trie_lock(). Imagine one user is connected to a single
imap process twice.
[Dovecot] SIS for maildir?
When might deduplication of attachments work with maildir?
[Dovecot] bogus fts percentage
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.
Re: [Dovecot] Single instance storage - testing please
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.
[Dovecot] Roff typo in sievec.1.in
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- piled Sieve binary file. Note that this option is not The output should be: dump to be written to stdout. The out-file argument may also be omitted, which has the same effect as '-'. The output is identical to what the sieve-dump(1) command pro- duces for a compiled Sieve binary file. Note that this Here is a patch: --- a/doc/man/sievec.1.in +++ b/doc/man/sievec.1.in @@ -50,8 +50,9 @@ Don\(aqt write the binary to \fIout\-file\fP, but write a textual dump of the binary instead. In this context, the \fIout\-file\fP value '\-' has special meaning: it causes the the textual dump to be written to \fBstdout\fP. -The \fIout\-file\fP argument may also be omitted, which has the same effect as -'\-'. The output is identical to what the \fBsieve\-dump\fP(1) command produces +The \fIout\-file\fP argument may also be omitted, which has the same effect +as '\-'. +The output is identical to what the \fBsieve\-dump\fP(1) command produces for a compiled Sieve binary file. Note that this option is not allowed when the \fIout\-file\fP argument is a directory. .TP
Re: [Dovecot] (Single instance) attachment storage
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.
Re: [Dovecot] Home directories
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 imply, to some people, $HOME. I suggest something less overloaded, such as nook, cubby, or stash.
Re: [Dovecot] (Single instance) attachment storage
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?
Re: [Dovecot] beta6 mdbox errors
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 broken data at offset=6216579 uid=0 means this happens while saving a new message. Magic value is probably NULs. Maybe it was reading old cached data, this should help then: http://hg.dovecot.org/dovecot-2.0/rev/26594f6d784a Yes, that helps. Thanks.
[Dovecot] quota_set leak
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_deinit
call belongs in quota_deinit.
--- a/src/plugins/quota/quota-storage.c (beta6)
+++ b/src/plugins/quota/quota-storage.c (patched)
@@ -427,6 +427,7 @@
{
struct quota_user *quser = QUOTA_USER_CONTEXT(user);
+ quota_settings_deinit(quser-quota-set);
quota_deinit(quser-quota);
quser-module_ctx.super.deinit(user);
}
Re: [Dovecot] Patch to fix leak in imap_refresh_proctitle in beta[5, 6]
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.
Re: [Dovecot] Patch to fix leak in imap_refresh_proctitle in beta[5, 6]
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_proctitle).
--- a/src/imap/cmd-uid.c(beta5)
+++ b/src/imap/cmd-uid.c(working copy)
@@ -20,7 +20,7 @@
return TRUE;
}
- cmd-name = t_strconcat(UID , cmd_name, NULL);
+ cmd-name = p_strconcat(cmd-pool, UID , cmd_name, NULL);
cmd-cmd_flags = command-flags;
cmd-func = command-func;
cmd-uid = TRUE;
Incidentally, this line in client_command_input is puzzling. Comparing a
pointer to a character?
if (cmd-name == '\0') {
[Dovecot] 2.0.beta6 panic (mailbox_list_get_unexpanded_path)
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-list.c: line 318 (mailbox_list_get_unexpanded_path): assertion failed: (*location == '0') The location string is 1mdbox:/Volumes/Mail/joe. This did not happen with beta5. Backtrace: 0 __kill + 10 1 abort + 90 2 default_fatal_finish + 68 3 i_internal_error_handler + 0 4 i_debug + 0 5 mailbox_list_get_unexpanded_path + 111 6 mailbox_list_mkdir + 70 7 mdbox_map_open_internal + 169 8 mdbox_map_open_or_create + 14 9 mdbox_write_index_header + 51 10 mdbox_mailbox_create_indexes + 27 11 dbox_mailbox_create + 155 12 mailbox_open_full + 267 13 cmd_select_full + 1856 (cmd-select.c:287) 14 cmd_select + 11 (cmd-select.c:430) 15 client_command_input + 36 (imap-client.c:672) 16 client_command_input + 416 (imap-client.c:737) 17 client_handle_input + 134 (imap-client.c:778) 18 client_input + 118 (imap-client.c:829) 19 io_loop_handler_run + 234 20 io_loop_run + 56 21 master_service_run + 27 22 main + 689 (main.c:360) 23 start + 52
Re: [Dovecot] 2.0.beta6 panic (mailbox_list_get_unexpanded_path)
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] beta6 mdbox errors
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 broken data at offset=6216579 Warning: mdbox /Volumes/Mail/joe/storage: rebuilding indexes (I set mdbox_rotate_size = 200M.) These did not appear with beta5.
Re: [Dovecot] null errors from 2.0.beta5
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.
[Dovecot] null errors from 2.0.beta5
When my dovecot-2.0.beta5 auth module logs a 552-byte debug message, the message is split into two lines and also a null error message: Wed Jun 9 23:44:29 gromit dovecot[58892]: auth: Error: I think this has to do with the use of PIPE_BUF (512) sized buffers in the logging code, and the !line_is_ok() case in i_failure_parse_line(). Could you please remove the null error message? Just a nuisance, nothing serious. Thanks.
Re: [Dovecot] mdbox error with 2.0.beta5
So storage's uidvalidity had changed 17,5 minutes after Foobar's index was created. Was this a real user? No, this was a test user running a simulation. I can reproduce it at will if you need any more information. Since both dates are May 14th and your mail was also dated May 14h, was the user's first mdbox access also that day? Yes. Does it keep happening more than once for the same user? Yes. I heard this happens also after dsync mirror The dsync command was not involved. Just IMAP connections and dovecot-lda delivery. The path mismatch is intended. Rebuilding indexes rebuilds all indexes in all mailboxes. OK.
Re: [Dovecot] mdbox error with 2.0.beta5
Nah, forget it. Looks like the uidvalidity assignment is done in a stupid racy way. http://hg.dovecot.org/dovecot-2.0/rev/7fc5db26f6eb should help? Yes, that helps. Thank you.
Re: [Dovecot] STARTTLS does not seem to work
altair/phil /home/phil 162 telnet 172.30.0.24 143 Trying 172.30.0.24... Connected to 172.30.0.24. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 STARTTLS LOGINDISABLED] AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited STARTTLS STARTTLS BAD Error in IMAP command received by server. ^]quit Every IMAP command needs a command tag. Instead of STARTTLS try A STARTTLS.
Re: [Dovecot] STARTTLS does not seem to work
Anyway, with the tag it does work on IMAP. But it still fails on POP For POP3 the command is STLS.
Re: [Dovecot] STARTTLS does not seem to work
Well, that kinda complicates a STARTTLS tunnel Perhaps you might be interested in these commands. I'm not sure about their portability but they work tolerably well in scripts on Mac OS X 10.6. $ openssl s_client -connect yourhost:imap -starttls imap $ openssl s_client -connect yourhost:pop3 -starttls pop3 $ openssl s_client -connect yourhost:imaps $ openssl s_client -connect yourhost:pop3s $ openssl s_client -connect yourhost:smtp -starttls smtp
[Dovecot] mdbox error with 2.0.beta5
Running 2.0.beta5 on Mac OS X with HFS+J, I often see this error in the log: Fri May 14 12:25:59 gromit dovecot[5466]: imap(pid 8101 user joe): Error: mdbox /var/spool/imap/dovecot/mail/mailboxes/INBOX/Foobar/dbox-Mails: map uidvalidity mismatch (1273852899 vs 1273853949) Fri May 14 12:25:59 gromit dovecot[5466]: imap(pid 8101 user joe): Disconnected: Internal error occurred. Refer to server log for more information. [2010-05-14 12:25:59] bytes=1337/4443 Fri May 14 12:25:59 gromit dovecot[5466]: imap(pid 8101 user joe): Warning: mdbox /var/spool/imap/dovecot/mail/storage: rebuilding indexes The logs also reveal that this user was logged in twice at the time. There appear to be two issues here: the uidvalidity mismatch, and the path in the rebuilding indexes message does not match the path in the uidvalidity mismatch error.
Re: [Dovecot] raw backtrace in masses
I am a bit new to this kind of debugging. What happens if I turn on core dumps on Solaris? See the Core Dumps section of http://www.dovecot.org/bugreport.html. Does this fix help against this sort of crashes? http://hg.dovecot.org/dovecot-2.0/rev/8f251e0bc02d Probably not. You're running 1.2 not 2.0, and you did not report seeing that assertion failure in your logs.
Re: [Dovecot] Dovecot headers at start of text returned to KMail
1272011889.M384349P30156.f12barry.office.onelan.co.uk,S=6494,W=6606:2,S The size of this file should be 6494 bytes (S=6494) but in your attachment it is 6519 bytes. Did something insert a header into the file after dovecot received it? Perhaps this one, which (with a CR added) is 25 bytes, the same as the difference between 6519 and 6494: X-Spambayes-Trained: ham As I understand it, once messages are under dovecot's control they must not ever change at all. Adding headers after delivery is forbidden.
Re: [Dovecot] Dovecot headers at start of text returned to KMail
To recover from this error I think I need to: 1. service dovecot stop 2. rename all the mail files to have the S= match the size of the file on disk 3. remove all the dovecot.* files 4. service dovecot start Is this correct? I believe so but I'm not an authority on this part. Note that removing the dovecot.* files has other side effects, like making your clients re-download all the messages again, and losing any keywords. If you instead just remove the X-Spambayes-Trained header (and any other headers that might have been added after delivery) from the affected messages (using, e.g., sed), you might be able to skip step 3.
Re: [Dovecot] adding users to passwd-file
Is there a tool equivalent to the system passwd command The dovecotpw command may be a good place to start.
[Dovecot] imap-zlib patch to fix runaway imap process
Here is a patch to fix the problem where an imap process runs away when
imap-zlib is in use. The backtrace showed:
io_loop_handler_run -
stream_send_io -
client_output -
o_stream_flush -
o_stream_zlib_flush -
o_stream_zlib_send_flush
When o_stream_zlib_flush returns 0, stream_send_io reinstates the IO_WRITE
event, causing the infinite loop.
diff -ur dovecot-2.0.beta4/src/plugins/zlib/ostream-bzlib.c
dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-bzlib.c
--- dovecot-2.0.beta4/src/plugins/zlib/ostream-bzlib.c 2010-02-12
20:22:07.0 -0600
+++ dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-bzlib.c 2010-04-20
19:15:29.0 -0500
@@ -122,15 +122,15 @@
static int o_stream_bzlib_flush(struct ostream_private *stream)
{
struct bzlib_ostream *zstream = (struct bzlib_ostream *)stream;
+ int ret;
if (o_stream_bzlib_send_flush(zstream) 0)
return -1;
- if (o_stream_flush(zstream-output) 0) {
+ ret = o_stream_flush(zstream-output);
+ if (ret 0)
zstream_copy_error(zstream);
- return -1;
- }
- return 0;
+ return ret;
}
static ssize_t
diff -ur dovecot-2.0.beta4/src/plugins/zlib/ostream-zlib.c
dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-zlib.c
--- dovecot-2.0.beta4/src/plugins/zlib/ostream-zlib.c 2010-02-18
22:01:56.0 -0600
+++ dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-zlib.c 2010-04-20
19:15:29.0 -0500
@@ -184,15 +184,15 @@
static int o_stream_zlib_flush(struct ostream_private *stream)
{
struct zlib_ostream *zstream = (struct zlib_ostream *)stream;
+ int ret;
if (o_stream_zlib_send_flush(zstream) 0)
return -1;
- if (o_stream_flush(zstream-output) 0) {
+ ret = o_stream_flush(zstream-output);
+ if (ret 0)
zstream_copy_error(zstream);
- return -1;
- }
- return 0;
+ return ret;
}
static ssize_t
[Dovecot] double write-locking dovecot.index.log
Dovecot's transactions often write-lock dovecot.index.log twice (without unlocking in between), and then unlock it twice. Is that intended, or is that a bug? If I read the man pages correctly, double write-locking is pointless but safe. But double unlocking could cause data corruption during the period between the first and second unlocks, because the locks don't nest (are not refcounted). The first unlock leaves the file totally unlocked. Could this be the source of some index corruption errors? For example: 1. Process A acquires a F_WRLCK on a file. 2. Through a different code path, process A again acquires a F_WRLCK on the same file. Since these locks don't nest this is essentially a no-op. 3. Process A modifies the file. 4. Process A unlocks the file to undo the lock in step 2. Now the file has no lock on it at all. 5a. Process B locks, modifies, and unlocks the file. 5b. Process A also modifies the file, thinking that it still has a write lock. 6. Process A unlocks the file to undo the lock in step 1, but this is another no-op. Data corruption is possible if steps 5a and 5b conflict, or if 5b uses stale data. Here is a code path in dovecot-1.2.11 which exhibits the above behavior. Outer write lock: maildir_transaction_save_commit_pre - maildir_transaction_save_commit_pre_sync - maildir_sync_index_begin - mail_index_sync_begin - mail_index_sync_begin_to - mail_index_sync_begin_init - mail_transaction_log_sync_lock - mail_transaction_log_lock_head - mail_transaction_log_file_lock - mail_index_lock_fd - file_wait_lock - file_lock_do Inner write lock: maildir_transaction_save_commit_pre - maildir_sync_index_finish - mail_index_sync_commit - mail_index_write - mail_transaction_log_rotate - mail_transaction_log_file_create - mail_transaction_log_file_create2 - mail_transaction_log_file_lock - mail_index_lock_fd - file_wait_lock - file_lock_do The file being locked is the same, dovecot.index.log. In another case, maildir_sync_index_begin is reached this way (outer lock): mailbox_sync - mailbox_sync_init - maildir_storage_sync_init - maildir_sync_context - maildir_sync_index_begin - mail_index_sync_begin - etc. And maildir_sync_index_finish is reached this way (inner lock): mailbox_sync - mailbox_sync_init - maildir_storage_sync_init - maildir_sync_context - maildir_sync_index_finish - etc. Could these lead to data corruption? Please let me know if you need any more information. Thanks.
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
With v2.0 it's possible to do:
disable_plaintext_auth = yes
remote submit.domain.org {
disable_plaintext_auth = no
}
I think that takes care of the need for X-PLAIN-SUBMIT?
Wouldn't that allow anyone from submit.domain.org to use plaintext, rather than
only submit users? I know X-PLAIN-SUBMIT is not pretty and there should be a
better way. Not sure that's quite it though.
[urlauth-keys] could probably use lib-dict instead.
That sounds promising.
Ported: http://hg.dovecot.org/dovecot-2.0-urlauth/
Awesome! Thanks!
Re: [Dovecot] RFC 4468
the MUA submits the message to the IMAP server and then the IMAP server forwards it to the MTA. The MUA submits the message to the IMAP server. Then the MUA tells the submission server to fetch the message from the IMAP server. The IMAP server does not push the message out to the MTA.
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
Yes, it allows submit.domain.org to use plaintext for all authentications. But typically your submit server wouldn't be trying to authenticate as anything else as the submit user, I think? In v1.2 you could also do something similar to this by adding the submit server's IP to login_trusted_networks. A well-behaved submission server will only authenticate as a submit user. But the intent is to open the door as little as possible. If the administrator of the IMAP server disables plain text auth, it's safer to weaken that only for submit user(s) than for an entire network. Anyone on that network would be able to use plain text auth for any user. Consider that the submission server and the IMAP server may be unrelated, under completely different administrative domains. Separate departments of a school or business, for instance, or even different schools or businesses. You would want to allow submit users from any network to connect (securely) and authenticate. But the authentication must be plain-text for submit user(s) even when regular users are forbidden from using it. RFC 4468 section 3.3 requires it: Specifically, this requires that the submit server implement a configuration that uses STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the IMAP server.
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
That says the submit server's IMAP client must support STARTTLS+SASL PLAIN authentication. Yes. Which is exactly the opposite of what X-PLAIN-SUBMIT does. X-PLAIN-SUBMIT is intended to allow a submission server to connect to the IMAP server, send STARTTLS, and then authenticate using a plain-text password -- even when PLAIN is disabled for normal users. Nothing more. We just didn't want URLAUTH to break when the administrator shuts down PLAIN auth.
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
except if auth { mechanisms } doesn't have PLAIN
Precisely. Hence, X-PLAIN-SUBMIT.
Re: [Dovecot] RFC 4468
wouldn't it be nice to have RFC 4468 Actually, Apple contributed such support a few hours ago but it's stuck in the mailing list queue because the patch is big. As soon as Timo approves the posting
[Dovecot] 2.0.alpha3 typo patch
--- 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_gid(set-mail_privileged_group,
rset.privileged_gid))
i_fatal(Unknown mail_gid group: %s, set-mail_gid);
}
if (*set-mail_access_groups != '\0')
[Dovecot] 2.0.alpha3 ssl_ca_file is broken
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 = /path/to/file as was done with ssl_cert and ssl_key. Tue Nov 17 11:19:38 server dovecot[1143]: imap-login: Fatal: Error reading configuration: Invalid settings: ssl_ca_file: access(/path/to/file) failed: No such file or directory
